> Kontinuierliche Prozessverbesserung > Serviceanfragemanagement > ServiceNow > Daten Template

Ihr Daten-Template für das Serviceanfragemanagement

ServiceNow

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Service-Request-Managements (21) Aktivitäten im Service-Request-Management (14) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für das Serviceanfragemanagement

Dieses umfassende Daten-Template erleichtert Ihnen den Einstieg ins Process Mining für das Serviceanfragemanagement. Es zeigt, welche wichtigen Attribute Sie erfassen und welche Aktivitäten Sie nachverfolgen sollten. Außerdem enthält es praktische Hinweise zur Datenextraktion aus ServiceNow. Mit diesem Template erfassen Sie alle erforderlichen Daten für eine präzise Analyse und wirksame Prozessverbesserungen.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Prozesserkennung
Schritt-für-Schritt-Anleitung zur Datenextraktion

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

Template herunterladen

Attribute des Service-Request-Managements

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

5 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des konkreten Ereignisses oder der Aufgabe, die im Ablauf der Serviceanfrage aufgetreten ist.
Beschreibung Das Attribut Aktivität erfasst den Namen jedes Schritts oder jeder Statusänderung im Prozess der Serviceanfrage. Dazu gehören beispielsweise Ereignisse wie „Anfrage erstellt“, „Anfrage freigegeben“, „Person zugewiesen“ oder „Anfrage geschlossen“. Durch die Analyse dieser Aktivitäten lässt sich der Prozessablauf visualisieren. Außerdem können häufige Abläufe und Abweichungen von der Standardvorgehensweise erkannt werden. Das Attribut bildet die Grundlage, um zu verstehen, was bei der Erfüllung einer Anfrage tatsächlich geschieht. Warum das wichtig ist Dies ist ein erforderliches Attribut, das die Schritte in der Prozessdarstellung festlegt. Es ist grundlegend für alle Prozessanalysen, etwa zur Erkennung von Engpässen, Schleifen mit Nacharbeit und Compliance-Problemen. Woher beziehen Abgeleitet aus Änderungen der Felder „State“ oder „Stage“ in Tabellen wie „sc_request“ oder „sc_req_item“ oder aus dem Prüfpfad (sys_audit). Beispiele Serviceanfrage erstelltAnfrage einer Gruppe zugewiesenServiceanfrage gelöstInformationen beim Benutzer angefordert
	Service Request ID ServiceRequestID	Die eindeutige Kennung jedes Datensatzes einer Serviceanfrage.
Beschreibung Die Service Request ID ist der Primärschlüssel, der jede von einem Benutzer oder System eingereichte Serviceanfrage eindeutig identifiziert. Sie bildet die zentrale Verbindung zwischen allen nachfolgenden Ereignissen, von der ersten Erfassung bis zum endgültigen Abschluss. Beim Process Mining ist diese ID entscheidend, um den gesamten Ablauf jeder einzelnen Anfrage zu rekonstruieren und ihren vollständigen Lebenszyklus zu analysieren. Warum das wichtig ist Dies ist die erforderliche Case-ID. Sie verknüpft alle zugehörigen Aktivitäten zu einer einzelnen Prozessinstanz und ermöglicht so die Analyse von Prozessabläufen, Varianten und Zykluszeiten. Woher beziehen Tabelle ServiceNow Request [sc_request], Feld „number“. Beispiele REQ0010001REQ0010025REQ0010112
	Startzeit EventTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis begonnen hat.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen die einzelnen Aktivitäten im Prozess der Serviceanfrage stattgefunden haben. Es liefert die chronologische Abfolge der Ereignisse, die für die Erstellung der Prozessdarstellung und zeitbasierte Analysen erforderlich ist. Genaue Timestamps sind entscheidend für die Berechnung von Zykluszeiten, Wartezeiten und Bearbeitungsdauern. Anhand dieser Daten lassen sich Engpässe, SLA-Verstöße und Leistungstrends im Zeitverlauf erkennen. Warum das wichtig ist Dieser erforderliche Timestamp sorgt dafür, dass Ereignisse korrekt geordnet werden. Er bildet die Grundlage für alle Leistungs- und Zeitdaueranalysen, einschließlich der Zykluszeit und der Erkennung von Engpässen. Woher beziehen In der Regel in den Feldern „sys_updated_on“ oder „sys_created_on“ der relevanten ServiceNow-Tabellen (z. B. sc_request, sc_task) oder im Prüfpfad (sys_audit) zu finden. Beispiele 2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Datenaktualisierung oder -extraktion.
Beschreibung Dieses Attribut gibt Datum und Uhrzeit an, zu denen die Daten zuletzt aus dem Quellsystem extrahiert und in das Process-Mining-Tool geladen wurden. So ist nachvollziehbar, wie aktuell die analysierten Daten sind. Analysten können damit prüfen, ob sie mit den neuesten Daten arbeiten. Das ist für die operative Überwachung und zeitnahe, datengetriebene Entscheidungen entscheidend. Außerdem lässt sich so einschätzen, wie aktuell die Erkenntnisse sind. Warum das wichtig ist Macht die Aktualität der Daten transparent. Das ist entscheidend, um den Analyseergebnissen zu vertrauen und rechtzeitig datengetriebene Entscheidungen zu treffen. Woher beziehen Dieses Metadatenfeld wird beim Laden der Daten hinzugefügt und enthält den Timestamp, zu dem der ETL-Auftrag abgeschlossen wurde. Beispiele 2023-10-27T04:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten stammen.
Beschreibung Dieses Attribut gibt das Quellsystem der Daten an, in diesem Fall ServiceNow. Es ist hilfreich, wenn Daten aus mehreren Systemen zusammengeführt werden, um einen umfassenden Überblick über den Prozess zu erhalten. Bei Analysen mit nur einer Datenquelle liefert das Attribut wichtigen Kontext und unterstützt die Datenverwaltung und Data Governance. So ist die Herkunft der analysierten Daten jederzeit nachvollziehbar. Warum das wichtig ist Liefert wichtige Metadaten für Data Governance, Rückverfolgbarkeit und Kontext, insbesondere wenn Daten aus mehreren Unternehmenssystemen zusammengeführt werden. Woher beziehen In der Regel ein statischer Wert, der während der Datenextraktion und -transformation hinzugefügt wird. Beispiele ServiceNow
	Kategorie Category	Die primäre Klassifizierung der Serviceanfrage, zum Beispiel Hardware oder Software.
Beschreibung Die Kategorie ordnet die Serviceanfrage einer übergeordneten Klasse zu. Sie dient in der Regel dazu, die Anfrage an das zuständige Team weiterzuleiten und die eingehenden Anfragen nach Typ auszuwerten. Beim Process Mining ermöglicht die Kategorie gezielte Filter und Auswertungen nach Dimensionen. Analysten können damit Prozessabläufe, Zykluszeiten und Automatisierungsraten verschiedener Anfragetypen vergleichen und Abweichungen erkennen, die in aggregierten Daten verborgen bleiben. Der Ablauf für eine Hardwareanfrage kann sich beispielsweise grundlegend von dem für eine Softwareanfrage unterscheiden. Warum das wichtig ist Ermöglicht eine differenzierte Segmentierung und den Vergleich von Prozessen für verschiedene Servicearten. So lassen sich kategoriespezifische Probleme und Verbesserungsmöglichkeiten erkennen. Woher beziehen ServiceNow-Tabelle „Request Item“ [sc_req_item], üblicherweise über die Kategorie des zugehörigen Catalog Item [sc_cat_item]. Beispiele HardwareSoftwareZugriffsanfrageNetzwerk
	Priorität Priority	Die Prioritätsstufe der Serviceanfrage, die ihre Dringlichkeit beeinflusst.
Beschreibung Die Priorität gibt die relative Bedeutung und Dringlichkeit einer Serviceanfrage an. Sie wird häufig anhand der Auswirkungen und der Dringlichkeit festgelegt und hilft den Mitarbeitenden zu entscheiden, welche Anfragen zuerst bearbeitet werden. Die Analyse nach Priorität zeigt, ob Anfragen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. In Dashboards können Sie prüfen, ob SLAs für kritische Anfragen eingehalten werden, und feststellen, wie wirksam das Priorisierungssystem ist. Warum das wichtig ist Ermöglicht die Segmentierung von Anfragen, um zu prüfen, ob Anfragen mit hoher Priorität schneller bearbeitet werden. Das ist wichtig für die SLA-Analyse und die Ressourcenverteilung. Woher beziehen Tabellen ServiceNow Request [sc_request] oder Request Item [sc_req_item], Feld „priority“. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	SLA eingehalten MadeSLA	Ein boolesches Kennzeichen, das angibt, ob die Serviceanfrage innerhalb der vereinbarten Service Level Agreement-Frist gelöst wurde.
Beschreibung Dieses Attribut gibt an, ob die Serviceanfrage innerhalb der festgelegten Service Level Agreement (SLA)-Frist gelöst wurde. Es ist eine wichtige Ergebniskennzahl, die die Serviceleistung direkt an den vereinbarten Zusagen misst. Mit diesem Kennzeichen lässt sich die KPI zur SLA-Einhaltungsquote berechnen. Als Dimension ermöglicht es den Vergleich der Prozesspfade von SLA-konformen und SLA-verletzenden Anfragen. So werden wiederkehrende Muster und Aktivitäten sichtbar, die zu SLA-Verstößen beitragen. Das ist wichtig, um Risiken frühzeitig zu überwachen und den Service kontinuierlich zu verbessern. Warum das wichtig ist Misst die Leistung direkt an den Servicezusagen und ermöglicht eine Ursachenanalyse von SLA-Verstößen durch den Vergleich konformer und nicht konformer Cases. Woher beziehen ServiceNow-Tabelle „Task SLA“ [task_sla], Feld 'has_breached'. Der Wert muss umgekehrt werden, zum Beispiel MadeSLA = NOT has_breached. Beispiele truefalse
	Status State	Der aktuelle Bearbeitungsstatus der Serviceanfrage.
