> Kontinuierliche Prozessverbesserung > Serviceanfragenmanagement > Ivanti Service Manager > Daten Template

Ihr Daten-Template für das Service-Request-Management

Ivanti Service Manager

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Service-Request-Managements (21) Aktivitäten im Service-Request-Management (14) Anleitungen zum Datenexport (2)

Ihr Daten-Template für das Service-Request-Management

Dieses Template zeigt, welche Daten Sie für ein aussagekräftiges Process Mining Ihres Service-Request-Managements erfassen sollten. Es beschreibt die erforderlichen Attribute und wichtigen Aktivitäten und erklärt, wie Sie diese Informationen aus Ihrem System extrahieren. Damit können Sie ein Event Log für Ihre Analyse erstellen.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Aktivitäten für die Prozesserkennung
Anleitung zum Datenexport aus Ihrem Quellsystem

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 Ihr Service-Request-Management umfassend zu analysieren.

5 Erforderlich 9 Empfohlen 7 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Lebenszyklus der Serviceanfrage aufgetreten ist.
Beschreibung Dieses Attribut beschreibt einen bestimmten Schritt oder eine Statusänderung im Service-Request-Prozess, zum Beispiel „Anfrage zur Freigabe eingereicht“ oder „Serviceanfrage gelöst“. Die Analyse von Reihenfolge und Häufigkeit der Aktivitäten ist entscheidend, um den Prozessablauf zu verstehen, Engpässe zu erkennen und Abweichungen von der Standardvorgehensweise aufzudecken. Warum das wichtig ist Das Attribut legt die Schritte in der Prozesslandkarte fest und ermöglicht die Visualisierung und Analyse des Prozessablaufs. So lassen sich auch Nacharbeit, Engpässe und Abweichungen erkennen. Woher beziehen Wird in der Regel aus Statusänderungen, Journaleinträgen oder Beschreibungen von Audit-Log-Ereignissen in Ivanti Service Manager abgeleitet. Beispiele Serviceanfrage erstelltAnfrage freigegebenServiceanfrage gelöstServiceanfrage geschlossen
	Ereigniszeit EventTime	Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Die Ereigniszeit, auch Startzeit genannt, bezeichnet das genaue Datum und die Uhrzeit, zu der eine Aktivität im System erfasst wurde. Dieser Zeitstempel ist entscheidend für die korrekte Reihenfolge der Ereignisse und bildet die Grundlage für alle zeitbasierten Process-Mining-Analysen, etwa zur Berechnung von Durchlaufzeiten, Wartezeiten und Aktivitätsdauern. Warum das wichtig ist Dieser Zeitstempel ist erforderlich, um Ereignisse chronologisch zu ordnen und alle dauerbasierten Kennzahlen zu berechnen, die für die Leistungsanalyse wichtig sind. Woher beziehen Zu finden in Audit-Logs, Journaleinträgen, zum Beispiel Journal.CreatedDateTime, oder in Statusänderungsdatensätzen zur Serviceanfrage. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Service-Request-ID ServiceRequestID	Die eindeutige Kennung jeder Serviceanfrage.
Beschreibung Die Service-Request-ID kennzeichnet jede einzelne Serviceanfrage, die von einer Person oder einem System eingereicht wurde. Sie dient als zentrale Verknüpfung aller nachfolgenden Ereignisse, von der ersten Erfassung bis zum endgültigen Abschluss. So lässt sich der gesamte Ablauf jeder Serviceanfrage analysieren. Warum das wichtig ist Dies ist die zentrale Case-ID, die alle zugehörigen Aktivitäten zu einer einzelnen Prozessinstanz verbindet und eine durchgängige Prozessanalyse ermöglicht. Woher beziehen Dies ist der Primärschlüssel des Business-Objekts Service Request. In der Tabelle ServiceReq ist er häufig als ServiceReqNumber zu finden. Beispiele SR-0012345SR-0012346SR-0012347
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel der letzten Datenaktualisierung aus dem Quellsystem.
Beschreibung Dieses Attribut gibt an, wann die Daten zuletzt aus Ivanti Service Manager extrahiert wurden. Es zeigt, wie aktuell die analysierten Daten sind. So wissen Benutzer, welchen Zeitraum die Analyse abdeckt und wann mit der nächsten Aktualisierung zu rechnen ist. Warum das wichtig ist Das Attribut informiert Benutzer über die Aktualität der Daten. Das ist entscheidend, wenn Entscheidungen auf Grundlage der neuesten verfügbaren Informationen zur Prozessleistung getroffen werden. Woher beziehen Dieser Wert wird zum Zeitpunkt der Datenextraktion erzeugt und dem Datensatz hinzugefügt. Beispiele 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Prozessdaten an. In dieser Ansicht ist der Wert konstant, da alle Daten aus Ivanti Service Manager stammen. Das ist wichtig, wenn Daten aus mehreren Systemen zusammengeführt werden, damit Herkunft und Kontext eindeutig bleiben. Warum das wichtig ist Das Attribut liefert wichtige Informationen zur Datenherkunft. So lassen sich Analysen dem richtigen Quellsystem zuordnen, insbesondere in Umgebungen mit mehreren Systemen. Woher beziehen In der Regel wird während der Datenextraktion ein statischer Wert hinzugefügt, der die Herkunft des Datensatzes kennzeichnet. Beispiele Ivanti Service Manager
	Ereignis-Endzeit EventEndTime	Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde.