Beschreibung Das Attribut Status gibt die aktuelle Phase der Serviceanfrage in ihrem Ablauf an, etwa „Offen“, „In Bearbeitung“, „Ausstehend“ oder „Geschlossen“. Änderungen dieses Feldes werden häufig verwendet, um Aktivitäten für die Prozessdarstellung zu erzeugen. Die Analyse des Status ist entscheidend, um zu verstehen, wie lange Anfragen in bestimmten Statuswerten verbleiben, insbesondere in Warte- oder Ausstehend-Status. So lassen sich Warteschlangen und Verzögerungen erkennen, etwa die Zeit im Status „Warten auf Benutzerinformationen“, der häufig zu längeren Zykluszeiten führt. Warum das wichtig ist Zeigt den Status der Anfrage zu jedem Zeitpunkt an und ermöglicht so die Analyse von Wartezeiten, Warteschlangen und der Dauer einzelner Prozessphasen. Woher beziehen Tabellen ServiceNow Request [sc_request] oder Request Item [sc_req_item], Feld „state“ oder „stage“. Beispiele OffenIn BearbeitungWarten auf BenutzerinformationenVollständig abgeschlossen
	Zugewiesen an AssignedTo	Der einzelne Benutzer, der zu einem bestimmten Zeitpunkt für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung Dieses Attribut gibt die Person oder den Techniker an, die bzw. der der Serviceanfrage zugewiesen ist. Der Wert ändert sich, wenn die Anfrage an eine andere Person übergeben wird. Die Analyse des Feldes „Zugewiesen an“ ist entscheidend, um die Arbeitsverteilung, die individuelle Leistung und die Auswirkungen von Übergaben auf die Lösungszeiten zu verstehen. Sie hilft dabei, Fragen zur Ressourcennutzung zu beantworten und Möglichkeiten für Schulungen oder klarere Prozesse zu erkennen, um Neuzuweisungen zu verringern. Warum das wichtig ist Ermöglicht die Analyse der Arbeitslast, Leistung und Übergaben einzelner Mitarbeitender. Das Attribut ist wichtig für die Ressourcenplanung und die Erkennung von Engpässen, die mit bestimmten Personen zusammenhängen. Woher beziehen Tabellen ServiceNow Request Item [sc_req_item] oder Catalog Task [sc_task], Feld „assigned_to“. Beispiele Beth AnglinDavid LooHoward Johnson
	Zuweisungsgruppe AssignmentGroup	Das Team oder die Gruppe, das bzw. die für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung Die Zuweisungsgruppe bezeichnet das Team, etwa „Service Desk“, „Netzwerkbetrieb“ oder „Datenbankadministration“, das in einer bestimmten Phase für eine Serviceanfrage zuständig ist. Dieses Attribut ist wichtig, um den Prozessfluss zwischen verschiedenen Fachbereichen zu analysieren. Durch die Erfassung von Änderungen der Zuweisungsgruppe können Unternehmen Übergaben zwischen Teams visualisieren, Wartezeiten in den jeweiligen Arbeitsvorräten messen und Abhängigkeiten oder Verzögerungen zwischen Teams erkennen. Das ist entscheidend, um die bereichsübergreifende Zusammenarbeit zu verbessern. Warum das wichtig ist Zeigt die Arbeitsverteilung zwischen Teams und Übergaben zwischen ihnen. So lassen sich teamspezifische Engpässe und Leistungsprobleme erkennen. Woher beziehen Tabellen ServiceNow Request Item [sc_req_item] oder Catalog Task [sc_task], Feld „assignment_group“. Beispiele Service DeskIT-Support L2Hardwarebereitstellung
	Anzahl der Wiedereröffnungen ReopenCount	Wie oft eine Serviceanfrage nach ihrer Lösung erneut geöffnet wurde.
Beschreibung Dieses Attribut zählt, wie oft eine Serviceanfrage nach der Lösung oder dem Abschluss wieder in den Status „Offen“ oder „In Bearbeitung“ versetzt wurde. Ein Wert über null zeigt, dass die ursprüngliche Lösung nicht erfolgreich war. Die Kennzahl weist direkt auf Nacharbeit hin und ist ein wichtiger Bestandteil der KPI zur Lösungsquote beim ersten Versuch. Häufige Wiedereröffnungen deuten auf eine mangelhafte Lösungsqualität, eine unvollständige Erfüllung oder ein Missverständnis der Benutzeranforderungen hin. All dies beeinträchtigt die Prozesseffizienz und die Zufriedenheit der Benutzer. Warum das wichtig ist Quantifiziert Nacharbeit und Lösungsqualität. Eine hohe Zahl an Wiedereröffnungen weist auf ineffiziente Abläufe, eine niedrige Lösungsquote beim ersten Versuch und sinkende Kundenzufriedenheit hin. Woher beziehen ServiceNow-Tabelle „Request“ [sc_request] oder „Request Item“ [sc_req_item], Feld 'reopen_count'. Beispiele 012
	Automatisiert IsAutomated	Ein Kennzeichen, das angibt, ob ein System oder eine Automatisierung eine Aktivität ausgeführt hat.
Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die ein Mitarbeiter manuell ausgeführt hat, und solchen, die ein automatisiertes System wie ein Workflow oder eine Integration übernommen hat. „Genehmigung angefordert“ kann beispielsweise automatisiert sein, während „Anfrage einem Agenten zugewiesen“ manuell erfolgt. Das Attribut ist wichtig, um den Automatisierungsgrad im Serviceanfrageprozess zu messen und zu erhöhen. Es zeigt, welche manuellen Aufgaben besonders zeitaufwendig sind und sich für eine künftige Automatisierung eignen. So lassen sich Effizienz steigern und Kosten senken. Warum das wichtig ist Ermöglicht die Messung des Automatisierungsgrads und zeigt Möglichkeiten zur Automatisierung manueller Aufgaben auf. Das steigert die Effizienz und senkt die Betriebskosten. Woher beziehen Wird abgeleitet, indem geprüft wird, ob der Benutzer, der eine Aktion ausgeführt hat, zum Beispiel 'sys_updated_by', ein festgelegter System- oder Integrationsbenutzer ist. Beispiele truefalse
	Beim ersten Versuch gelöst IsFirstPassResolution	Ein Kennzeichen dafür, ob die Anfrage beim ersten Versuch und ohne Wiedereröffnung gelöst wurde.
Beschreibung Dieses berechnete Attribut ist ein boolesches Kennzeichen. Es ist nur dann 'true', wenn die Serviceanfrage gelöst und abgeschlossen wurde, ohne jemals wiedereröffnet worden zu sein. Es ist ein wichtiger Indikator für die Qualität und Wirksamkeit der Lösung durch den Service Desk. Die Kennzahl unterstützt direkt die KPI zur Lösungsquote beim ersten Versuch. Eine hohe Quote ist wünschenswert, denn sie steht für effizienten Service und hochwertige Lösungen und trägt zu einer höheren Kundenzufriedenheit bei. Die Analyse von Cases, die nicht beim ersten Versuch gelöst wurden, kann Ursachen wie unzureichende Schulungen, mangelhafte Dokumentation oder eine falsche Erstdiagnose aufdecken. Warum das wichtig ist Misst Qualität und Effizienz des Lösungsprozesses. Eine niedrige Lösungsquote beim ersten Versuch weist auf grundlegende Probleme hin, die Nacharbeit und Unzufriedenheit bei Kunden verursachen. Woher beziehen Wird auf Case-Ebene berechnet. Ein Case gilt als beim ersten Versuch gelöst, wenn sein 'ReopenCount' null beträgt. Beispiele truefalse
	Endzeit EndTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. Sie entspricht dem Timestamp der nächsten Aktivität in der Abfolge und legt damit die Dauer der aktuellen Aktivität fest. Dieses Attribut ist entscheidend, um die Bearbeitungsdauer der einzelnen Prozessschritte zu berechnen. Durch den Vergleich von Start- und Endzeit lassen sich Bearbeitungs- und Wartezeiten berechnen. Das ist grundlegend, um Engpässe zu erkennen, die Ressourceneffizienz zu messen und die Leistung anhand zeitbasierter Ziele zu überwachen. Warum das wichtig ist Dieses Attribut ist erforderlich, um die Dauer jeder Aktivität zu berechnen. Diese ist eine zentrale Grundlage für Leistungsanalysen, die Erkennung von Engpässen und die Untersuchung der Ressourcennutzung. Woher beziehen Dieses abgeleitete Attribut wird anhand des „StartTime“-Werts des nachfolgenden Ereignisses im Case berechnet. Beispiele 2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
	Eröffnet von OpenedBy	Die Person, die die Serviceanfrage ursprünglich eingereicht hat.