Beschreibung Die Ereignis-Endzeit kennzeichnet den Abschluss einer Aktivität. Die Zeitspanne zwischen der Ereigniszeit (Beginn) und der Ereignis-Endzeit entspricht der Verarbeitungszeit dieser Aktivität. Sie ist entscheidend, um festzustellen, welche Prozessschritte am meisten Zeit beanspruchen und wo Ineffizienzen und Verbesserungspotenziale liegen. Warum das wichtig ist Damit lassen sich die Dauer einzelner Aktivitäten berechnen. Das ist wichtig, um Engpässe im Prozess und lang laufende Aufgaben zu erkennen. Woher beziehen Möglicherweise gibt es dafür kein eigenes Feld. Häufig entspricht der Wert der Startzeit der nächsten Aktivität in der Sequenz desselben Cases. Beispiele 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Priorität Priority	Die der Serviceanfrage zugewiesene Prioritätsstufe.
Beschreibung Die Priorität gibt an, wie dringend eine Serviceanfrage ist. Üblicherweise gibt es Stufen wie „Niedrig“, „Mittel“, „Hoch“ und „Kritisch“. Anhand dieses Attributs lässt sich beurteilen, ob Anfragen mit hoher Priorität im Prozess tatsächlich schneller bearbeitet werden. Dazu werden häufig Zykluszeiten und SLA-Einhaltung für die verschiedenen Prioritätsstufen verglichen. So können Sie prüfen, ob die Priorisierungsregeln wie vorgesehen greifen. Warum das wichtig ist Das Attribut ist entscheidend, um die Wirksamkeit der Priorisierungsstrategie zu bewerten und sicherzustellen, dass Anfragen mit hoher Priorität schneller gelöst werden als solche mit niedriger Priorität. Woher beziehen Ein Standardfeld im Serviceanfrageobjekt, das üblicherweise „Priority“ heißt. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	Serviceanfragetyp ServiceRequestType	Die Klassifizierung oder Kategorie der Serviceanfrage.
Beschreibung Dieses Attribut kategorisiert die Serviceanfrage, zum Beispiel als „Hardwareanfrage“, „Softwareinstallation“ oder „Passwort zurücksetzen“. Es ist eine wichtige Auswertungsdimension: Teams können damit Prozessleistung, Zykluszeiten und SLA-Einhaltung für verschiedene Servicearten vergleichen. Wer diese Unterschiede kennt, kann Prozessverbesserungen gezielt planen und Ressourcen wirksamer einsetzen. Warum das wichtig ist Wenn Sie den Prozess nach Anfragetyp segmentieren, können Sie gezielt untersuchen, ob bestimmte Anfragen häufiger zu Verzögerungen, Nacharbeit oder SLA-Verstößen führen. Woher beziehen Das Feld befindet sich wahrscheinlich im Geschäftsobjekt für Serviceanfragen und heißt häufig „Service“ oder „Kategorie“. Die Dokumentation von Ivanti Service Manager enthält die genauen Feldnamen, zum Beispiel „SvcReqTmplLink_Category“. Beispiele Neue HardwareanfrageSoftwarezugriffKontoänderungInformationsanfrage
	SLA-Frist SLADeadline	Der Timestamp, bis zu dem die Serviceanfrage voraussichtlich gelöst sein soll.
Beschreibung Die SLA-Frist ist das berechnete Datum und die Uhrzeit, bis zu denen eine Serviceanfrage gelöst sein muss, damit die vereinbarte Servicequalität eingehalten wird. Der Zielwert richtet sich üblicherweise nach Faktoren wie Priorität und Typ der Anfrage. Der Vergleich zwischen dem tatsächlichen Lösungszeitpunkt und dieser Frist bildet die Grundlage für die Messung der SLA-Einhaltung. Warum das wichtig ist Die Frist dient als Vergleichswert für die tatsächliche Leistung. Sie unterstützt direkt die Berechnung der SLA-Einhaltungsquote und hilft, gefährdete Anfragen zu erkennen. Woher beziehen In Ivanti handelt es sich häufig um ein berechnetes Feld, das in Feldern zur Service Level Agreement oder zum Serviceangebot gespeichert ist, zum Beispiel „ResolutionTargetDateTime“. Beispiele 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	SLA-Status SLAStatus	Gibt an, ob die Serviceanfrage innerhalb der SLA-Frist gelöst wurde.
Beschreibung Dieses abgeleitete Attribut kennzeichnet jede Serviceanfrage anhand des Lösungszeitpunkts im Verhältnis zur SLA-Frist als „Eingehalten“ oder „Verletzt“. Es bildet die Grundlage für das Dashboard „Leistung bei der SLA-Einhaltung“ und die Kennzahl „SLA-Einhaltungsquote“. Dazu werden für jeden Case ResolutionDateTime und SLADeadline verglichen. Warum das wichtig ist Das Attribut misst direkt, ob die vereinbarten Serviceziele eingehalten werden. Das ist entscheidend, um die Servicequalität zu bewerten und das Vertrauen der Benutzer zu erhalten. Woher beziehen Der Status wird durch den Vergleich von „ResolutionDateTime“ und „SLADeadline“ berechnet. Wenn ResolutionDateTime <= SLADeadline gilt, lautet der Status „Eingehalten“, andernfalls „Verletzt“. Beispiele EingehaltenVerletzt
	Status der Serviceanfrage ServiceRequestStatus	Der Status der Serviceanfrage zum Zeitpunkt des Ereignisses.
Beschreibung Dieses Attribut erfasst den Status der Serviceanfrage, zum Beispiel „Erfasst“, „In Bearbeitung“, „Ausstehend“, „Gelöst“ oder „Geschlossen“. Statusänderungen definieren häufig die Aktivitäten im Prozessprotokoll. Eine Auswertung der Verweildauer in den einzelnen Status kann Engpässe aufdecken, etwa wenn Anfragen zu lange auf „Ausstehend“ stehen. Warum das wichtig ist Das Attribut zeigt den Status der Anfrage zu einem bestimmten Zeitpunkt. So können Sie die Verweildauer in einzelnen Status berechnen und Stillstände im Prozess erkennen. Woher beziehen Ein Standardfeld im Serviceanfrageobjekt, das häufig „Status“ heißt. Beispiele ErfasstAktivWarten auf KundenErfülltGeschlossen
	Zeitstempel der Lösung ResolutionDateTime	Datum und Uhrzeit, zu denen die Serviceanfrage offiziell gelöst wurde.
Beschreibung Dieses Attribut auf Case-Ebene enthält den abschließenden Timestamp, zu dem der Service erbracht oder das Problem behoben wurde, bevor die Anfrage offiziell geschlossen wird. Er bildet den Endpunkt für die Berechnung der durchgängigen Zykluszeit einer Serviceanfrage und ist damit eine wichtige Grundlage für die Messung der gesamten Prozesseffizienz und der SLA-Einhaltung. Warum das wichtig ist Das Attribut legt den Endpunkt für die Berechnung der Zykluszeit des Kernprozesses fest. Diese Kennzahl ist wichtig, um die Effizienz der Servicebereitstellung zu bewerten. Woher beziehen Ein eigenes Timestamp-Feld im Serviceanfrageobjekt, das häufig „ResolvedDateTime“ oder ähnlich heißt. Beispiele 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Zugewiesene Person AssignedAgent	Der Benutzer oder die zuständige Person, der die Serviceanfrage zugewiesen wurde.
Beschreibung Die zugewiesene Person ist konkret für die Bearbeitung der Serviceanfrage verantwortlich. Mit diesem Attribut können Sie auf individueller Ebene auswerten, etwa für das Leistungsmanagement, die Arbeitsverteilung und die Ermittlung von Schulungsbedarf. Die Nachverfolgung von Neuzuweisungen ist wichtig, um Kennzahlen wie „Durchschnittliche Neuzuweisungen pro Anfrage“ zu berechnen und Ineffizienzen im Prozess zu verstehen. Warum das wichtig ist Damit lassen sich individuelle Arbeitslast, Leistung und Neuzuweisungsmuster analysieren. Auffälligkeiten können auf Schulungsbedarf, fehlende Kompetenzen oder eine ungeeignete Erstzuweisung hindeuten. Woher beziehen Das Feld befindet sich üblicherweise im Serviceanfrageobjekt und heißt beispielsweise „Owner“. Bei jeder Neuzuweisung kann sich der Wert ändern. Deshalb sollte er im Event Log erfasst werden. Beispiele Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Zugewiesenes Team AssignedTeam	Das Supportteam oder die Gruppe, die aktuell für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung Dieses Attribut gibt an, welches Team zu einem bestimmten Zeitpunkt für die Bearbeitung der Serviceanfrage verantwortlich ist. Die Übergaben zwischen Teams, die Bearbeitungszeit je Team und die Anzahl der von den Teams bearbeiteten Anfragen sind wichtige Faktoren, um die Arbeitsverteilung zu verstehen, Engpässe zu erkennen und die Teamleistung zu bewerten. Das Attribut unterstützt direkt Dashboards zur SLA-Einhaltung und zur Arbeitslast der Mitarbeitenden. Warum das wichtig ist Das Attribut bildet Zuständigkeiten und Übergaben ab. So lassen sich Verzögerungen zwischen Teams, die Arbeitsverteilung und Teams mit Engpässen im Prozess analysieren. Woher beziehen Diese Information ist üblicherweise in einem Feld wie „OwnerTeam“ des Serviceanfrageobjekts oder in zugehörigen Zuweisungsdatensätzen gespeichert. Beispiele IT-Service-DeskNetzwerkbetriebHR-SupportGebäudemanagement
	Abteilung der anfragenden Person RequestorDepartment	Die Fachabteilung des Benutzers, der die Serviceanfrage gestellt hat.
Beschreibung Dieses Attribut gibt die Abteilung des Mitarbeitenden oder Systems an, von dem die Serviceanfrage ausgeht, zum Beispiel „Vertrieb“, „Finanzen“ oder „Personal“. Damit können Sie Servicequalität und Nachfrage in verschiedenen Bereichen der Organisation vergleichen. So lässt sich beispielsweise feststellen, ob bestimmte Abteilungen länger auf eine Lösung warten oder besonders viele Anfragen stellen. Warum das wichtig ist Damit können Sie Serviceverbrauch und -qualität nach Geschäftseinheit auswerten und abteilungsspezifische Probleme oder Trends erkennen. Woher beziehen Diese Information stammt üblicherweise aus dem Benutzerprofil der anfragenden Person, das mit der Serviceanfrage verknüpft ist. Das Feld könnte im Objekt Profile.Employee „Department“ heißen. Beispiele FinanzenVertriebMarketingInformationstechnologie
	Anzahl der Wiedereröffnungen ReopenCount	Wie oft eine gelöste Serviceanfrage wiedereröffnet wurde.
Beschreibung Dieser Zähler wird bei jeder Änderung einer Serviceanfrage von „Gelöst“ oder „Geschlossen“ zurück zu „Aktiv“ erhöht. Eine hohe Anzahl von Wiedereröffnungen deutet häufig auf eine unzureichende Lösung beim ersten Versuch, unvollständige Lösungen oder wiederkehrende Probleme hin. Das Attribut unterstützt direkt die Kennzahl „Nacharbeitsquote bei Serviceanfragen“. Warum das wichtig ist Das Attribut misst Nacharbeit direkt und ist ein wichtiger Indikator für die Lösungsqualität. Hohe Werte deuten darauf hin, dass die erste Lösung nicht wirksam war. Woher beziehen Üblicherweise handelt es sich um ein Zählerfeld im Serviceanfrageobjekt, das bei einer entsprechenden Statusänderung durch eine Geschäftsregel erhöht wird. Es könnte „ReopenCounter“ heißen. Beispiele 0123
	Anzahl der Zuweisungen AssignmentCount	Wie oft eine Serviceanfrage insgesamt zugewiesen oder neu zugewiesen wurde.
Beschreibung Diese berechnete Kennzahl zählt für jede Serviceanfrage die Aktivitäten im Zusammenhang mit Zuweisungen, zum Beispiel „Team zugewiesen“ oder „Person zugewiesen“. Häufige Neuzuweisungen, auch als „Ticket-Pingpong“ bezeichnet, deuten auf ineffiziente Weiterleitung, fehlende Lösung beim Erstkontakt oder unklare Zuständigkeiten der Teams hin. Das Attribut ist wichtig für die Kennzahl „Durchschnittliche Neuzuweisungen pro Anfrage“. Warum das wichtig ist Das Attribut quantifiziert ineffiziente Übergaben und Probleme bei der Weiterleitung. Hohe Werte deuten häufig auf längere Lösungszeiten und Frustration bei den Benutzern hin. Woher beziehen Wird bei der Datenaufbereitung berechnet, indem die Vorkommen zuweisungsbezogener Aktivitäten für jede eindeutige ServiceRequestID gezählt werden. Beispiele 12345
	Kanal Channel	Die Methode oder der Kanal, über den die Serviceanfrage eingereicht wurde.