Beschreibung Dieses Attribut gibt an, welcher Benutzer die Serviceanfrage erstellt hat. Das ist häufig die betroffene Person, kann aber auch eine Führungskraft, eine Vertretung oder ein automatisiertes System sein. Die Auswertung nach dem Benutzer, der die Anfrage eröffnet hat, oder nach dessen Abteilung zeigt Muster auf. So lässt sich beispielsweise erkennen, ob eine bestimmte Benutzergruppe häufig komplexe oder problematische Anfragen einreicht. Daraus können gezielte Schulungen oder bessere Wissensdatenbankartikel abgeleitet werden, die den Self-Service fördern. Warum das wichtig ist Ermöglicht die Auswertung von Anfragemustern nach Benutzer, Abteilung oder Rolle. Die Ergebnisse können in Schulungsmaßnahmen und gezielte Prozessverbesserungen einfließen. Woher beziehen ServiceNow-Tabelle „Request“ [sc_request], Feld 'opened_by'. Beispiele Abel TuterFred LuddyDon Goodliffe
	Kanal ContactType	Der Weg, über den der Anfragende die Serviceanfrage einreicht.
Beschreibung Der Kontakttyp beziehungsweise Kanal gibt an, wie die Serviceanfrage eingegangen ist. Übliche Kanäle sind das Serviceportal, E-Mail, Telefon oder ein automatischer Alarm. Der Kanal ist wichtig, um Prozessabweichungen zu untersuchen, die durch die Art der Einreichung entstehen können. Anfragen über das Portal sind beispielsweise oft strukturierter und stärker automatisiert. Dadurch werden sie möglicherweise schneller bearbeitet als Anfragen per E-Mail. Die Auswertung zeigt, welche Kanäle effizienter sind. Warum das wichtig ist Zeigt, wie sich die verschiedenen Einreichungskanäle auf Prozesseffizienz, Automatisierungsgrad und Zykluszeiten auswirken. Diese Erkenntnisse helfen dabei, die Interaktion mit Benutzern zu verbessern. Woher beziehen ServiceNow-Tabellen „Request“ [sc_request] oder „Interaction“ [interaction]. Das Feld heißt häufig 'contact_type'. Beispiele PortalE-MailTelefonSelf-Service
	Lösungscode ResolutionCode	Ein Code zur Klassifizierung der abschließenden Lösung der Serviceanfrage.
Beschreibung Der Lösungscode klassifiziert strukturiert, wie eine Serviceanfrage letztlich gelöst wurde. Beispiele sind „Durch Automatisierung erfüllt“, „Benutzerfehler“ oder „Nicht mehr erforderlich“. Dieses Attribut ist für das Dashboard zur Ursachenanalyse von Verzögerungen wichtig. Werden Lösungscodes mit langen Zykluszeiten oder häufigen Nacharbeiten verglichen, lassen sich systemische Probleme erkennen. Sind beispielsweise Anfragen mit dem Code „Unvollständige Informationen“ regelmäßig langsam, deutet das auf Probleme bei der anfänglichen Datenerfassung hin. Warum das wichtig ist Liefert strukturierte Daten zu den Lösungsergebnissen und ermöglicht so die Ursachenanalyse von Prozessverzögerungen, Nacharbeit und weiteren Ineffizienzen. Woher beziehen ServiceNow-Tabelle „Request Item“ [sc_req_item] oder eine zugehörige Task-Tabelle. Das Feld heißt häufig 'close_code' oder 'resolution_code'. Beispiele Dauerhaft gelöstNicht gelöst (nicht reproduzierbar)Anfrage erfülltVom Benutzer storniert
	Nacharbeit IsRework	Ein berechnetes Kennzeichen, das angibt, ob eine Aktivität im selben Case wiederholt wurde.
Beschreibung Dieses boolesche Kennzeichen identifiziert Nacharbeitsschleifen innerhalb einer Serviceanfrage. Es wird auf 'true' gesetzt, wenn dieselbe Aktivität im selben Case bereits zuvor stattgefunden hat. Das ist beispielsweise der Fall, wenn eine Anfrage zweimal demselben Team zugewiesen oder der Benutzer mehrfach um Informationen gebeten wird. Dieses Attribut ist für das Dashboard zu Agentenübergaben und Nacharbeitsfällen sowie für die KPI zur Nacharbeitsquote bei Anfragen wichtig. Es macht ineffiziente Schleifen im Prozess sichtbar und quantifizierbar, die in aggregierten Daten oft verborgen bleiben. Warum das wichtig ist Kennzeichnet und quantifiziert Nacharbeit direkt. So lassen sich Ursachen und Auswirkungen ineffizienter Schleifen untersuchen, die Kosten und Zykluszeiten erhöhen. Woher beziehen Wird während der Datentransformation berechnet, indem geprüft wird, ob derselbe Aktivitätsname im selben Case bereits zuvor vorkam. Beispiele falsetrue
	Zufriedenheitsbewertung SatisfactionScore	Die Zufriedenheitsbewertung, die der Anfragende beim Abschluss abgibt.
Beschreibung Dieses Attribut erfasst die Zufriedenheitsbewertung, die der Endbenutzer nach der Lösung seiner Serviceanfrage abgibt, häufig auf einer Skala von 1 bis 5. Sie misst direkt, wie der Service wahrgenommen wird. Diese Daten sind für das Dashboard zur Analyse der Auswirkungen auf die Kundenzufriedenheit wichtig. Sie ermöglichen den direkten Vergleich von Prozesskennzahlen wie Zykluszeit, Nacharbeit und Übergaben mit der Customer Experience. So lässt sich der geschäftliche Nutzen von Prozessverbesserungen belegen, indem die betriebliche Effizienz mit den Ergebnissen für Kunden verknüpft wird. Warum das wichtig ist Verknüpft die Prozessleistung direkt mit den Ergebnissen für Kunden und hilft, die Auswirkungen ineffizienter Abläufe auf die Benutzererfahrung zu quantifizieren. Woher beziehen In der Regel in einer verknüpften Survey-Tabelle [asmt_assessment_instance], die der ursprünglichen Anfrage zugeordnet ist. Beispiele 5431
	Zykluszeit des Cases CaseCycleTime	Die gesamte Zeit von der Erstellung bis zum endgültigen Abschluss einer Serviceanfrage.
Beschreibung Die Zykluszeit des Cases ist eine berechnete Kennzahl für die Gesamtdauer einer Serviceanfrage. Sie reicht vom Timestamp des ersten Ereignisses bis zum Timestamp des letzten Ereignisses und bildet die vollständige Bearbeitungszeit aus Sicht des Kunden ab. Diese zentrale KPI misst die Effizienz des Gesamtprozesses. Sie wird in übergeordneten Dashboards verwendet, um die Leistung anhand von Zielwerten zu überwachen und Trends im Zeitverlauf auszuwerten. Durch die Aufschlüsselung nach Dimensionen wie Kategorie oder Priorität lässt sich feststellen, welche Anfragetypen am längsten dauern. Warum das wichtig ist Diese wichtige KPI misst die Leistung des gesamten Prozesses. Sie ist für die übergeordnete Überwachung, den Benchmarking-Vergleich und die Ermittlung von Verbesserungsmöglichkeiten unverzichtbar. Woher beziehen Wird für jede eindeutige 'ServiceRequestID' berechnet, indem der minimale Wert von 'StartTime' vom maximalen Wert von 'EndTime' abgezogen wird. Beispiele 2 10:30:000 04:15:2210 00:05:00

Erforderlich Empfohlen Optional

Aktivitäten im Service-Request-Management

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess präzise zu entdecken und Engpässe zu identifizieren.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Anfrage einer Person zugewiesen	Diese Aktivität tritt ein, wenn eine bestimmte Person mit der Bearbeitung der Serviceanfrage betraut wird. Sie wird erfasst, indem Änderungen am Feld „Zugewiesen an“ in der Anfrage oder den zugehörigen Erfüllungsaufgaben überwacht werden.
Warum das wichtig ist Diese Information ist entscheidend, um Übergaben zu messen, die Arbeitslast einzelner Mitarbeitender zu berechnen und Wartezeiten zu analysieren, bevor eine Person mit der Bearbeitung beginnt. Woher beziehen Lässt sich an einer Änderung des Feldes assigned_to in der Tabelle sc_req_item oder sc_task erkennen. Der Änderungsverlauf wird in der Tabelle sys_audit protokolliert. Erfassung Verfolgen Sie Änderungen am Feld assigned_to in sys_audit. Ereignistyp inferred
	Anfrage freigegeben	Diese Aktivität zeigt an, dass die Anfrage offiziell freigegeben wurde und in die Erfüllungsphase übergehen kann. Sie wird erfasst, wenn eine freigebende Person den zugehörigen Freigabedatensatz als „freigegeben“ markiert.