Beschreibung Der Kanal gibt an, wie die Serviceanfrage erstellt wurde, zum Beispiel über das Self-Service-Portal, per E-Mail oder Telefon oder automatisch durch ein anderes System. Wenn Sie Anfragevolumen und Lösungszeiten nach Kanal auswerten, erkennen Sie, welche Kanäle am effizientesten sind und wo Prozessverbesserungen oder Schulungen für Benutzer erforderlich sein könnten. Warum das wichtig ist Das Attribut hilft, das Verhalten der Benutzer und die Effizienz der einzelnen Kanäle zu verstehen. Die Erkenntnisse können in Entscheidungen zur Servicebereitstellung und zu Automatisierungsmöglichkeiten einfließen. Woher beziehen Das Attribut ist häufig in einem Feld wie „Source“ oder „CreatedBy“ des Serviceanfrageobjekts gespeichert. Beispiele Self-ServiceE-MailTelefonDirekteingabe
	Lösungskategorie ResolutionCategory	Eine Klassifizierung der Lösung für die Serviceanfrage.
Beschreibung Die Lösungskategorie bietet eine strukturierte Möglichkeit, die abschließende Lösung einer Serviceanfrage zu klassifizieren. Häufig handelt es sich um eine hierarchische Einteilung, etwa in Kategorie und Unterkategorie, die Ursachenanalysen und Trendberichte unterstützt. So lassen sich wiederkehrende Probleme oder häufige Maßnahmen zur Erfüllung von Anfragen erkennen. Diese Erkenntnisse können zur Verbesserung von Services oder zur Erstellung von Wissensdatenbankartikeln beitragen. Warum das wichtig ist Das Attribut zeigt, welche Arten von Lösungen eingesetzt werden. So lassen sich häufige Probleme, Möglichkeiten zur Serviceverbesserung und geeignete Automatisierungskandidaten erkennen. Woher beziehen Die Information ist häufig in Kategorisierungsfeldern gespeichert, die beim Lösen der Anfrage ausgefüllt werden, zum Beispiel in „ResolutionCategory“ oder einem benutzerdefinierten Abschlusscodefeld. Beispiele Benutzerschulung erforderlichSoftware bereitgestelltHardware repariertZugriff gewährt
	Nacharbeit IsRework	Ein boolesches Kennzeichen dafür, ob bei der Serviceanfrage Nacharbeit angefallen ist.
Beschreibung Dieses berechnete Kennzeichen wird auf „true“ gesetzt, wenn eine Serviceanfrage Anzeichen von Nacharbeit aufweist, etwa wenn sie nach der Lösung wiedereröffnet oder eine Aktivität in einer Schleife wiederholt wird. Es vereinfacht die Berechnung der Kennzahl „Nacharbeitsquote bei Serviceanfragen“ und hilft, ineffiziente Prozessinstanzen in Dashboards wie „Nacharbeits- und Neuzuweisungsabläufe“ zu filtern. Warum das wichtig ist Damit lassen sich Anfragen, die zusätzlichen, ungeplanten Aufwand erfordern, einfach erkennen und quantifizieren. So werden Probleme bei Qualität und Effizienz sichtbar. Woher beziehen Das Kennzeichen wird aus den Daten abgeleitet. Die Logik kann darauf basieren, dass das Attribut „ReopenCount“ größer als null ist, oder bestimmte Aktivitätssequenzen erkennen, etwa mehrere Ereignisse vom Typ „Assigned to Agent“. Beispiele truefalse
	Name des Anbieters VendorName	Der Name des externen Anbieters, der an der Lösung der Anfrage beteiligt ist.
Beschreibung Dieses Attribut gibt den Drittanbieter an, der zur Unterstützung oder Bearbeitung einer Serviceanfrage hinzugezogen wurde. Es ist wichtig für das Dashboard „Dauer externer Anbieteraktivitäten“, denn damit lassen sich die Leistungen verschiedener Anbieter messen und vergleichen. Die Nachverfolgung unterstützt das Anbietermanagement und hilft, Engpässe durch externe Abhängigkeiten zu erkennen. Warum das wichtig ist Damit können Sie die Leistung von Drittanbietern und deren Einfluss auf die gesamte Lösungszeit von Serviceanfragen analysieren. Das unterstützt das Anbietermanagement. Woher beziehen Das Feld kann sich in einem Aufgabenobjekt befinden, das mit der Serviceanfrage verknüpft ist, oder direkt im Serviceanfrageobjekt, wenn ein Anbieter zugewiesen wurde. Beispiele Dell SupportOracle ConsultingMicrosoft Premiernull

Erforderlich Empfohlen Optional

Aktivitäten im Service-Request-Management

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess zuverlässig zu entdecken und zu analysieren.

5 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Anfrage einem Team zugewiesen	Die Serviceanfrage wird einem bestimmten Supportteam zur Bearbeitung zugewiesen. Dies lässt sich daran erkennen, dass das Feld „OwnerTeam“ im Service-Request-Datensatz befüllt oder geändert wird.
Warum das wichtig ist Dieses Ereignis ist wichtig, um die Leistung einzelner Teams, die Arbeitsverteilung und die Übergabezeiten zwischen Teams zu analysieren. Es hilft außerdem dabei, Teams zu erkennen, die im Prozess einen Engpass bilden. Woher beziehen Erfasst anhand von Änderungen am Feld „OwnerTeam“ im Audit-Verlauf oder Journal der Serviceanfrage. Erfassung Ein Aktualisierungsereignis für das Feld „OwnerTeam“, das üblicherweise in einem Audit-Trail protokolliert wird. Ereignistyp explicit
	Anfrage einer zuständigen Person zugewiesen	Eine bestimmte Person übernimmt die Serviceanfrage. Diese Aktivität lässt sich in der Regel daran erkennen, dass das Feld „Owner“, in dem die zuständige Person angegeben ist, erstmals befüllt oder aktualisiert wird.