Warum das wichtig ist Dieser wichtige Meilenstein markiert den Übergang von der Freigabe- zur Erfüllungsphase. Die Zeit bis zu diesem Schritt ist entscheidend, um Verzögerungen vor Beginn der Erfüllung zu verstehen. Woher beziehen Lässt sich daran erkennen, dass das Feld state des zugehörigen Datensatzes in sysapproval_approver zu „freigegeben“ wechselt. Dadurch wird anschließend eine Statusänderung in sc_req_item ausgelöst. Erfassung Ermitteln Sie den Timestamp, zu dem sysapproval_approver.state den Wert „freigegeben“ annimmt. Ereignistyp inferred
	Informationen beim Benutzer angefordert	Dieses Ereignis tritt ein, wenn die für die Erfüllung zuständige Person weitere Angaben von der ursprünglichen anfragenden Person benötigt. Es lässt sich in der Regel daran erkennen, dass der Status der Anfrage auf einen Wert wie „Warten auf Benutzerinformationen“ gesetzt wird.
Warum das wichtig ist Diese Aktivität ist entscheidend für das Dashboard „Analyse der Wartezeit auf Angaben der anfragenden Person“. Damit lässt sich die Zeit erfassen, die durch das Warten auf externe Informationen verloren geht. Woher beziehen Lässt sich daran erkennen, dass das Feld state in sc_req_item zu einem festgelegten Status für ausstehende Informationen wechselt. Die Änderung wird in der Tabelle sys_audit protokolliert. Erfassung Ermitteln Sie den Timestamp, zu dem sc_req_item.state zu „Warten auf Benutzerinformationen“ wechselt. Ereignistyp inferred
	Serviceanfrage erstellt	Diese Aktivität markiert den Beginn des Ablaufs einer Serviceanfrage. Sie wird protokolliert, wenn ein Benutzer eine Anfrage über den Servicekatalog einreicht. Das System erfasst sie als Erstellungsereignis eines neuen Datensatzes in der Tabelle sc_req_item (Requested Item).
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Es ist entscheidend, um die gesamte Zykluszeit zu berechnen und Anfragevolumen sowie Einreichungsmuster zu analysieren. Woher beziehen Dieses explizite Ereignis wird anhand des Erstellungs-Timestamp (Feld sys_created_on) des Datensatzes in der Tabelle sc_req_item erfasst. Erfassung Verwenden Sie den Timestamp sys_created_on des Datensatzes in sc_req_item. Ereignistyp explicit
	Serviceanfrage gelöst	Diese Aktivität zeigt an, dass die für die Erfüllung zuständige Person die Arbeit abgeschlossen und eine Lösung bereitgestellt hat. Sie wird erfasst, wenn der Status der Anfrage auf „Gelöst“ oder einen ähnlichen Wert gesetzt wird.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein, an dem die SLA-Zeitmessung in der Regel endet. Er markiert das Ende der aktiven Erfüllungsarbeit und fließt in die Berechnung der gesamten Lösungszeit ein. Woher beziehen Lässt sich daran erkennen, dass das Feld state in sc_req_item vor dem endgültigen Abschluss auf „Gelöst“ oder einen ähnlichen Endstatus gesetzt wird. Die Änderung wird in der Tabelle sys_audit protokolliert. Erfassung Ermitteln Sie den Timestamp, zu dem sc_req_item.state zu „Gelöst“ wechselt. Ereignistyp inferred
	Serviceanfrage geschlossen	Markiert das endgültige Ende des Ablaufs einer Serviceanfrage. Dies geschieht in der Regel automatisch, nachdem die Anfrage eine festgelegte Zeit lang den Status „Gelöst“ hatte. Während dieser Zeit kann der Benutzer sie erneut öffnen.
Warum das wichtig ist Dies ist das primäre erfolgreiche End-Event des Prozesses. Auch die Zeit zwischen „Gelöst“ und „Geschlossen“ lässt sich analysieren, um Richtlinien für den automatischen Abschluss zu bewerten. Woher beziehen Lässt sich daran erkennen, dass das Feld state in sc_req_item auf einen endgültigen Status wie „Vollständig geschlossen“ gesetzt wird. Die Änderung wird in der Tabelle sys_audit protokolliert. Erfassung Ermitteln Sie den Timestamp, zu dem sc_req_item.state zu „Vollständig geschlossen“ wechselt. Ereignistyp inferred
	Anfrage abgelehnt	Diese Aktivität steht für die formelle Ablehnung einer Anfrage während der Freigabephase. Sie bildet einen alternativen Weg zum Abschluss und wird erfasst, wenn eine freigebende Person die Anfrage als „abgelehnt“ markiert.
Warum das wichtig ist Die Erfassung von Ablehnungen hilft, ungültige oder falsch adressierte Anfragen sowie Probleme bei der Einreichung zu erkennen. Außerdem bildet sie einen wichtigen Ausnahmeweg für die Analyse ab. Woher beziehen Lässt sich daran erkennen, dass das Feld state des zugehörigen Datensatzes in sysapproval_approver zu „abgelehnt“ wechselt. Dadurch wird der übergeordnete Datensatz sc_req_item in der Regel auf einen geschlossenen, unvollständigen Status gesetzt. Erfassung Ermitteln Sie den Timestamp, zu dem sysapproval_approver.state den Wert „abgelehnt“ annimmt. Ereignistyp inferred
	Anfrage einer Gruppe zugewiesen	Zeigt an, dass die Serviceanfrage einem bestimmten Erfüllungsteam oder einer Gruppe zugewiesen wurde. Das Ereignis lässt sich an einer Änderung des Feldes für die Zuweisungsgruppe im Anfrageelement oder in den zugehörigen Aufgaben erkennen.
Warum das wichtig ist Die Erfassung von Gruppenzuweisungen hilft, die Arbeitsverteilung zwischen Teams zu analysieren und Verzögerungen zu erkennen, bevor eine Anfrage an die zuständigen Mitarbeitenden weitergeleitet wird. Woher beziehen Lässt sich an einer Änderung des Feldes assignment_group in der Tabelle sc_req_item oder sc_task erkennen. Der Änderungsverlauf wird in der Tabelle sys_audit protokolliert. Erfassung Verfolgen Sie Änderungen am Feld assignment_group in sys_audit. Ereignistyp inferred
	Anfrage erneut geöffnet	Diese Aktivität erfasst Fälle, in denen eine zuvor als gelöst markierte Anfrage wieder geöffnet wird. Sie lässt sich an einem Statuswechsel von „Gelöst“ zurück zu „In Bearbeitung“ oder einem ähnlichen Status erkennen.
Warum das wichtig ist Diese Aktivität misst Nacharbeit direkt und ist entscheidend für die Berechnung der KPI „Lösungsquote beim ersten Versuch“. Hohe Werte weisen auf eine unzureichende Lösungsqualität oder einen unvollständigen Abschluss hin. Woher beziehen Lässt sich an einer Änderung des Feldes state in sc_req_item erkennen, wenn die Anfrage von einem gelösten oder geschlossenen Status zurück in einen offenen oder laufenden Status wechselt. Die Änderung wird in sys_audit protokolliert. Erfassung Erkennen Sie in sys_audit einen Statuswechsel von „Gelöst“ zu „In Bearbeitung“. Ereignistyp inferred
	Anfrage storniert	Diese Aktivität markiert den Endstatus von Anfragen, die vor dem Abschluss storniert werden, entweder durch den Benutzer oder eine zuständige Person. Sie wird erfasst, wenn der Status der Anfrage auf „Storniert“ oder „Geschlossen, storniert“ gesetzt wird.
Warum das wichtig ist Dies ist ein wichtiges erfolgloses End-Event. Die Analyse der Stornierungsgründe kann Erkenntnisse zu den Bedürfnissen der Benutzer, Ineffizienzen im Prozess oder veränderten geschäftlichen Prioritäten liefern. Woher beziehen Lässt sich daran erkennen, dass das Feld state in sc_req_item auf einen endgültigen Stornierungsstatus wie „Geschlossen, storniert“ gesetzt wird. Die Änderung wird in der Tabelle sys_audit protokolliert. Erfassung Ermitteln Sie den Timestamp, zu dem sc_req_item.state zu „Storniert“ wechselt. Ereignistyp inferred
	Erfüllungsaufgabe erstellt	Markiert die Erstellung eines konkreten Arbeitselements oder einer Aufgabe, die zur Erfüllung der Serviceanfrage erforderlich ist. Dieses explizite Ereignis wird protokolliert, wenn ein neuer Datensatz in der Tabelle Catalog Task erstellt wird.