Warum das wichtig ist Damit endet die anfängliche Warte- oder Warteschlangenzeit. Die Dauer bis zu dieser Aktivität hilft, Probleme bei der Ressourcenzuweisung zu erkennen und das Dashboard zur Arbeitsauslastung der Mitarbeitenden zu unterstützen. Woher beziehen Abgeleitet aus dem Befüllen oder Ändern des Felds „Owner“ im Service-Request-Datensatz, wie im Audit-Verlauf dokumentiert. Erfassung Der erste Zeitstempel nach der Erstellung oder Teamzuweisung, zu dem das Feld „Owner“ mit dem Namen einer zuständigen Person befüllt ist. Ereignistyp inferred
	Serviceanfrage erstellt	Diese Aktivität markiert den Beginn des Lebenszyklus einer Serviceanfrage: Eine neue Anfrage wird offiziell eingereicht und in Ivanti erfasst. Das Ereignis wird aufgezeichnet, wenn im Business-Objekt Service Request ein neuer Datensatz angelegt und eine eindeutige Service-Request-ID vergeben wird.
Warum das wichtig ist Dies ist das zentrale Start-Event des Prozesses. Die Zeitspanne von diesem Zeitpunkt bis zur Lösung ist entscheidend, um die gesamte Durchlaufzeit und Prozesseffizienz zu messen. Woher beziehen Erfasst anhand des Erstellungszeitstempels des Service-Request-Datensatzes, zum Beispiel im Feld CreatedDateTime des Business-Objekts ServiceReq. Erfassung Das Erstellungsereignis in der Tabelle ServiceReq, ermittelt anhand des Erstellungszeitstempels. Ereignistyp explicit
	Serviceanfrage gelöst	Die Serviceanfrage gilt als gelöst und die Lösung wurde der anfragenden Person bereitgestellt. Dieser zentrale Meilenstein wird durch eine Statusänderung zu „Gelöst“ erfasst. Dabei wird häufig auch die SLA-Zeitmessung beendet.
Warum das wichtig ist Dies ist ein entscheidender Endpunkt für die Messung der Bearbeitungszeit und der SLA-Einhaltung. Die Zeit von der Erstellung bis zu dieser Aktivität ist eine zentrale Kennzahl für die Prozessleistung. Woher beziehen Abgeleitet aus einer Änderung des Felds „Status“ im Service-Request-Datensatz zu „Gelöst“ und dem zugehörigen Zeitstempel. Erfassung Erkennung der Änderung des Felds „Status“ zu „Gelöst“ anhand des Audit-Verlaufs. Ereignistyp inferred
	Serviceanfrage geschlossen	Die Serviceanfrage wurde offiziell geschlossen. Weitere Maßnahmen sind nicht mehr möglich. Dies geschieht häufig automatisch, nachdem die Anfrage eine festgelegte Zeit lang den Status „Gelöst“ hatte, und markiert das endgültige Ende ihres Lebenszyklus.
Warum das wichtig ist Diese Aktivität markiert das endgültige Prozessende. Die Zeit zwischen „Gelöst“ und „Geschlossen“ kann auf Verzögerungen bei der Bestätigung oder bei automatisierten Systemabläufen hinweisen. Woher beziehen Abgeleitet aus einer Änderung des Felds „Status“ im Service-Request-Datensatz zu „Geschlossen“ und dem zugehörigen Zeitstempel. Erfassung Erkennung der Änderung des Felds „Status“ zu „Geschlossen“ anhand des Audit-Verlaufs. Ereignistyp inferred
	Anfrage freigegeben	Die Serviceanfrage hat alle erforderlichen Freigaben erhalten und kann nun bearbeitet werden. Dieses Ereignis wird erfasst, wenn der Freigabe-Workflow erfolgreich abgeschlossen wird und sich dadurch der Status der Anfrage ändert.
Warum das wichtig ist Diese Aktivität markiert einen wichtigen Meilenstein: Die Freigabephase endet, die Bearbeitung beginnt. Damit lässt sich die Effizienz des Freigabeprozesses messen. Woher beziehen Abgeleitet aus einer Statusänderung von „Wartet auf Freigabe“ zu „Freigegeben“ oder „Erfüllt“. Das Ereignis kann auch explizit im Business-Objekt FRS_Approval protokolliert sein. Erfassung Eine Änderung des Felds „Status“ im Service-Request-Datensatz von einem Freigabestatus zu einem aktiven Status. Ereignistyp inferred
	Anfrage zur Freigabe eingereicht	Die Serviceanfrage wurde zur erforderlichen Freigabe eingereicht, bevor sie bearbeitet werden kann. Dies lässt sich in der Regel daran erkennen, dass sich der Status der Anfrage in „Eingereicht“ oder „Freigabe ausstehend“ ändert und dadurch häufig ein Freigabe-Workflow startet.
Warum das wichtig ist Die Erfassung dieser Aktivität hilft, Verzögerungen in der Freigabephase zu erkennen. Lange Wartezeiten können einen erheblichen Engpass darstellen und die Bearbeitungszeit sowie die Nutzerzufriedenheit beeinträchtigen. Woher beziehen Abgeleitet aus einer Statusänderung des Service-Request-Datensatzes, wahrscheinlich zu „Eingereicht“ oder „Wartet auf Freigabe“. Die Daten können auch aus den Business-Objekten FRS_Approval oder FRS_ApprovalVoteTracking stammen. Erfassung Eine Änderung des Felds „Status“ im Service-Request-Datensatz in einen Status, der auf eine ausstehende Freigabe hinweist. Ereignistyp inferred
	Externer Dienstleister eingebunden	Die Bearbeitung der Serviceanfrage wurde an einen externen Dienstleister oder Dritten übergeben. Dies wird in der Regel durch eine Statusänderung zu „Wartet auf Dritte“ oder einem ähnlichen Status erfasst.
Warum das wichtig ist Diese Aktivität ist wichtig, um die Leistung des Dienstleisters und deren Auswirkungen auf die gesamte Durchlaufzeit zu messen. Sie ermöglicht die Analyse dienstleisterbedingter Verzögerungen und unterstützt das Dashboard zur Dauer von Aktivitäten externer Dienstleister. Woher beziehen Abgeleitet aus einer Statusänderung des Service-Request-Datensatzes zu „Wartet auf Dritte“ oder „Dienstleister ausstehend“. Erfassung Erkennung einer Änderung des Felds „Status“ in einen festgelegten Status, der auf eine ausstehende Rückmeldung des Dienstleisters hinweist. Ereignistyp inferred
	Informationen bei Nutzenden angefordert	Die zuständige Person benötigt weitere Informationen von der anfragenden Person, um die Anfrage bearbeiten zu können. Dies wird erfasst, wenn der Status der Anfrage beispielsweise auf „Wartet auf Kunden“ gesetzt wird.
Warum das wichtig ist Diese Aktivität macht Verzögerungen aufgrund unvollständiger Angaben bei der Einreichung sichtbar. Ihre Häufigkeit und Dauer sind wichtige Kennzahlen für die Analyse der Auswirkungen von Informationsanfragen und für die Ermittlung von Verbesserungsmöglichkeiten. Woher beziehen Abgeleitet aus einer Statusänderung des Service-Request-Datensatzes, beispielsweise zu „Wartet auf Kunden“ oder „Ausstehend“. Erfassung Erkennung einer Änderung des Felds „Status“ in einen festgelegten Status, der auf eine ausstehende Rückmeldung der anfragenden Person hinweist. Ereignistyp inferred
	Informationen von Nutzenden erhalten	Die anfragende Person hat die erforderlichen Informationen bereitgestellt, sodass die zuständige Person die Bearbeitung fortsetzen kann. Dies wird erfasst, wenn die Anfrage den Status „Wartet auf Kunden“ verlässt und wieder in einen aktiven Status wechselt.
Warum das wichtig ist Mit diesem Ereignis ist die Informationsanfrage abgeschlossen. Die Zeit zwischen der Anfrage und dem Eingang der Informationen ist ein wichtiger Faktor für Prozessverzögerungen und Nacharbeitsschleifen. Woher beziehen Abgeleitet, wenn sich das Feld „Status“ der Serviceanfrage von „Wartet auf Kunden“ in einen aktiven Status wie „Aktiv“ oder „In Bearbeitung“ ändert. Erfassung Erkennung einer Statusänderung von einem Status, der auf eine ausstehende Rückmeldung der anfragenden Person hinweist, zu einem aktiven Status. Ereignistyp inferred
	Priorität geändert	Die Priorität der Serviceanfrage wurde nach ihrer Erstellung aktualisiert. Dieses Ereignis wird anhand des Audit-Protokolls oder Verlaufs erfasst, in dem Änderungen auf Feldebene aufgezeichnet werden.
Warum das wichtig ist Die Erfassung von Prioritätsänderungen ist wichtig für die Übersicht zur Wirksamkeit der Priorisierung. Sie hilft festzustellen, ob Eskalationen angemessen bearbeitet werden und die ursprüngliche Priorisierung zutreffend war. Woher beziehen Dieses explizite Ereignis wird aus dem Audit-Verlauf des Service-Request-Datensatzes erfasst, in dem Änderungen am Feld „Priority“ protokolliert werden. Erfassung Ein Aktualisierungsereignis für das Feld „Priority“, das im Audit-Trail des Systems aufgezeichnet ist. Ereignistyp explicit
	Serviceanfrage erfüllt	Alle Aufgaben zur Erfüllung der Serviceanfrage wurden von der zuständigen Person oder dem System abgeschlossen. Dies wird durch eine Statusänderung zu „Erfüllt“ erfasst, der häufig der abschließende Status „Gelöst“ folgt.
Warum das wichtig ist Dieser Meilenstein markiert den Abschluss der technischen oder verfahrensbezogenen Arbeit. Er ist ein wichtiger Bezugspunkt, um die aktive Bearbeitungszeit bis zur abschließenden Bestätigung und Schließung zu messen. Woher beziehen Abgeleitet aus einer Änderung des Felds „Status“ im Service-Request-Datensatz zu „Erfüllt“. Erfassung Eine Änderung des Felds „Status“ zu „Erfüllt“, die im Verlauf des Datensatzes erkannt wird. Ereignistyp inferred
	Serviceanfrage erneut geöffnet	Eine zuvor gelöste Serviceanfrage wurde erneut aktiviert, weil das Problem weiterhin besteht oder die Lösung nicht zufriedenstellend war. Dies wird erfasst, wenn sich der Status von „Gelöst“ zurück in einen aktiven Status wie „Aktiv“ oder „Zugewiesen“ ändert.
Warum das wichtig ist Diese Aktivität weist direkt auf Nacharbeit und eine unzureichende Lösung beim ersten Versuch hin. Die Analyse erneut geöffneter Anfragen hilft, Schwachstellen im Prozess zu erkennen und die KPI zur Nacharbeitsquote bei Serviceanfragen zu verbessern. Woher beziehen Abgeleitet aus dem Audit-Verlauf, wenn sich das Feld „Status“ von „Gelöst“ oder „Geschlossen“ in einen aktiven Status ändert. Erfassung Eine Statusänderung von einem Endstatus („Gelöst“, „Geschlossen“) zu einem offenen Status („Aktiv“, „Zugewiesen“). Ereignistyp inferred
	Serviceanfrage storniert	Die anfragende Person oder eine zuständige Person hat die Serviceanfrage vor ihrer Lösung storniert. Dieser alternative Endstatus wird durch eine Statusänderung zu „Storniert“ oder „Zurückgezogen“ erfasst.
Warum das wichtig ist Dies ist ein nicht reguläres Prozessende. Die Analyse der Stornierungsgründe kann Probleme im Anfrageprozess oder veränderte Bedürfnisse der Nutzenden aufdecken. Woher beziehen Abgeleitet aus einer Änderung des Felds „Status“ im Service-Request-Datensatz zu „Storniert“. Erfassung Erkennung der Änderung des Felds „Status“ zu „Storniert“ anhand des Audit-Verlaufs. Ereignistyp inferred