Warum das wichtig ist Bei komplexen Anfragen bietet die Analyse der Erstellung und des Abschlusses einzelner Aufgaben einen detaillierteren Einblick in den Erfüllungsprozess und die Stellen, an denen Verzögerungen auftreten. Woher beziehen Dieses explizite Ereignis wird anhand des Erstellungs-Timestamp (Feld sys_created_on) eines Datensatzes in der Tabelle sc_task erfasst, der mit sc_req_item verknüpft ist. Erfassung Verwenden Sie den Timestamp sys_created_on der Datensätze in sc_task. Ereignistyp explicit
	Externer Anbieter eingebunden	Markiert die Übergabe einer Serviceanfrage oder einer zugehörigen Aufgabe an einen externen Anbieter zur Erfüllung. Dies lässt sich an der Zuweisung zu einer anbieterspezifischen Gruppe oder an einer Kennzeichnung in der Anfrage erkennen.
Warum das wichtig ist Diese Aktivität ermöglicht die Analyse der Anbieterleistung und ihrer Auswirkungen auf den gesamten Ablauf der Anfrage. Sie ist entscheidend für das Dashboard „Zyklus der Einbindung externer Anbieter“. Woher beziehen Dieses Ereignis wird in der Regel abgeleitet. Grundlage kann die Zuweisung des Feldes assignment_group zu einer Anbietergruppe oder ein bestimmtes Kennzeichnungsfeld im Datensatz sc_req_item oder sc_task sein. Erfassung Ermitteln Sie, wann assignment_group zu einer bekannten Anbietergruppe wechselt. Ereignistyp inferred
	Freigabe angefordert	Markiert den Zeitpunkt, zu dem eine Serviceanfrage einer Führungskraft oder einer anderen zuständigen Person zur Freigabe vorgelegt wird. Dies lässt sich in der Regel daran erkennen, dass der Status der Anfrage zu „Freigabe ausstehend“ oder einem ähnlichen Wert wechselt.
Warum das wichtig ist Die Erfassung von Freigaben hilft, Engpässe im Freigabeprozess zu erkennen und zu messen, wie lange Anfragen auf die Autorisierung warten, bevor die Erfüllung beginnen kann. Woher beziehen Lässt sich daran erkennen, dass das Feld state in sc_req_item auf einen Wert für eine ausstehende Freigabe wechselt, oder an der Erstellung eines zugehörigen Datensatzes in der Tabelle sysapproval_approver. Änderungen werden in der Tabelle sys_audit protokolliert. Erfassung Ermitteln Sie den Timestamp, zu dem sc_req_item.state zu „Freigabe ausstehend“ wechselt. Ereignistyp inferred
	Informationen vom Benutzer erhalten	Diese Aktivität markiert den Zeitpunkt, zu dem die anfragende Person die benötigten Informationen bereitgestellt hat. Sie lässt sich daran erkennen, dass die Anfrage den Status „Warten auf Benutzerinformationen“ verlässt und wieder einen aktiven Status wie „In Bearbeitung“ annimmt.
Warum das wichtig ist In Verbindung mit „Informationen beim Benutzer angefordert“ ermöglicht diese Aktivität eine genaue Messung von Verzögerungen, die durch ausstehende Benutzerangaben entstehen. Außerdem hilft sie, die Effizienz des Informationsaustauschs zu bewerten. Woher beziehen Lässt sich daran erkennen, dass das Feld state in sc_req_item von einem Status für ausstehende Informationen zu einem aktiven Status wechselt. Häufig wird dies dadurch ausgelöst, dass der Benutzer einen Kommentar hinzufügt oder auf eine E-Mail antwortet. Erfassung Ermitteln Sie den Timestamp, zu dem der Status von „Warten auf Benutzerinformationen“ zu „In Bearbeitung“ wechselt. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus ServiceNow

Schritte

Den Export aus mehreren Tabellen verstehen: Aufgrund des Datenmodells von ServiceNow lassen sich nicht alle benötigten Ereignisse mit einem einzigen Export erfassen. Exportieren Sie Daten aus mehreren Tabellen und führen Sie sie anschließend außerhalb von ServiceNow zusammen. Die wichtigsten Tabellen sind Requested Item (sc_req_item), Approval (sysapproval_approver), Catalog Task (sc_task) und Audit (sys_audit).
Export 1: Zentrale Daten zu Serviceanfragen: Öffnen Sie die Tabelle Requested Item, indem Sie sc_req_item.list in den Filter-Navigator eingeben. Filtern Sie nach dem gewünschten Zeitraum, zum Beispiel [Created] [on] [Last 6 months]. Fügen Sie Spalten wie Anzahl, Sys Created On, Resolved, Closed, State, Assignment group, Assigned to und Made SLA hinzu. Klicken Sie mit der rechten Maustaste auf eine Spaltenüberschrift, wählen Sie Export und anschließend CSV oder XLSX.
Export 2: Genehmigungsentscheidungen: Öffnen Sie die Tabelle Approval, indem Sie sysapproval_approver.list eingeben. Filtern Sie die Liste nach Einträgen zu Serviceanfragen: [Source table] [is] [sc_req_item] AND [Created] [on] [Last 6 months]. Fügen Sie Spalten wie Approving.Number, State, Sys Created On und Sys Updated On hinzu. Exportieren Sie die gefilterte Liste.
Export 3: Erstellung von Fulfillment-Aufgaben: Öffnen Sie die Tabelle Catalog Task, indem Sie sc_task.list eingeben. Filtern Sie die Liste so, dass sie nur Anfragen aus dem gewählten Zeitraum enthält, zum Beispiel [Request Item.Created] [on] [Last 6 months]. Fügen Sie die Spalten Request Item.Number, Sys Created On, State, Assignment group und Assigned to hinzu. Exportieren Sie die Daten.
Export 4: Detaillierter Aktivitätsverlauf: Öffnen Sie die Tabelle Audit über sys_audit.list. Diese Tabelle enthält den Verlauf von Feldänderungen. Erstellen Sie einen Filter für [Table name] [is] [sc_req_item] AND [Created] [on] [Last 6 months] AND [Field name] [is one of] [state, assignment_group, assigned_to]. Fügen Sie die Spalten Document key, Field name, Old value, New value und Sys Created On hinzu. Exportieren Sie die Daten. Für den Zugriff auf diese Tabelle sind möglicherweise erweiterte Berechtigungen erforderlich.
Daten zusammenführen und umwandeln: Führen Sie die vier exportierten Dateien mit einem Tool wie Microsoft Excel, Python mit pandas oder einem speziellen Tool zur Datenaufbereitung zusammen. Verwenden Sie die Service-Request-Nummer oder die Sys ID als gemeinsamen Schlüssel.
Struktur des Event Logs erstellen: Legen Sie in der zusammengeführten Datei die erforderlichen Spalten ServiceRequestID, ActivityName und EventTime an.
Rohdaten den Aktivitäten zuordnen: Erstellen Sie für jede einzelne Aktivität eine neue Zeile. Zum Beispiel:
- Verwenden Sie für Service Request Created den Wert aus Sys Created On des Exports von sc_req_item.
- Verwenden Sie für Request Approved den Wert aus Sys Updated On des Exports von sysapproval_approver, wenn sich State in „approved“ geändert hat.
- Suchen Sie für Request Assigned to Group im Export von sys_audit die Zeile, in der Field name den Wert assignment_group hat. Verwenden Sie den Wert aus Sys Created On dieses Audit-Eintrags als EventTime.
Attributspalten ausfüllen: Tragen Sie für jede Aktivitätszeile die Attribute AssignedTo, AssignmentGroup, Priority, State, Category und MadeSLA ein. Die Werte sollten den Zustand der Anfrage zum Zeitpunkt des Ereignisses wiedergeben.
Metadatenspalten hinzufügen: Fügen Sie SourceSystem mit einem festen Wert wie „ServiceNow“ und LastDataUpdate mit dem Timestamp der Datenextraktion hinzu.
Daten fertigstellen und exportieren: Speichern Sie die umgewandelten und zusammengeführten Daten als einzelne CSV-Datei. Achten Sie darauf, dass die Spaltenüberschriften den Importanforderungen entsprechen.

Konfiguration

Zieltabellen: Für die Extraktion werden Daten aus mehreren Tabellen benötigt:
- sc_req_item: Enthält die primären Datensätze zu Serviceanfragen (Requested Item).
- sysapproval_approver: Enthält Genehmigungsdatensätze zu Anfragen.
- sc_task: Enthält die einzelnen Bearbeitungsaufgaben, die für eine Anfrage erstellt wurden.
- sys_audit: Enthält einen detaillierten Verlauf von Feldänderungen, der für die Nachverfolgung von Zuweisungen und Statusänderungen erforderlich ist.
Filter für den Zeitraum: Wenden Sie bei allen Exporten denselben Zeitraumfilter an, zum Beispiel Created on Last 6 months, damit die Daten konsistent bleiben. Für ein ausgewogenes Verhältnis zwischen Datenumfang und Erkenntnisgewinn empfiehlt sich ein Zeitraum von 3 bis 6 Monaten.
Wichtige Filter: Verwenden Sie zusätzlich zum Zeitraum Filter wie Source table is sc_req_item für die Genehmigungstabelle und Table name is sc_req_item für die Audit-Tabelle, um relevante Datensätze einzugrenzen.
Erforderliche Spalten: Exportieren Sie wichtige Kennungen wie Anzahl und Sys ID (in der Audit-Tabelle als document key), damit Sie die Datensätze zusammenführen können. Timestamps wie Sys Created On, Sys Updated On, Gelöst und Geschlossen sind für die Erstellung des Event Logs unverzichtbar.
Voraussetzungen: Für den Zugriff auf die meisten benötigten Tabellen ist ein ServiceNow-Benutzerkonto mit mindestens der Rolle itil erforderlich. Für den Export aus der Tabelle sys_audit benötigen Sie aufgrund ihres Umfangs und der Sensibilität der Daten möglicherweise die Rolle admin oder eine spezielle Rolle.

a Beispielabfrage config

This method uses the ServiceNow user interface for filtering and exporting, so there is no single script. The configuration consists of setting filters and choosing columns for multiple list views.

**Configuration for Export 1: Requested Items**
*   **Table**: `sc_req_item`
*   **Filter Conditions**:
    1. `[Created] [on] [Last 6 months]`
    2. `[Active] [is one of] [true, false]` (Or adjust based on process scope)
*   **Columns to Add**: `Number`, `Sys ID`, `Sys Created On`, `Resolved`, `Closed`, `State`, `Stage`, `Assignment group`, `Assigned to`, `Priority`, `Category`, `Made SLA`

**Configuration for Export 2: Approvals**
*   **Table**: `sysapproval_approver`
*   **Filter Conditions**:
    1. `[Source table] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
*   **Columns to Add**: `Approving`, `Approving.Number`, `State`, `Sys Created On`, `Sys Updated On`

**Configuration for Export 3: Catalog Tasks**
*   **Table**: `sc_task`
*   **Filter Conditions**:
    1. `[Request Item.Created] [on] [Last 6 months]`
*   **Columns to Add**: `Request Item`, `Request Item.Number`, `Sys Created On`, `Sys Updated On`, `State`, `Assignment group`, `Assigned to`

**Configuration for Export 4: Audit History**
*   **Table**: `sys_audit`
*   **Filter Conditions**:
    1. `[Table name] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
    3. `[Field name] [is one of] [state, assignment_group, assigned_to]`
*   **Columns to Add**: `Document key`, `Table name`, `Field name`, `Old value`, `New value`, `Sys Created On`

Schritte

Python-Umgebung vorbereiten: Stellen Sie sicher, dass Python 3.6 oder eine neuere Version installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas.
Skriptparameter konfigurieren: Öffnen Sie das Python-Skript in einem Editor. Suchen Sie den Konfigurationsabschnitt am Anfang des Skripts. Tragen Sie die URL Ihrer ServiceNow-Instanz ein, zum Beispiel https://your-instance.service-now.com, sowie Benutzername und Passwort eines Servicekontos mit den erforderlichen Leseberechtigungen für die benötigten Tabellen.
Zeitraum für die Extraktion festlegen: Legen Sie den Beginn und das Ende des Extraktionszeitraums fest, indem Sie die Variablen start_date und end_date anpassen. Testen Sie das Skript zunächst mit einem kürzeren Zeitraum, zum Beispiel drei Monaten, und prüfen Sie die Leistung.
Tabellen- und Feldnamen prüfen: Das Skript verwendet standardmäßige ServiceNow-Tabellennamen wie sc_req_item, sys_audit und sc_task. Prüfen Sie, ob diese Tabellen- und Feldnamen Ihrer ServiceNow-Konfiguration entsprechen. Passen Sie sie im Skript an, wenn Ihre Instanz benutzerdefinierte Tabellen oder Felder verwendet.
Python-Skript ausführen: Starten Sie das Skript über die Befehlszeile oder das Terminal mit dem Befehl python your_script_name.py. Das Skript verbindet sich mit der ServiceNow-API, ruft Daten für die angegebenen Aktivitäten ab und zeigt den Fortschritt in der Konsole an.
API-Seitennummerierung verarbeiten: Das Skript enthält eine Funktion zur automatischen Seitennummerierung. Wenn die Anzahl der Einträge das Seitenlimit (sysparm_limit) überschreitet, führt es mehrere API-Aufrufe aus, bis alle Daten für den angegebenen Zeitraum abgerufen sind.
Daten umwandeln und zusammenführen: Das Skript verarbeitet die Rohdaten aus der JSON-Antwort der API für jeden Aktivitätstyp. Es extrahiert die erforderlichen Felder, ordnet sie dem Event-Log-Schema (ServiceRequestID, ActivityName, EventTime usw.) zu und führt sie in einem einheitlichen Datensatz zusammen.
Event-Log-Datei erstellen: Nach Abschluss des Skripts wird das fertige Event Log als CSV-Datei servicenow_servicerequest_eventlog.csv im selben Verzeichnis gespeichert, aus dem Sie das Skript gestartet haben.
Upload vorbereiten: Öffnen Sie die erstellte CSV-Datei in einem Tabellenkalkulationsprogramm und prüfen Sie die Daten auf Vollständigkeit und Richtigkeit. Achten Sie vor dem Upload darauf, dass die Spaltenüberschriften dem ProcessMind-Schema entsprechen.

Konfiguration

URL der ServiceNow-Instanz: Die Basis-URL Ihrer ServiceNow-Instanz, zum Beispiel https://your-instance.service-now.com.
Authentifizierung: Erforderlich sind Benutzername und Passwort eines Servicekontos mit Lesezugriff auf die Tabellen sc_req_item, sys_audit, sysapproval_approver und sc_task.
Zeitraum: Legen Sie im Skript mit den Variablen start_date und end_date den Zeitraum für die Extraktion fest. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten.
Seitenlimit (sysparm_limit): Das Skript begrenzt die Anzahl der Einträge, die pro API-Aufruf zurückgegeben werden. Der Standardwert beträgt 1000 und eignet sich für die meisten Instanzen. Passen Sie ihn je nach Systemleistung und API-Ratenbegrenzungen an.
Abfragefilter (sysparm_query): Das Skript verwendet Datumsfilter (sys_created_on>=...), um den Datenabruf zu begrenzen. Ergänzen Sie die Abfragezeichenfolge um weitere Filter, zum Beispiel nach einem bestimmten Katalogeintrag oder einer Zuweisungsgruppe, um das Datenvolumen zu verringern (active=true^category=hardware).
Anzeigewerte: Mit dem Parameter sysparm_display_value=true werden für Referenzfelder lesbare Namen statt interner sys_id-Werte abgerufen. Das ist besonders wichtig für Attribute wie AssignmentGroup und AssignedTo.

a Beispielabfrage python

import requests
import pandas as pd
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
SN_INSTANCE = class="hl-string">'https://[your-instance].service-now.com'
SN_USER = class="hl-string">'[your-username]'
SN_PASSWORD = class="hl-string">'[your-password]'

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD)
start_date = class="hl-string">'[YYYY-MM-DD]'
end_date = class="hl-string">'[YYYY-MM-DD]'

class=class="hl-string">"hl-comment"># --- End Configuration ---