Anleitungen zum Datenexport

So exportieren Sie Ihre Daten aus Ivanti Service Manager

Schritte

Melden Sie sich mit einer Rolle, die Lesezugriff auf Service Requests und deren Audit-Verlauf hat, bei Ivanti Service Manager an.
Öffnen Sie im Hauptnavigationsbereich den Arbeitsbereich „Service Request“.
Für diesen Prozess sind zwei separate Datenexporte erforderlich, die anschließend außerhalb von Ivanti zusammengeführt werden. Der erste Export enthält das Erstellungsereignis und die wichtigsten Attribute, der zweite den detaillierten Änderungsverlauf.
Erster Export (Erstellungsereignisse): Erstellen Sie eine neue Saved Search für das Business Object ServiceReq. Legen Sie einen Filter für CreatedDateTime fest, um Service Requests aus dem gewünschten Analysezeitraum auszuwählen, zum Beispiel aus den letzten sechs Monaten.
Richten Sie die Spalten der Suche nach Erstellungsereignissen so ein, dass sie RecId, ServiceReqNumber (für ServiceRequestID), CreatedDateTime (für EventTime), SvcReqTmplLink_Category (für ServiceRequestType), OwnerTeam, Verantwortlicher, Priority, Status, ResolutionDateTime und TargetDateTime (für SLADeadline) enthalten.
Führen Sie die Suche aus und exportieren Sie die Daten über die Exportfunktion des Rasters, meist über ein Symbol in Form einer Diskette oder eines Pfeils, in eine CSV-Datei. Nennen Sie die Datei ServiceRequests.csv.
Zweiter Export (Audit-Verlauf): Erstellen Sie eine neue Saved Search, diesmal für das Business Object FRS_data_audit_history, in dem Feldänderungen protokolliert werden.
Filtern Sie die Suche so, dass nur Änderungen an Service Requests enthalten sind. Fügen Sie einen Filter hinzu, bei dem ParentObjectType dem Wert 'ServiceReq' entspricht. Filtern Sie außerdem AuditDate nach demselben Analysezeitraum wie zuvor.
Richten Sie die Spalten der Audit-Suche so ein, dass sie ParentLink_RecID (zur Verknüpfung mit dem Service Request), FieldName, OldValue, NewValue und AuditDate (für EventTime) enthalten. Exportieren Sie die Daten in eine zweite CSV-Datei mit dem Namen AuditHistory.csv.
Daten umwandeln und zusammenführen: Führen Sie die exportierten CSV-Dateien zu einem einzelnen Event Log zusammen und bringen Sie sie in die erforderliche Form. Verwenden Sie dazu ein Werkzeug zur Datenaufbereitung, etwa Power Query in Excel, Python oder ein Datenbankwerkzeug:
- Laden Sie ServiceRequests.csv und AuditHistory.csv.
- Erstellen Sie anhand von ServiceRequests.csv für jeden Request das Ereignis 'Service Request Created'.
- Erstellen Sie anhand von AuditHistory.csv alle weiteren Ereignisse. Ordnen Sie die Werte in den Spalten FieldName und NewValue den erforderlichen Aktivitätsnamen zu. Wenn beispielsweise FieldName den Wert 'Status' und NewValue den Wert 'Resolved' enthält, lautet der Wert für ActivityName 'Service Request Resolved'.
- Verknüpfen Sie die umgewandelten Audit-Ereignisse anhand von ParentLink_RecID aus der Audit-Datei und RecId aus der Service-Request-Datei mit den Service-Request-Daten. Dadurch erhält jedes Ereignis die Attribute auf Case-Ebene.
- Führen Sie die Ereignisse 'Created' und die aus dem Audit-Verlauf abgeleiteten Ereignisse in einer Tabelle zusammen.
Formatieren Sie die zusammengeführte Tabelle mit den erforderlichen Spaltenüberschriften: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate und weiteren empfohlenen Attributen. Achten Sie auf ein einheitliches Timestamp-Format.
Speichern Sie das fertige Event Log als einzelne CSV-Datei. Es kann anschließend hochgeladen werden.

Konfiguration

Business Objects: Für diese Methode müssen Sie Daten aus zwei Business Objects exportieren: ServiceReq für die Hauptdaten der Requests und FRS_data_audit_history für die Ereignisdaten.
Filter für den Zeitraum: Filtern Sie beide Exporte unbedingt nach einem Zeitraum, damit das Datenvolumen überschaubar bleibt. Verwenden Sie das Feld CreatedDateTime in ServiceReq und das Feld AuditDate in FRS_data_audit_history. Für eine erste Analyse empfehlen sich 3 bis 6 Monate.
Wichtige Filter für den Audit-Verlauf:
- Filtern Sie ParentObjectType nach 'ServiceReq', damit nur Änderungen an Service Requests exportiert werden.
- Optional können Sie FieldName auf prozessrelevante Felder wie 'Status', 'Verantwortlicher', 'OwnerTeam' und 'Priority' beschränken. Dadurch lässt sich die Größe des Exports deutlich verringern.
Voraussetzungen: Sie benötigen ein Benutzerkonto für Ivanti Service Manager mit Berechtigungen zum Erstellen von Saved Searches und zum Exportieren von Daten aus den Business Objects ServiceReq und FRS_data_audit_history.
Leistungshinweise: Die Tabelle FRS_data_audit_history kann sehr groß sein. Ein Export ohne ausreichend eingegrenzten Zeitraum kann die Leistung der Ivanti-Anwendung beeinträchtigen und zu einer Zeitüberschreitung führen. Exportieren Sie die Daten bei Bedarf in kleineren monatlichen oder vierteljährlichen Abschnitten.

a Beispielabfrage sql

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

Schritte