def query_servicenow_table(table, query, fields):
    class="hl-string">"""Queries a ServiceNow table with pagination."""
    all_records = []
    offset = 0
    limit = 1000
    
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    url = fclass="hl-string">"{SN_INSTANCE}/api/now/table/{table}"
    
    while True:
        params = {
            class="hl-string">'sysparm_query': query,
            class="hl-string">'sysparm_fields': class="hl-string">','.join(fields),
            class="hl-string">'sysparm_limit': limit,
            class="hl-string">'sysparm_offset': offset,
            class="hl-string">'sysparm_display_value': class="hl-string">'true',
            class="hl-string">'sysparm_exclude_reference_link': class="hl-string">'true'
        }
        
        print(fclass="hl-string">"Querying {table} with offset {offset}...")
        response = requests.get(url, auth=(SN_USER, SN_PASSWORD), headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
        
        records = response.json().get(class="hl-string">'result', [])
        if not records:
            break
        all_records.extend(records)
        offset += limit
        
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    all_events = []
    source_system = class="hl-string">'ServiceNow'
    last_data_update = datetime.datetime.now().isoformat()

    class=class="hl-string">"hl-comment"># Define common attributes to fetch for context
    context_fields = [class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state', class="hl-string">'cat_item.category', class="hl-string">'made_sla']

    class=class="hl-string">"hl-comment"># 1. Service Request Created
    query = fclass="hl-string">'sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    fields = [class="hl-string">'sys_created_on'] + context_fields
    req_items = query_servicenow_table(class="hl-string">'sc_req_item', query, fields)
    for item in req_items:
        all_events.append({
            class="hl-string">'ServiceRequestID': item[class="hl-string">'number'],
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': item[class="hl-string">'sys_created_on'],
            class="hl-string">'AssignedTo': item.get(class="hl-string">'assigned_to'),
            class="hl-string">'AssignmentGroup': item.get(class="hl-string">'assignment_group'),
            class="hl-string">'Priority': item.get(class="hl-string">'priority'),
            class="hl-string">'State': item.get(class="hl-string">'state'),
            class="hl-string">'Category': item.get(class="hl-string">'cat_item.category'),
            class="hl-string">'MadeSLA': item.get(class="hl-string">'made_sla')
        })

    class=class="hl-string">"hl-comment"># Get a list of relevant document keys (sys_id of sc_req_item)
    doc_keys_query = fclass="hl-string">'tablename=sc_req_item^sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    audit_records = query_servicenow_table(class="hl-string">'sys_audit', doc_keys_query, [class="hl-string">'documentkey'])
    relevant_doc_keys = list(set([rec[class="hl-string">'documentkey'] for rec in audit_records]))
    
    class=class="hl-string">"hl-comment"># Query audit and other tables in batches to avoid long URLs
    batch_size = 50
    for i in range(0, len(relevant_doc_keys), batch_size):
        key_batch = relevant_doc_keys[i:i+batch_size]
        key_batch_str = class="hl-string">','.join(key_batch)

        class=class="hl-string">"hl-comment"># 2-14. Activities from sys_audit, sysapproval_approver, sc_task
        class=class="hl-string">"hl-comment"># Fetch sc_req_item details for context
        ritm_context = {ritm[class="hl-string">'sys_id']: ritm for ritm in query_servicenow_table(class="hl-string">'sc_req_item', fclass="hl-string">'sys_idIN{key_batch_str}', [class="hl-string">'sys_id'] + context_fields)}

        class=class="hl-string">"hl-comment"># Activities based on state changes and field updates from sys_audit
        audit_query = fclass="hl-string">'documentkeyIN{key_batch_str}^fieldnameINassignment_group,assigned_to,state'
        audit_log = query_servicenow_table(class="hl-string">'sys_audit', audit_query, [class="hl-string">'documentkey', class="hl-string">'sys_created_on', class="hl-string">'fieldname', class="hl-string">'newvalue', class="hl-string">'oldvalue'])
        for log in audit_log:
            context = ritm_context.get(log[class="hl-string">'documentkey'], {})
            if not context:
                continue

            event = {
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'EventTime': log[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'),
                class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'),
                class="hl-string">'Priority': context.get(class="hl-string">'priority'),
                class="hl-string">'State': context.get(class="hl-string">'state'),
                class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'),
                class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla'),
            }
            activity = None
            class=class="hl-string">"hl-comment"># Map audit entries to activities
            if log[class="hl-string">'fieldname'] == class="hl-string">'assignment_group' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Group'
                event[class="hl-string">'AssignmentGroup'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'assigned_to' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Agent'
                event[class="hl-string">'AssignedTo'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'state':
                class=class="hl-string">"hl-comment"># Define state mappings, may need customization
                state_map = {
                    class="hl-string">'Awaiting User Info': class="hl-string">'Information Requested from User',
                    class="hl-string">'Resolved': class="hl-string">'Service Request Resolved',
                    class="hl-string">'Closed Complete': class="hl-string">'Service Request Closed',
                    class="hl-string">'Closed Cancelled': class="hl-string">'Request Cancelled'
                }
                if log[class="hl-string">'newvalue'] in state_map:
                    activity = state_map[log[class="hl-string">'newvalue']]
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Awaiting User Info':
                    activity = class="hl-string">'Information Provided by User'
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Resolved':
                    activity = class="hl-string">'Request Reopened'
                class=class="hl-string">"hl-comment"># For class="hl-string">'Approval Requested', class="hl-string">'External Vendor Engaged' - more complex logic might be needed
                class=class="hl-string">"hl-comment"># This is a common inference. Adjust if you have a specific state.
                if log[class="hl-string">'newvalue'] == class="hl-string">'Pending Approval':
                     activity = class="hl-string">'Approval Requested'

            if activity:
                event[class="hl-string">'ActivityName'] = activity
                all_events.append(event)

        class=class="hl-string">"hl-comment"># Approval Activities
        approval_query = fclass="hl-string">'sysapprovalIN{key_batch_str}'
        approvals = query_servicenow_table(class="hl-string">'sysapproval_approver', approval_query, [class="hl-string">'sysapproval', class="hl-string">'sys_updated_on', class="hl-string">'state'])
        for appr in approvals:
            context = ritm_context.get(appr[class="hl-string">'sysapproval'], {})
            if not context: continue
            activity = None
            if appr[class="hl-string">'state'] == class="hl-string">'approved':
                activity = class="hl-string">'Request Approved'
            elif appr[class="hl-string">'state'] == class="hl-string">'rejected':
                activity = class="hl-string">'Request Rejected'
            if activity:
                all_events.append({
                    class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': appr[class="hl-string">'sys_updated_on'],
                    class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
                })

        class=class="hl-string">"hl-comment"># Fulfillment Task Creation
        task_query = fclass="hl-string">'request_itemIN{key_batch_str}'
        tasks = query_servicenow_table(class="hl-string">'sc_task', task_query, [class="hl-string">'request_item', class="hl-string">'sys_created_on', class="hl-string">'number'])
        for task in tasks:
            context = ritm_context.get(task[class="hl-string">'request_item'], {})
            if not context: continue
            all_events.append({
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'ActivityName': fclass="hl-string">'Fulfillment Task Created - {task["number"]}',
                class="hl-string">'EventTime': task[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
            })

    class=class="hl-string">"hl-comment"># Post-processing and saving
    if not all_events:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = source_system
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to match schema
    final_cols = [class="hl-string">'ServiceRequestID', 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">'State', class="hl-string">'Category', class="hl-string">'MadeSLA']
    df = df[final_cols]
    
    df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], inplace=True)
    df.to_csv(class="hl-string">'servicenow_servicerequest_eventlog.csv', index=False)
    print(class="hl-string">"Extraction complete. File saved to servicenow_servicerequest_eventlog.csv")

if __name__ == class="hl-string">'__main__':
    main()

Schritte

ServiceNow-API-Benutzer einrichten: Erstellen Sie in Ihrer ServiceNow-Instanz einen eigenen Benutzer für diese Integration. Weisen Sie ihm die Rollen rest_service und itil zu. Stellen Sie sicher, dass der Benutzer über Leseberechtigungen (ACLs) für folgende Tabellen verfügt: Requested Item (sc_req_item), Catalog Task (sc_task), Approval (sysapproval_approver) und Audit (sys_audit).
Entwicklungsumgebung vorbereiten: Installieren Sie Node.js auf dem Rechner, den Sie für die Extraktion verwenden. Initialisieren Sie anschließend ein neues Node.js-Projekt und installieren Sie mit npm install axios fast-csv im Terminal die Bibliothek axios für HTTP-Anfragen und fast-csv zum Schreiben der Ausgabedatei.
Extraktionsskript konfigurieren: Kopieren Sie den bereitgestellten JavaScript-Code in eine Datei, zum Beispiel extract.js. Ersetzen Sie die Platzhalter am Anfang des Skripts durch die URL Ihrer ServiceNow-Instanz sowie den API-Benutzernamen und das Passwort.
Zeitraum und Filter festlegen: Passen Sie die Variablen startDate und endDate im Skript an, um den Extraktionszeitraum festzulegen. Ergänzen Sie bei Bedarf die Zeichenfolgen sysparm_query für die einzelnen Aktivitäten um weitere Filter, etwa nach einem bestimmten Katalogeintrag oder einer Zuweisungsgruppe.
API-Aufrufe verstehen: Das Skript führt für jede der 14 erforderlichen Aktivitäten einen eigenen API-Aufruf aus. Ereignisse wie die Erstellung werden direkt aus den Quelltabellen (sc_req_item, sc_task) abgerufen. Statusänderungen und Zuweisungen ermittelt das Skript anhand bestimmter Feldänderungen in der Tabelle sys_audit.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl node extract.js. Es verbindet sich mit der ServiceNow Table API, ruft die Daten für jede Aktivität ab und verarbeitet die Seitennummerierung automatisch.
Daten verarbeiten: Während des Abrufs wandelt das Skript die JSON-Antwort von ServiceNow in ein standardisiertes Event-Log-Format um. Dabei ordnet es Felder Spalten wie ServiceRequestID, ActivityName und EventTime zu.
Ergebnisse zusammenführen: Das Skript führt die Ergebnisse aller einzelnen API-Aufrufe in einem einheitlichen Array zusammen, das das vollständige Event Log enthält.
Ausgabedatei erstellen: Nachdem alle Daten abgerufen und verarbeitet wurden, schreibt das Skript das zusammengeführte Event Log mit der Bibliothek fast-csv in die Datei servicenow_event_log.csv im selben Verzeichnis.
Upload vorbereiten: Die erstellte CSV-Datei enthält die erforderlichen Spalten für Process Mining. Vor dem Upload auf die ProcessMind-Plattform sind keine weiteren Formatierungsarbeiten nötig.

Konfiguration

URL der ServiceNow-Instanz: Die Basis-URL Ihrer ServiceNow-Umgebung, zum Beispiel https://your-instance.service-now.com.
API-Zugangsdaten: Gültiger Benutzername und gültiges Passwort eines ServiceNow-Benutzers mit den erforderlichen Leseberechtigungen und Rollen (rest_service, itil).
Zeitraum: Für einen repräsentativen Datensatz empfehlen wir, Daten aus einem Zeitraum von 3 bis 6 Monaten zu extrahieren. Legen Sie diesen Zeitraum im Skript über die Variablen startDate und endDate fest. Die Werte werden auf die entsprechenden Timestamp-Felder in den API-Abfragen angewendet.
sysparm_query: Dieser URL-Parameter dient hauptsächlich zum Filtern von Einträgen. Das Skript verwendet ihn unter anderem, um bestimmte Ereignisse herauszufiltern, etwa Einträge, die innerhalb eines Zeitraums erstellt wurden, oder Audit-Einträge zu einer Statusänderung von „Resolved“ zu „Work in Progress“.
sysparm_fields: Mit diesem Parameter legen Sie fest, welche Spalten der API-Aufruf zurückgibt. Die Datenmenge und damit die Übertragungszeit sinken deutlich, wenn Sie nur die benötigten Felder abrufen. Das Skript enthält bereits die erforderlichen Felder für jede Abfrage.
Seitennummerierungslimit (sysparm_limit): Das Skript ruft Einträge in Paketen zu je 1000 ab. Sie können diesen Wert anpassen. Für eine zuverlässige Ausführung empfiehlt sich jedoch ein Wert unterhalb des ServiceNow-Maximums, das üblicherweise bei 10.000 liegt.

a Beispielabfrage javascript

const axios = require('axios');
const fs = require('fs');
const { format, writeToStream } = require('@fast-csv/format');

// --- Configuration ---
const SN_INSTANCE = 'https://YOUR_INSTANCE.service-now.com';
const SN_USER = 'YOUR_API_USER';
const SN_PASSWORD = 'YOUR_API_PASSWORD';
const BATCH_SIZE = 1000;

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

const auth = { username: SN_USER, password: SN_PASSWORD };

// --- Helper Function for Paginated API Calls ---
async function fetchAllRecords(table, query, fields, processFunction) {
    let offset = 0;
    let hasMore = true;
    let allEvents = [];

    console.log(`Starting fetch for table: ${table}`);

    while (hasMore) {
        try {
            const response = await axios.get(`${SN_INSTANCE}/api/now/table/${table}`, {
                auth,
                params: {
                    sysparm_query: query,
                    sysparm_fields: fields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset,
                    sysparm_display_value: 'true', // Get display values for reference fields
                    sysparm_exclude_reference_link: true
                }
            });

            const records = response.data.result;
            if (records.length > 0) {
                console.log(`Fetched ${records.length} records from ${table} with offset ${offset}`);
                const processedEvents = records.map(processFunction);
                allEvents.push(...processedEvents);
                offset += BATCH_SIZE;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching data from ${table}:`, error.response ? error.response.statusText : error.message);
            hasMore = false; // Stop on error
        }
    }
    return allEvents;
}

// --- Main Extraction Logic ---
async function extractServiceRequestData() {
    let finalEventLog = [];
    const now = new Date().toISOString();

    // 1. Service Request Created
    const createdEvents = await fetchAllRecords(
        'sc_req_item',
        `sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'number,sys_created_on,assigned_to,assignment_group,priority,state,cat_item.category,made_sla',
        (r) => ({
            ServiceRequestID: r.number,
            ActivityName: 'Service Request Created',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: r.assigned_to,
            AssignmentGroup: r.assignment_group,
            Priority: r.priority,
            State: r.state,
            Category: r['cat_item.category'],
            MadeSLA: r.made_sla
        })
    );
    finalEventLog.push(...createdEvents);

    // 2. Approval Requested
    const approvalRequestedEvents = await fetchAllRecords(
        'sysapproval_approver',
        `sysapproval.sys_class_name=sc_req_item^state=requested^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'sysapproval,sys_created_on',
        (r) => ({
            ServiceRequestID: r.sysapproval,
            ActivityName: 'Approval Requested',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Pending Approval', Category: null, MadeSLA: null
        })
    );
    finalEventLog.push(...approvalRequestedEvents);

    // Function to process audit records
    const processAuditRecord = (activityName) => (r) => ({
        ServiceRequestID: r['documentkey.number'],
        ActivityName: activityName,
        EventTime: r.sys_created_on,
        SourceSystem: 'ServiceNow',
        LastDataUpdate: now,
        AssignedTo: activityName === 'Request Assigned to Agent' ? r.newvalue : null,
        AssignmentGroup: activityName === 'Request Assigned to Group' ? r.newvalue : null,
        Priority: null, 
        State: ['Service Request Resolved', 'Service Request Closed', 'Request Cancelled', 'Request Reopened', 'Information Requested from User', 'Information Provided by User'].includes(activityName) ? r.newvalue : null,
        Category: null, 
        MadeSLA: null
    });
    
    // 3. Request Approved
    const approvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=approved^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Approved', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Approved', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...approvedEvents);

    // 4. Request Assigned to Group
    const assignedGroupEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Group')
    );
    finalEventLog.push(...assignedGroupEvents);

    // 5. Request Assigned to Agent
    const assignedAgentEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assigned_to^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Agent')
    );
    finalEventLog.push(...assignedAgentEvents);

    // 6. Fulfillment Task Created
    const taskCreatedEvents = await fetchAllRecords(
        'sc_task',
        `request_item.sys_class_name=sc_req_item^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'request_item.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['request_item.number'], ActivityName: 'Fulfillment Task Created', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: null, Category: null, MadeSLA: null })
    );
    finalEventLog.push(...taskCreatedEvents);

    // 7. Information Requested from User
    const infoRequestedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Requested from User')
    );
    finalEventLog.push(...infoRequestedEvents);

    // 8. Information Provided by User
    const infoProvidedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Provided by User')
    );
    finalEventLog.push(...infoProvidedEvents);

    // 9. External Vendor Engaged (Note: requires a specific vendor group name)
    const vendorEngagedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^newvalue=[Your Vendor Assignment Group Name]^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('External Vendor Engaged')
    );
    finalEventLog.push(...vendorEngagedEvents);

    // 10. Request Reopened
    const reopenedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Resolved^newvalue=Work in Progress^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Reopened')
    );
    finalEventLog.push(...reopenedEvents);

    // 11. Service Request Resolved
    const resolvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Resolved^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Resolved')
    );
    finalEventLog.push(...resolvedEvents);

    // 12. Service Request Closed
    const closedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalueINClosed Complete,Closed Incomplete,Closed Skipped^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Closed')
    );
    finalEventLog.push(...closedEvents);

    // 13. Request Rejected
    const rejectedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=rejected^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Rejected', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Rejected', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...rejectedEvents);

    // 14. Request Cancelled
    const cancelledEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Cancelled^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Cancelled')
    );
    finalEventLog.push(...cancelledEvents);

    // --- Write to CSV ---
    const csvStream = format({ headers: true });
    const writableStream = fs.createWriteStream('servicenow_event_log.csv');

    writableStream.on('finish', () => {
        console.log('CSV file written successfully.');
    });

    csvStream.pipe(writableStream);
    finalEventLog.sort((a, b) => new Date(a.EventTime) - new Date(b.EventTime)); // Sort events chronologically
    finalEventLog.forEach(row => csvStream.write(row));
    csvStream.end();
}