Voraussetzungen und Einrichtung: Stellen Sie sicher, dass Python 3.6 oder höher auf Ihrem System installiert ist. Installieren Sie die erforderlichen Bibliotheken requests für API-Aufrufe und pandas zur Datenverarbeitung mit dem Befehl pip install requests pandas. Lassen Sie sich von Ihrem Ivanti Service Manager-Administrator einen API-Schlüssel mit mindestens Leseberechtigung für die Business Objects ServiceReq und FRS_Audit_ServiceReq ausstellen.
Skript konfigurieren: Laden Sie das bereitgestellte Python-Skript herunter. Öffnen Sie es in einem Texteditor oder einer IDE und passen Sie die Platzhaltervariablen am Anfang an Ihre Ivanti-Umgebung und den gewünschten Exportzeitraum an: TENANT_URL, API_KEY, START_DATE und END_DATE.
Skript ausführen: Starten Sie das Skript über die Befehlszeile mit python your_script_name.py. Zunächst gibt das Skript eine Meldung aus, dass es eine Verbindung zur Ivanti API herstellt und sich authentifiziert.
Service-Request-Daten abrufen: Das Skript fragt das Business Object ServiceReq nach allen Requests ab, die im angegebenen Zeitraum erstellt wurden. Es verarbeitet die API-Seitennummerierung automatisch, um alle Requests abzurufen, und zeigt beim Abruf jeder Datenseite den Fortschritt an.
Audit-Verlauf abrufen: Für jeden abgerufenen Service Request führt das Skript eine zweite Abfrage für das Business Object FRS_Audit_ServiceReq aus. Dadurch wird der vollständige Verlauf der Feldänderungen für den jeweiligen Request abgerufen, der für das detaillierte Event Log erforderlich ist.
Ereignis „Created“ erstellen: Bei der Verarbeitung jedes Service Requests erstellt das Skript zunächst das Ereignis 'Service Request Created'. Der Timestamp stammt direkt aus dem Feld CreatedDateTime des Service-Request-Datensatzes.
Ereignisse aus dem Audit-Verlauf erstellen: Anschließend durchläuft das Skript die Audit-Datensätze für jeden Service Request. Dabei prüft es Änderungen an wichtigen Feldern wie Status, OwnerTeam, Verantwortlicher und Priority.
Änderungen Aktivitäten zuordnen: Eine im Skript festgelegte Zuordnungslogik wandelt diese Feldänderungen in konkrete Aktivitätsnamen um. Eine Änderung des Felds Status von 'Active' zu 'Resolved' wird beispielsweise als Aktivität 'Service Request Resolved' erfasst.
Event Log erstellen: Das Skript führt alle erstellten Ereignisse, sowohl die anfängliche Erstellung als auch die späteren Änderungen aus dem Audit-Verlauf, in einer strukturierten Liste zusammen. Jedes Ereignis enthält die Service-Request-ID, den Aktivitätsnamen, den Timestamp und weitere relevante Attribute.
Daten umwandeln und formatieren: Die gesammelten Ereignisse werden in einen Pandas DataFrame umgewandelt. Das Skript stellt sicher, dass alle Spalten dem erforderlichen Schema für ProcessMind entsprechen, einschließlich ServiceRequestID, ActivityName und EventTime.
Als CSV exportieren: Nachdem alle Service Requests und ihre Verläufe verarbeitet wurden, speichert das Skript den fertigen DataFrame im selben Verzeichnis, in dem es ausgeführt wurde, als CSV-Datei mit dem Namen ivanti_servicereq_event_log.csv. Die Datei kann anschließend hochgeladen werden.

Konfiguration

API-Endpunkt-URL: Die Basis-URL der REST API Ihres Ivanti Service Manager-Mandanten. Tragen Sie sie im Skript in die Variable TENANT_URL ein, zum Beispiel https://your-tenant.ivanti.com.
API-Schlüssel: Ein gültiger REST-API-Schlüssel, der in der Ivanti-Verwaltungskonsole erstellt wurde. Er muss einer Rolle mit Leseberechtigung für die Business Objects ServiceReq und FRS_Audit_ServiceReq zugeordnet sein.
Zeitraum: Das Skript benötigt START_DATE und END_DATE im Format 'YYYY-MM-DD'. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. So bleibt das Datenvolumen überschaubar und umfasst zugleich genügend Prozessvarianten.
Seitengröße (TOP_COUNT): Diese Variable legt fest, wie viele Datensätze pro API-Aufruf abgerufen werden. Der Standardwert ist 500 und bietet einen guten Ausgleich zwischen Leistung und Speicherbedarf. Sie können den Wert an die Leistung Ihres API-Servers anpassen.
Erforderliche Felder (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): Im Skript ist festgelegt, welche Felder über die API abgerufen werden, um die übertragene Datenmenge zu begrenzen. Achten Sie darauf, dass diese Listen alle Felder enthalten, die für die erforderlichen und empfohlenen Attribute benötigt werden.

a Beispielabfrage python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

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

Möchten Sie loslegen?

Mit diesem detaillierten Daten-Template können Sie das Potenzial Ihres Service-Request-Managements besser ausschöpfen. Beginnen Sie noch heute damit, Ihre Abläufe zu optimieren.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie noch heute Ihr Service-Request-Management

Verkürzen Sie lange Bearbeitungszeiten, verringern Sie die Frustration der Benutzer und erreichen Sie eine Automatisierungsquote von 70 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für das Service-Request-Management

Ihr Daten-Template für das Service-Request-Management

Attribute des Service-Request-Managements

Aktivitäten im Service-Request-Management

Anleitungen zum Datenexport

Gespeicherte Suche und Rasterdaten aus Ivanti als CSV exportieren

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Ivanti REST API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie noch heute Ihr Service-Request-Management

Ihr Daten-Template für das Service-Request-Management

Ihr Daten-Template für das Service-Request-Management

Attribute des Service-Request-Managements

Aktivitäten im Service-Request-Management

Anleitungen zum Datenexport

Gespeicherte Suche und Rasterdaten aus Ivanti als CSV exportieren

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Ivanti REST API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie noch heute Ihr Service-Request-Management

Der Schutz Ihrer Daten ist uns wichtig