extractServiceRequestData();

Möchten Sie loslegen?

Verwenden Sie dieses Template als Ausgangspunkt für Ihr Process-Mining-Vorhaben und erschließen Sie Effizienzpotenziale im Service-Request-Management. Optimieren Sie Ihre Workflows, um Anfragen schneller zu lösen und die Kundenzufriedenheit zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Service-Request-Management verbessern: Jetzt handeln

Erreichen Sie eine Automatisierungsquote von 70 % und lösen Sie Serviceanfragen schneller.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für das Serviceanfragemanagement

Ihr Daten-Template für das Serviceanfragemanagement

Attribute des Service-Request-Managements

Aktivitäten im Service-Request-Management

Anleitungen zur Datenextraktion

ServiceNow-Berichte und Listen als CSV/XLSX exportieren

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript zur Extraktion über die Table API mit Requests

Schritte

Konfiguration

a Beispielabfrage python

Datenextraktion über die ServiceNow-REST-Table-API

Schritte

Konfiguration

a Beispielabfrage javascript

Möchten Sie loslegen?

Service-Request-Management verbessern: Jetzt handeln

Ihr Daten-Template für das Serviceanfragemanagement

Ihr Daten-Template für das Serviceanfragemanagement

Attribute des Service-Request-Managements

Aktivitäten im Service-Request-Management

Anleitungen zur Datenextraktion

ServiceNow-Berichte und Listen als CSV/XLSX exportieren

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript zur Extraktion über die Table API mit Requests

Schritte

Konfiguration

a Beispielabfrage python

Datenextraktion über die ServiceNow-REST-Table-API

Schritte

Konfiguration

a Beispielabfrage javascript

Möchten Sie loslegen?

Service-Request-Management verbessern: Jetzt handeln

Der Schutz Ihrer Daten ist uns wichtig