> Kontinuierliche Prozessoptimierung > Serviceanfragen Management > Ivanti Service Manager > Datenvorlage

Ihr Service Request Management Daten-Template

Ivanti Service Manager

Attribute im Service Request Management (22) Aktivitäten im Service Request Management (14) Extraktionsleitfäden (2)

Ihr Service Request Management Daten-Template

Dieses Template bietet eine umfassende Anleitung zur Sammlung der essenziellen Daten, die für ein effektives Process Mining Ihres Service Request Managements erforderlich sind. Es skizziert die entscheidenden Attribute, die gesammelt werden müssen, die wichtigsten Aktivitäten, die verfolgt werden sollen, und enthält praktische Hinweise zur Extraktion dieser Informationen aus Ihrem System. Nutzen Sie diese Ressource, um ein leistungsstarkes Event Log für Ihre Analyse zu erstellen.

Empfohlene Attribute für eine umfassende Analyse
Schlüsselaktivitäten zur Verfolgung für die Prozesserkennung
Anleitung zur Datenextraktion aus Ihrem Quellsystem

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

Vorlage herunterladen

Attribute im Service Request Management

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um eine umfassende Analyse Ihres Service Request Management Prozesses zu ermöglichen.

5 Erforderlich 10 Empfohlen 7 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des Events oder der Aufgabe, das/die zu einem bestimmten Zeitpunkt im Service Request Lifecycle aufgetreten ist.
Beschreibung Dieses Attribut beschreibt einen spezifischen Schritt oder eine Statusänderung innerhalb des Service-Request-Prozesses, wie z.B. 'Anfrage zur Genehmigung eingereicht' oder 'Service Request gelöst'. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten ist fundamental, um den Prozessfluss zu verstehen, Engpässe zu identifizieren und Abweichungen vom Standardverfahren aufzudecken. Bedeutung Es definiert die Schritte in der Prozesskarte und ermöglicht die Visualisierung und Analyse des Prozessflusses, einschließlich der Identifizierung von Nacharbeiten, Engpässen und Abweichungen. Datenquelle Typischerweise abgeleitet aus Statusänderungen, Journaleinträgen oder Audit Log Event-Beschreibungen innerhalb des Ivanti Service Managers. Beispiele Serviceanfrage erstelltAnfrage genehmigtServiceanfrage gelöstServiceanfrage geschlossen
	Ereigniszeit EventTime	Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Event Time, auch als Startzeitpunkt bekannt, ist das genaue Datum und die Uhrzeit, zu der eine Aktivität im System erfasst wurde. Dieser Timestamp ist entscheidend für die korrekte Sequenzierung von Events und bildet die Grundlage für alle zeitbasierten Process Mining-Analysen, wie die Berechnung von Cycle Times, Wartezeiten und Aktivitätsdauern. Bedeutung Dieser Timestamp ist essenziell für die chronologische Anordnung von Events und die Berechnung aller dauerbasierten Metriken, die für die Performance-Analyse entscheidend sind. Datenquelle Gefunden in Audit Logs, Journal-Einträgen (z. B. Journal.CreatedDateTime) oder Statusänderungsdatensätzen, die mit der Serviceanfrage verknüpft sind. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Serviceanfrage-ID ServiceRequestID	Der eindeutige Identifikator für jeden Service Request.
Beschreibung Die Service Request ID identifiziert jeden einzelnen Service Request, der von einem Nutzer oder System eingereicht wurde, eindeutig. Sie dient als zentraler Faden, der alle nachfolgenden Events, von der anfänglichen Erfassung bis zum endgültigen Abschluss, miteinander verbindet und eine vollständige End-to-End-Analyse der Reise jedes Service Requests ermöglicht. Bedeutung Dies ist der essenzielle Case Identifier, der alle zusammengehörigen Aktivitäten zu einer einzigen Process Instance verbindet und eine End-to-End Prozessanalyse ermöglicht. Datenquelle Dies ist der Primärschlüssel des Service Request Business Objekts, oft zu finden als ServiceReqNumber in der ServiceReq-Tabelle. Beispiele SR-0012345SR-0012346SR-0012347
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel der aktuellsten Datenaktualisierung aus dem Quellsystem.
Beschreibung Dieses Attribut gibt das Datum und die Uhrzeit an, zu der die Daten zuletzt aus dem Ivanti Service Manager extrahiert wurden. Es bietet Kontext zur Aktualität der analysierten Daten und stellt sicher, dass die Nutzer über den durch die Analyse abgedeckten Zeitraum und den Zeitpunkt des nächsten Updates informiert sind. Bedeutung Informiert Benutzer über die Aktualität der Daten, was entscheidend ist, um Entscheidungen auf der Grundlage der aktuellsten verfügbaren Prozessleistungsinformationen zu treffen. Datenquelle Dieser Wert wird zum Zeitpunkt der Datenextraktion generiert 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 identifiziert den Ursprung der Prozessdaten. Für diese Ansicht wird der Wert konstant sein, was darauf hinweist, dass alle Daten aus dem Ivanti Service Manager stammen. Dies ist wichtig in Umgebungen, in denen Daten aus mehreren Systemen zusammengeführt werden könnten, um eine klare Datenherkunft und einen klaren Kontext sicherzustellen. Bedeutung Es liefert entscheidenden Kontext zur Datenherkunft und stellt sicher, dass Analysen korrekt dem spezifischen Quellsystem zugeordnet werden, insbesondere in Multi-System-Umgebungen. Datenquelle Üblicherweise ein statischer Wert, der während der Extraktion vergeben wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Ivanti Service Manager
	Art der Serviceanfrage ServiceRequestType	Die Klassifikation oder Kategorie des Service Requests.
Beschreibung Dieses Attribut kategorisiert den Service Request, zum Beispiel als 'Hardware Request', 'Software Installation' oder 'Passwort zurücksetzen'. Es ist eine kritische Dimension für die Analyse, die es Teams ermöglicht, die Prozess-Performance, Zykluszeiten und SLA-Einhaltung über verschiedene Service-Typen hinweg zu vergleichen. Das Verständnis dieser Unterschiede hilft, Prozessverbesserungen maßzuschneidern und Ressourcen effektiver zuzuweisen. Bedeutung Die Segmentierung des Prozesses nach Request-Typ ermöglicht eine zielgerichtete Analyse und zeigt auf, ob bestimmte Request-Arten anfälliger für Verzögerungen, Nacharbeiten oder SLA-Verletzungen sind. Datenquelle Wahrscheinlich ein Feld im Service Request Business Object, oft benannt als 'Service' oder 'Category'. Konsultieren Sie die Ivanti Service Manager Dokumentation für spezifische Feldnamen wie 'SvcReqTmplLink_Category'. Beispiele Neue Hardware-AnfrageSoftwarezugriffKontoänderungInformationsanfrage
	Durchlaufzeit CycleTime	Die Gesamtzeit von der Erstellung des Service Requests bis zu seiner endgültigen Lösung.
Beschreibung Die Cycle Time ist eine berechnete Metrik, die die Dauer vom ersten Event (Service Request Created) bis zum Lösungs-Event (Service Request Resolved) misst. Sie ist einer der wichtigsten Key Performance Indicators für die Prozesseffizienz. Diese Metrik wird ausgiebig in Dashboards verwendet, um die Gesamtleistung zu verfolgen und Trends über die Zeit zu identifizieren. Bedeutung Dies ist eine primäre KPI zur Messung der End-to-End Prozesseffizienz und spiegelt direkt die Serviceerfahrung aus Nutzersicht wider. Datenquelle Berechnet durch Subtraktion des Erstellungs-Timestamps vom Lösungs-Timestamp für jede Serviceanfrage. Beispiele 25920000060480000086400000
	Endzeit des Events EventEndTime	Der Zeitstempel, der angibt, wann eine Aktivität abgeschlossen wurde.
Beschreibung Die Event End Time markiert den Abschluss einer Aktivität. Die Dauer zwischen der Event Time (Start) und der Event End Time repräsentiert die Bearbeitungszeit für diese spezifische Aktivität. Dies ist entscheidend, um zu identifizieren, welche Schritte im Prozess die meiste Zeit beanspruchen, und hilft, Ineffizienzen und Verbesserungsbereiche genau zu bestimmen. Bedeutung Es ermöglicht die Berechnung individueller Aktivitätsdauern, was wesentlich ist, um Prozessengpässe und langlaufende Aufgaben zu identifizieren. Datenquelle Existiert möglicherweise nicht als separates Feld. Oft ist es der Startzeitpunkt der nachfolgenden Aktivität in der Sequenz für denselben Case. Beispiele 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Lösungs-Timestamp ResolutionDateTime	Das Datum und die Uhrzeit, zu der der Service Request offiziell gelöst wurde.
Beschreibung Dies ist ein Case-Level Attribut, das den finalen Timestamp markiert, an dem der Service geliefert oder das Problem behoben wurde, bevor der Request formal geschlossen wird. Dieser Timestamp ist der primäre Endpunkt zur Berechnung der End-to-End Zykluszeit eines Service Requests. Er ist eine kritische Komponente zur Messung der gesamten Prozesseffizienz und SLA-Einhaltung. Bedeutung Definiert den Endpunkt für die Berechnung der Kernprozess-Durchlaufzeit, ein Key Performance Indicator für die Effizienz der Servicebereitstellung. Datenquelle Ein spezifisches Timestamp-Feld im Service Request Objekt, oft benannt als 'ResolvedDateTime' oder ähnlich. Beispiele 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Priorität Priority	Das dem Service Request zugewiesene Prioritätslevel.
Beschreibung Priorität gibt die Dringlichkeit einer Serviceanfrage an, typischerweise auf einer Skala wie 'Niedrig', 'Mittel', 'Hoch', 'Kritisch'. Dieses Attribut ist grundlegend für die Bewertung, ob der Prozess hochpriorisierte Anfragen effektiv beschleunigt. Die Analyse beinhaltet oft den Vergleich von Cycle Times und SLA-Einhaltung über verschiedene Prioritätsstufen hinweg, um sicherzustellen, dass die Priorisierungsregeln wie beabsichtigt funktionieren. Bedeutung Entscheidend für die Beurteilung der Wirksamkeit der Priorisierungsstrategie und die Sicherstellung, dass Anfragen mit hoher Priorität schneller gelöst werden als solche mit niedriger Priorität. Datenquelle Ein Standardfeld im Service Request Objekt, in der Regel 'Priority' genannt. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	SLA-Frist SLADeadline	Der Timestamp, bis zu dem der Service Request voraussichtlich gelöst sein wird.
Beschreibung Die SLA Deadline ist das berechnete Datum und die Uhrzeit, bis zu der ein Service Request gelöst werden muss, um das Service Level Agreement zu erfüllen. Dieses Ziel wird typischerweise basierend auf Faktoren wie der Priorität und dem Typ des Requests bestimmt. Der Vergleich der tatsächlichen Lösungszeit mit dieser Deadline ist die Grundlage für die Messung der SLA-Einhaltung. Bedeutung Es ist der Benchmark, an dem die tatsächliche Leistung gemessen wird und unterstützt direkt die Berechnung der SLA-Einhaltungsraten und die Identifizierung von gefährdeten Anfragen. Datenquelle Dies ist oft ein berechnetes Feld innerhalb von Ivanti, das in Feldern gespeichert wird, die mit dem Service Level Agreement oder Offering in Verbindung stehen, wie z.B. 'ResolutionTargetDateTime'. Beispiele 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	SLA-Status SLAStatus	Gibt an, ob die Serviceanfrage innerhalb ihrer SLA-Frist gelöst wurde.
Beschreibung Dies ist ein abgeleitetes Attribut, das jeden Service Request basierend auf seiner Lösungszeit im Verhältnis zu seiner SLA-Deadline als 'Eingehalten' oder 'Verletzt' kennzeichnet. Es ist die Grundlage für das Dashboard „SLA Adherence Performance“ und die KPI „Service Level Agreement Adherence Rate“. Die Logik vergleicht die ResolutionDateTime mit der SLADeadline für jeden Case. Bedeutung Misst direkt die Leistung im Vergleich zu Servicezusagen, was entscheidend ist für die Bewertung der Servicequalität und die Aufrechterhaltung des Benutzervertrauens. Datenquelle Berechnet durch den Vergleich der 'ResolutionDateTime' mit dem 'SLADeadline'. Wenn ResolutionDateTime <= SLADeadline, ist der Status 'Erfüllt'; andernfalls ist er 'Verletzt'. Beispiele ErfülltVerletzt
	Status des Service Requests ServiceRequestStatus	Der Status des Service Requests zum Zeitpunkt des Events.
Beschreibung Dieses Attribut erfasst den Status des Service Requests, wie z.B. 'Erfasst', 'In Bearbeitung', 'Ausstehend', 'Gelöst' oder 'Geschlossen'. Statusänderungen definieren oft die Aktivitäten im Process Log. Die Analyse der in jedem Status verbrachten Zeit kann Engpässe aufzeigen, zum Beispiel, wenn Requests zu lange im Status 'Ausstehend' verweilen. Bedeutung Bietet einen Snapshot des Zustands der Anfrage zu jedem gegebenen Zeitpunkt, was für die Berechnung der in bestimmten Zuständen verbrachten Zeit und die Identifizierung von Prozessstillständen unerlässlich ist. Datenquelle Ein Standardfeld im Service Request Objekt, üblicherweise 'Status' genannt. Beispiele ErfasstAktivWarten auf KundenrückmeldungErfüllt.Geschlossen
	Zugewiesener Agent AssignedAgent	Der einzelne Nutzer oder Bearbeiter, der dem Service Request zugewiesen ist.
Beschreibung Der zugewiesene Bearbeiter ist die spezifische Person, die für die Bearbeitung des Service Requests verantwortlich ist. Dieses Attribut ermöglicht eine Analyse auf individueller Ebene, was nützlich ist für Performance Management, Workload Balancing und die Identifizierung von Schulungsmöglichkeiten. Das Verfolgen von Neu-Zuweisungen zwischen Bearbeitern ist entscheidend für die Berechnung von KPIs wie „Durchschnittliche Neu-Zuweisungen pro Request“ und das Verständnis von Prozessineffizienzen. Bedeutung Ermöglicht die Analyse der individuellen Arbeitslast, Leistung und Umverteilungsmuster, was auf Probleme mit Schulungen, Qualifikationen oder der initialen Zuweisung hindeuten kann. Datenquelle Typischerweise in einem Feld wie 'Owner' im Service Request Objekt zu finden. Dies kann sich bei jeder Neu-Zuweisung ändern und sollte im Event Log verfolgt werden. Beispiele Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Zugewiesenes Team AssignedTeam	Das Support-Team oder die Gruppe, die aktuell mit der Bearbeitung des Service Requests beauftragt ist.
Beschreibung Dieses Attribut identifiziert das Team, das zu einem bestimmten Zeitpunkt für die Bearbeitung des Service Requests verantwortlich ist. Die Analyse von Übergaben zwischen Teams, der mit jedem Team verbrachten Zeit und des von verschiedenen Teams bearbeiteten Request-Volumens ist entscheidend für das Verständnis der Arbeitslastverteilung, die Identifizierung von Engpässen und die Bewertung der Team-Performance. Es unterstützt direkt Dashboards zur SLA-Einhaltung und Arbeitslast der Bearbeiter. Bedeutung Verfolgt Verantwortlichkeiten und Übergaben, hilft bei der Analyse von Verzögerungen zwischen Teams, der Arbeitslastverteilung und welche Teams Engpässe im Prozess darstellen. Datenquelle Diese Information wird typischerweise in einem Feld wie 'OwnerTeam' im Service Request Objekt oder in zugehörigen Zuweisungs-Records gespeichert. Beispiele IT-ServicedeskNetzwerkbetriebHR-SupportFacility Management
	Abteilung des Anfragenden RequestorDepartment	Die Geschäftsabteilung des Nutzers, der den Service Request eingereicht hat.
Beschreibung Dieses Attribut identifiziert die Abteilung des Mitarbeiters oder Systems, das den Service Request initiiert hat, wie z.B. 'Vertrieb', 'Finanzen' oder 'Personalwesen'. Es ermöglicht die Analyse der Servicequalität und -nachfrage in verschiedenen Teilen der Organisation. Zum Beispiel kann es helfen zu identifizieren, ob bestimmte Abteilungen längere Lösungszeiten haben oder ein höheres Request-Volumen einreichen. Bedeutung Ermöglicht die Analyse des Serviceverbrauchs und der Servicequalität nach Geschäftseinheit, wodurch abteilungsspezifische Probleme oder Trends identifiziert werden können. Datenquelle Diese Information wird normalerweise aus dem Nutzerprofil des Anfragenden abgerufen, das mit dem Service Request verknüpft ist. Das Feld könnte 'Department' im Profile.Employee-Objekt sein. Beispiele FinanzenVertriebMarketingInformationstechnologie
	Anzahl der Zuweisungen AssignmentCount	Die Gesamtzahl der Male, die ein Service Request zugewiesen oder neu zugewiesen wurde.
Beschreibung Diese berechnete Metrik zählt die Anzahl der zuweisungsbezogenen Aktivitäten (z.B. 'Team zugewiesen', 'Bearbeiter zugewiesen') für jeden Service Request. Eine hohe Anzahl von Neu-Zuweisungen, oft als „Ticket-Ping-Pong“ bezeichnet, weist auf Ineffizienzen im Routing, mangelnde Erstkontaktlösung oder unklare Teamverantwortlichkeiten hin. Dieses Attribut ist essenziell für die KPI „Average Reassignments per Request“. Bedeutung Quantifiziert ineffiziente Übergaben und Routing-Probleme. Eine hohe Anzahl ist ein starker Indikator für verlängerte Bearbeitungszeiten und Nutzerfrustration. Datenquelle Berechnet durch Zählen der Vorkommen von zuweisungsbezogenen Aktivitäten für jede eindeutige ServiceRequestID während der Datenvorbereitung. Beispiele 12345
	Ist Nacharbeit IsRework	Ein boolesches Flag, das angibt, ob die Serviceanfrage Nacharbeitsaktivitäten umfasste.
Beschreibung Dieses berechnete Flag wird auf 'true' gesetzt, wenn ein Service Request Anzeichen von Nacharbeiten zeigt, wie z.B. eine Wiedereröffnung nach der Lösung oder wiederholte Aktivitäten in einer Schleife. Es vereinfacht die Berechnung der KPI „Service Request Rework Rate“ und hilft, ineffiziente Prozessinstanzen in Dashboards wie „Rework and Reassignment Flows“ zu filtern. Bedeutung Hilft, das Volumen von Anfragen, die zusätzlichen, ungeplanten Aufwand erfordern, leicht zu identifizieren und zu quantifizieren, wodurch Qualitäts- und Effizienzprobleme hervorgehoben werden. Datenquelle Aus den Daten abgeleitet. Die Logik kann auf dem Attribut 'ReopenCount' basieren, das größer als Null ist, oder durch die Erkennung spezifischer Aktivitätssequenzen, wie z. B. mehrerer 'Assigned to Agent'-Events. Beispiele truefalsch
	Kanal Channel	Die Methode oder der Kanal, über den der Service Request eingereicht wurde.
Beschreibung Der Kanal gibt an, wie der Service Request erstellt wurde, zum Beispiel über das Self-Service Portal, E-Mail, Telefon oder automatisch durch ein anderes System. Die Analyse von Request-Volumen und Lösungszeiten nach Kanal kann Einblicke geben, welche Kanäle am effizientesten sind und welche Prozessverbesserungen oder Nutzersschulungen erfordern könnten. Bedeutung Hilft, das Nutzerverhalten und die Effizienz der Kanäle zu verstehen, was Entscheidungen über die Servicebereitstellungsstrategie und Automatisierungsmöglichkeiten beeinflussen kann. Datenquelle Dies wird oft in einem Feld vom Typ 'Source' oder 'CreatedBy' im Service Request Objekt gespeichert. Beispiele `Self-Service`E-MailTelefonDirekte Eingabe
	Lieferantenname VendorName	Der Name des externen Anbieters, der an der Lösung des Requests beteiligt ist.
Beschreibung Dieses Attribut identifiziert den Drittanbieter, der zur Unterstützung oder Fertigstellung eines Service Requests beauftragt wird. Es ist essenziell für das Dashboard „External Vendor Activity Duration“, da es die Messung und den Vergleich der Performance verschiedener Anbieter ermöglicht. Die Verfolgung dieser Daten hilft beim Management von Anbieterbeziehungen und bei der Identifizierung von Engpässen, die durch externe Abhängigkeiten verursacht werden. Bedeutung Ermöglicht die Analyse der Leistung Dritter und deren Einfluss auf die gesamten Serviceanfrage-Lösungszeiten, was das Lieferantenmanagement unterstützt. Datenquelle Dies könnte ein Feld in einem Aufgabenobjekt sein, das mit dem Service Request verknüpft ist, oder ein spezifisches Feld im Service Request selbst, wenn ein Anbieter zugewiesen ist. Beispiele Dell SupportOracle ConsultingMicrosoft Premiernull
	Lösungskategorie ResolutionCategory	Eine Klassifizierung der für die Serviceanfrage bereitgestellten Lösung.
Beschreibung Die Lösungskategorie bietet eine strukturierte Möglichkeit, zu klassifizieren, wie ein Service Request letztendlich gelöst wurde. Dies ist oft eine hierarchische Klassifikation (z.B. Kategorie, Unterkategorie), die bei der Ursachenanalyse und der Trendberichterstattung hilft. Zum Beispiel kann sie wiederkehrende Probleme oder gängige Arten von Erfüllungsaktionen hervorheben, die zur Verbesserung von Services oder zur Erstellung von Knowledge Base-Artikeln verwendet werden können. Bedeutung Bietet Einblicke in die Art der Lösungen und hilft, häufige Probleme, Möglichkeiten zur Serviceverbesserung und Automatisierungskandidaten zu identifizieren. Datenquelle Oft in Kategorisierungsfeldern gespeichert, die bei der Lösung ausgefüllt werden, wie 'ResolutionCategory' oder ein benutzerdefiniertes Abschlusscode-Feld. Beispiele Nutzerschulung erforderlichSoftware bereitgestelltHardware repariertZugriff gewährt
	Wiedereröffnungsanzahl ReopenCount	Die Anzahl der Male, die ein gelöster Service Request wiedereröffnet wurde.
Beschreibung Dieses Attribut ist ein Zähler, der jedes Mal inkrementiert wird, wenn ein Service Request aus einem 'Gelöst'- oder 'Geschlossen'-Status in einen 'Aktiv'-Status zurückversetzt wird. Eine hohe Wiedereröffnungszahl ist ein starker Indikator für eine mangelhafte Erstlösungsqualität, unvollständige Lösungen oder wiederkehrende Probleme. Es unterstützt direkt die KPI „Service Request Rework Rate“. Bedeutung Misst direkt Nacharbeiten und ist ein Schlüsselindikator für die Lösungsqualität. Hohe Zahlen deuten darauf hin, dass die ursprüngliche Fehlerbehebung nicht effektiv war. Datenquelle Dies ist typischerweise ein Zählerfeld im Service Request Objekt, das durch eine Geschäftsregel inkrementiert wird, wenn sich der Status entsprechend ändert. Es könnte 'ReopenCounter' benannt sein. Beispiele 0123

Erforderlich Empfohlen Optional

Aktivitäten im Service Request Management

Dies sind die wesentlichen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine präzise Prozesserkennung und -analyse zu ermöglichen.

5 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Anfrage einem Agenten zugewiesen	Ein spezifischer Agent übernimmt die Verantwortung für die Serviceanfrage. Diese Aktivität wird typischerweise abgeleitet, wenn das Feld 'Owner', das den einzelnen Agenten bezeichnet, zum ersten Mal gefüllt oder aktualisiert wird.
Bedeutung Dies markiert das Ende der anfänglichen Warte- oder Queue-Zeit. Die Messung der Dauer vor dieser Aktivität hilft, Probleme bei der Ressourcenzuweisung zu identifizieren und unterstützt das Dashboard „Agent Workload“. Datenquelle Abgeleitet aus der Füllung oder Änderung des Feldes 'Owner' im Serviceanfrage-Datensatz, wie in der Audit-Historie ersichtlich. Erfassen Der erste Timestamp, an dem das Feld 'Owner' nach der Erstellung oder Teamzuweisung mit dem Namen eines Bearbeiters befüllt wird. Ereignistyp inferred
	Anfrage einem Team zugewiesen	Der Service Request wird einem spezifischen Support-Team zur Bearbeitung zugewiesen. Dies wird erfasst, indem die Befüllung oder Änderung des Feldes 'OwnerTeam' im Service Request Record beobachtet wird.
Bedeutung Dieses Event ist entscheidend für die Analyse der Team-Performance, der Arbeitslastverteilung und der Übergabezeiten zwischen Teams. Es hilft zu identifizieren, welche Teams Engpässe im Prozess darstellen. Datenquelle Verfolgt durch Änderungen im Feld 'OwnerTeam' innerhalb der Audit-Historie oder des Journals des Service Requests. Erfassen Ein Update-Event für das Feld 'OwnerTeam', das typischerweise in einem Audit Trail protokolliert wird. Ereignistyp explicit
	Serviceanfrage erstellt	Diese Aktivität markiert den Beginn des Service Request Lifecycles, wenn ein neuer Request formal eingereicht und in Ivanti erfasst wird. Dieses Event wird erfasst, wenn ein neuer Record im Service Request Business Objekt erstellt wird, der eine eindeutige Service Request ID generiert.
Bedeutung Dies ist das primäre Start Event für den Prozess. Die Analyse der Zeit von diesem Punkt bis zur Lösung ist fundamental für die Messung der gesamten Zykluszeit und Prozesseffizienz. Datenquelle Dies wird vom Creation Timestamp des Service Request Records erfasst (z.B. Feld CreatedDateTime im ServiceReq Business Objekt). Erfassen Das Record Creation Event in der ServiceReq-Tabelle, identifiziert durch seinen Creation Timestamp. Ereignistyp explicit
	Serviceanfrage gelöst	Der Service Request gilt als gelöst, und die Lösung wurde dem Nutzer bereitgestellt. Dies ist ein primärer Meilenstein, der durch eine Statusänderung auf 'Gelöst' erfasst wird, oft einen SLA-Timer stoppt.
Bedeutung Dies ist ein kritischer Endpunkt zur Messung der Lösungszeit und SLA-Einhaltung. Die Dauer von der Erstellung bis zu dieser Aktivität ist eine Kern-KPI für die Prozess-Performance. Datenquelle Abgeleitet aus einer Änderung des 'Status'-Feldes des Serviceanfrage-Datensatzes zu 'Gelöst', zusammen mit dem zugehörigen Timestamp. Erfassen Erkennung der Aktualisierung des 'Status'-Feldes auf 'Gelöst' aus der Audit-Historie. Ereignistyp inferred
	Serviceanfrage geschlossen	Der Service Request ist offiziell geschlossen, und es können keine weiteren Aktionen durchgeführt werden. Dies geschieht oft automatisch nach einer festgelegten Zeitspanne im Status 'Gelöst' und stellt den endgültigen Abschluss des Lifecycles dar.
Bedeutung Diese Aktivität ist das definitive Ende des Prozesses. Die Zeitspanne zwischen 'Gelöst' und 'Geschlossen' kann Verzögerungen bei der Bestätigung oder automatisierten Systemprozessen aufzeigen. Datenquelle Abgeleitet aus einer Änderung des 'Status'-Feldes des Serviceanfrage-Datensatzes zu 'Geschlossen', zusammen mit dem zugehörigen Timestamp. Erfassen Erkennung der Aktualisierung des 'Status'-Feldes auf 'Geschlossen' aus der Audit-Historie. Ereignistyp inferred
	Anfrage genehmigt	Der Service Request hat alle notwendigen Genehmigungen erhalten und kann nun zur Erfüllung übergehen. Dieses Event wird erfasst, wenn der Genehmigungs-Workflow erfolgreich abgeschlossen wird und den Status des Requests ändert.
Bedeutung Diese Aktivität markiert einen wichtigen Meilenstein, der das Ende der Genehmigungsphase und den Beginn der Erfüllung signalisiert. Sie ermöglicht die Messung der Effizienz des Genehmigungsprozesses selbst. Datenquelle Abgeleitet aus einem Statuswechsel von 'Warten auf Genehmigung' zu 'Genehmigt' oder 'Erfüllt'. Dies kann auch ein explizites Event sein, das im FRS_Approval Business Object protokolliert wurde. Erfassen Eine Änderung im 'Status'-Feld des Serviceanfrage-Datensatzes von einem Genehmigungsstatus zu einem aktiven Status. Ereignistyp inferred
	Anfrage zur Genehmigung eingereicht	Der Service Request wurde zur notwendigen Genehmigung eingereicht, bevor er erfüllt werden kann. Dies wird typischerweise abgeleitet, wenn der Request-Status sich zu 'Eingereicht' oder 'Genehmigung ausstehend' ändert, was oft einen Genehmigungs-Workflow auslöst.
Bedeutung Die Verfolgung dieser Aktivität hilft, Verzögerungen in der Genehmigungsphase zu identifizieren. Lange Wartezeiten hier können ein signifikanter Engpass sein, der die gesamten Lösungszeiten und die Nutzerzufriedenheit beeinflusst. Datenquelle Abgeleitet aus einer Statusänderung im Serviceanfrage-Datensatz, wahrscheinlich zu einem Status wie 'Eingereicht' oder 'Warten auf Genehmigung'. Dies kann auch aus den Business Objects FRS_Approval oder FRS_ApprovalVoteTracking stammen. Erfassen Eine Änderung im 'Status'-Feld des Serviceanfrage-Datensatzes zu einem genehmigungspflichtigen Status. Ereignistyp inferred
	Externer Anbieter eingebunden	Die Service-Request-Erfüllung wurde an einen externen Anbieter oder eine dritte Partei übergeben. Dies wird typischerweise durch eine Statusänderung auf 'Warten auf Drittpartei' oder einen ähnlichen Zustand erfasst.
Bedeutung Diese Aktivität ist essenziell für die Messung der Anbieter-Performance und deren Auswirkungen auf die gesamte Zykluszeit. Sie ermöglicht die Analyse anbieterbezogener Verzögerungen und unterstützt das Dashboard „External Vendor Activity Duration“. Datenquelle Abgeleitet aus einer Statusänderung im Serviceanfrage-Datensatz zu einem Status wie 'Warten auf Dritte' oder 'Anbieter ausstehend'. Erfassen Erkennung einer Änderung im 'Status'-Feld zu einem bestimmten 'Warten auf Anbieter'-Status. Ereignistyp inferred
	Informationen vom Benutzer angefordert	Der zugewiesene Bearbeiter benötigt weitere Informationen vom Anfragenden, um mit der Erfüllung fortzufahren. Dies wird erfasst, wenn der Request-Status auf einen Zustand wie 'Warten auf Kunden' aktualisiert wird.
Bedeutung Diese Aktivität beleuchtet Verzögerungen, die durch unvollständige Ausgangsinformationen verursacht werden. Die Verfolgung ihrer Häufigkeit und Dauer ist entscheidend für die Informationsanfrage-Auswirkungsanalyse und die Identifizierung von Bereichen für Prozessverbesserungen. Datenquelle Abgeleitet aus einer Statusänderung im Serviceanfrage-Datensatz zu einem Status wie 'Warten auf Kunden' oder 'Ausstehend'. Erfassen Erkennung einer Änderung im 'Status'-Feld zu einem bestimmten 'Warten auf Benutzer'-Status. Ereignistyp inferred
	Priorität geändert	Die Priorität des Service Requests wurde nach seiner anfänglichen Erstellung aktualisiert. Dieses Event wird aus dem Audit Log oder der Historie erfasst, die Feldänderungen nachverfolgt.
Bedeutung Die Verfolgung von Prioritätsänderungen ist entscheidend für die Übersicht zur Priorisierungseffektivität. Sie hilft festzustellen, ob Eskalationen korrekt verwaltet werden und ob die anfängliche Priorisierung präzise ist. Datenquelle Dies ist ein explizites Event, das aus der Audit-Historie des Service Request Records erfasst wird, welche Änderungen am Feld 'Priority' protokolliert. Erfassen Ein Update-Event für das Feld 'Priority', das im Audit Trail des Systems aufgezeichnet wird. Ereignistyp explicit
	Service Request storniert	Der Service Request wurde vom Nutzer oder einem Bearbeiter vor der Lösung storniert. Dies ist ein alternativer Endzustand, der durch eine Statusänderung auf 'Storniert' oder 'Zurückgezogen' erfasst wird.
Bedeutung Dies stellt eine nicht-standardisierte Prozessbeendigung dar. Die Analyse, warum Requests storniert werden, kann Probleme mit dem Request-Prozess selbst oder sich ändernde Nutzerbedürfnisse aufdecken. Datenquelle Abgeleitet aus einer Änderung des 'Status'-Feldes des Serviceanfrage-Datensatzes zu 'Abgebrochen'. Erfassen Erkennung der Aktualisierung des 'Status'-Feldes auf 'Abgebrochen' aus der Audit-Historie. Ereignistyp inferred
	Serviceanfrage erfüllt	Alle zur Erfüllung der Serviceanfrage erforderlichen Aufgaben wurden vom Agenten oder System abgeschlossen. Dies wird durch eine Statusänderung zu 'Erfüllt' erfasst, die oft dem endgültigen 'Resolved'-Status vorausgeht.
Bedeutung Dieser Meilenstein markiert den Abschluss der technischen oder prozeduralen Arbeit. Er ist ein Schlüsselpunkt für die Messung der aktiven Bearbeitungszeit vor der endgültigen Bestätigung und dem Abschluss. Datenquelle Abgeleitet aus einer Änderung des 'Status'-Feldes des Serviceanfrage-Datensatzes zu 'Erfüllt'. Erfassen Eine Änderung des 'Status'-Feldes zu 'Erfüllt', ermittelt aus der Historie des Datensatzes. Ereignistyp inferred
	Serviceanfrage wiedereröffnet	Eine zuvor gelöste Serviceanfrage wurde reaktiviert, da das Problem weiterhin besteht oder die Lösung unzureichend war. Dies wird erfasst, wenn der Status von 'Resolved' (Gelöst) zurück in einen aktiven Status wie 'Active' (Aktiv) oder 'Assigned' (Zugewiesen) wechselt.
Bedeutung Diese Aktivität ist ein direkter Indikator für Nacharbeiten und eine mangelhafte Erstlösungsqualität. Die Analyse von Reopen Events hilft, Prozessschwächen zu identifizieren und die KPI „Service Request Rework Rate“ zu verbessern. Datenquelle Abgeleitet aus der Audit-Historie, wenn sich das 'Status'-Feld von 'Resolved' oder 'Closed' in einen aktiven Status ändert. Erfassen Ein Statuswechsel von einem Endstatus ('Resolved', 'Closed') zu einem offenen Status ('Active', 'Assigned'). Ereignistyp inferred
	Vom Benutzer bereitgestellte Informationen	Der Anfragende hat die notwendigen Informationen bereitgestellt, sodass der Bearbeiter die Arbeit wieder aufnehmen kann. Dies wird erfasst, wenn der Request den Status 'Warten auf Kunden' verlässt und in einen aktiven Zustand zurückkehrt.
Bedeutung Dieses Event schließt den Kreis der Informationsanfragen. Die Zeitspanne zwischen Anforderung und Erhalt von Informationen ist eine kritische Komponente von Prozessverzögerungen und Nacharbeitschleifen. Datenquelle Abgeleitet, wenn sich das 'Status'-Feld des Service Requests von einem 'Warten auf Kunden'-Status in einen aktiven Status ändert, wie 'Aktiv' oder 'In Bearbeitung'. Erfassen Erkennung eines Statuswechsels von einem 'Warten auf Benutzer'-Status zu einem aktiven Status. Ereignistyp inferred

Extraktionsleitfäden

So erhalten Sie Ihre Daten vom Ivanti Service Manager

Schritte

Melden Sie sich mit einer Rolle im Ivanti Service Manager an, die Lesezugriff auf Serviceanfragen und deren Audit-Historie hat.
Navigieren Sie über das Hauptnavigationspanel zum Service Request Workspace.
Dieser Prozess erfordert zwei separate Datenexporte, die extern kombiniert werden. Der erste erfasst das Erstellungsereignis und die Kernattribute, der zweite die detaillierte Änderungsverlauf.
Erster Export (Erstellungsereignisse): Erstellen Sie eine neue "Saved Search" auf dem ServiceReq Business Object. Legen Sie einen Filter für CreatedDateTime fest, um Serviceanfragen auszuwählen, die innerhalb Ihres gewünschten Analysezeitraums erstellt wurden, z. B. die letzten sechs Monate.
Konfigurieren Sie die Spalten für die Erstellungsabfrage so, dass sie RecId, ServiceReqNumber (für ServiceRequestID), CreatedDateTime (für EventTime), SvcReqTmplLink_Category (für ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime und TargetDateTime (für SLADeadline) enthalten.
Führen Sie die Suche aus und verwenden Sie die Exportfunktion des Rasters, typischerweise ein Symbol, das einer Diskette oder einem Pfeil ähnelt, um die Daten in eine CSV-Datei zu exportieren. Nennen Sie diese ServiceRequests.csv.
Zweiter Export (Audit History Events): Erstellen Sie eine neue "Saved Search", diesmal auf dem FRS_data_audit_history Business Object, welches Feldänderungen protokolliert.
Filtern Sie diese Suche, um nur Änderungen im Zusammenhang mit Serviceanfragen einzuschließen. Fügen Sie einen Filter hinzu, bei dem ParentObjectType gleich 'ServiceReq' ist. Fügen Sie außerdem einen Filter auf AuditDate für denselben Analysezeitraum hinzu, den Sie zuvor verwendet haben.
Konfigurieren Sie die Spalten für die Audit-Suche so, dass sie ParentLink_RecID (zurück zum Service Request), FieldName, OldValue, NewValue und AuditDate (für EventTime) enthalten. Exportieren Sie diese Daten in eine zweite CSV-Datei namens AuditHistory.csv.
Datentransformation und -kombination: Die exportierten CSV-Dateien müssen kombiniert und zu einem einzigen Event Log umgeformt werden. Verwenden Sie ein Datenvorbereitungstool wie Power Query in Excel, Python oder ein Datenbanktool, um die folgenden Schritte durchzuführen:
- Laden Sie sowohl ServiceRequests.csv als auch AuditHistory.csv.
- Verwenden Sie die Datei ServiceRequests.csv, um das Event 'Service Request Created' für jede Anfrage zu generieren.
- Verwenden Sie die Datei AuditHistory.csv, um alle anderen Events zu generieren. Ordnen Sie die Werte in den Spalten FieldName und NewValue den erforderlichen Aktivitätsnamen zu, z. B. wenn FieldName 'Status' und NewValue 'Resolved' ist, wird der ActivityName zu 'Service Request Resolved'.
- Verbinden Sie die transformierten Audit-Events mit den Serviceanfragedaten, indem Sie ParentLink_RecID aus der Audit-Datei und RecId aus der Serviceanfrage-Datei verwenden. Dies fügt die Case-Level-Attribute zu jedem Event hinzu.
- Kombinieren Sie die 'Created'-Events und die aus dem Audit abgeleiteten Events in einer einzigen Tabelle.
Formatieren Sie die endgültige kombinierte Tabelle mit den erforderlichen Spaltenüberschriften: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate und anderen empfohlenen Attributen. Stellen Sie sicher, dass alle Timestamps in einem konsistenten Format vorliegen.
Speichern Sie das finale Event Log als eine einzige CSV-Datei, bereit für den Upload.

Konfiguration

Business Objects: Diese Methode erfordert den Export aus zwei separaten Business Objects: ServiceReq für die Hauptanfragedaten und FRS_data_audit_history für die Event-Daten.
Date Range Filter: Es ist entscheidend, einen Datumsbereichsfilter auf beide Exporte anzuwenden, um das Datenvolumen zu steuern. Verwenden Sie das Feld CreatedDateTime für ServiceReq und das Feld AuditDate für FRS_data_audit_history. Ein Zeitraum von 3-6 Monaten wird für die initiale Analyse empfohlen.
Key Filters for Audit History:
- ParentObjectType muss auf 'ServiceReq' gefiltert werden, um sicherzustellen, dass Sie nur Änderungen im Zusammenhang mit Serviceanfragen extrahieren.
- Sie können optional das FieldName filtern, um nur für Ihren Prozess relevante Felder wie 'Status', 'Owner', 'OwnerTeam' und 'Priority' einzuschließen, was die Exportgröße erheblich reduzieren kann.
Prerequisites: Ein Benutzerkonto im 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 ist erforderlich.
Performance Considerations: Die Tabelle FRS_data_audit_history kann sehr groß sein. Das Exportieren von Daten ohne einen restriktiven Datumsfilter kann zu Leistungsproblemen für die Ivanti-Anwendung führen und einen Timeout verursachen. Erwägen Sie bei Bedarf, Daten in kleineren monatlichen oder quartalsweisen Stapeln zu exportieren.

a Beispielabfrage config

-- 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 notwendigen Bibliotheken, requests für API-Aufrufe und pandas für die Datenmanipulation, indem Sie pip install requests pandas ausführen. Beschaffen Sie einen API-Schlüssel von Ihrem Ivanti Service Manager-Administrator mit mindestens Leseberechtigungen für die Business Objects ServiceReq und FRS_Audit_ServiceReq.
Skript konfigurieren: Laden Sie das bereitgestellte Python-Skript herunter. Öffnen Sie das Skript in einem Texteditor oder einer IDE und aktualisieren Sie die Platzhaltervariablen am Anfang: TENANT_URL, API_KEY, START_DATE und END_DATE, um sie an Ihre Ivanti-Umgebung und den gewünschten Extraktionszeitraum anzupassen.
Skript ausführen: Führen Sie das Skript über Ihre Befehlszeile mit python your_script_name.py aus. Das Skript wird zunächst eine Meldung ausgeben, die anzeigt, dass es sich mit der Ivanti-API verbindet und authentifiziert.
Service Request Daten abrufen: Das Skript beginnt damit, das Business Object ServiceReq nach allen Anfragen abzufragen, die innerhalb des angegebenen Datumsbereichs erstellt wurden. Es handhabt automatisch die API-Paginierung, um die vollständige Liste der Anfragen abzurufen, und gibt Fortschrittsaktualisierungen aus, während es jede Datenseite abruft.
Audit-Historie abrufen: Für jede abgerufene Serviceanfrage führt das Skript eine sekundäre Abfrage auf dem Business Object FRS_Audit_ServiceReq durch. Dies ruft die vollständige Feldänderungshistorie für diese spezifische Anfrage ab, was für den Aufbau des detaillierten Event Logs unerlässlich ist.
'Created'-Event generieren: Während das Skript jede Serviceanfrage verarbeitet, erstellt es zuerst das Event 'Service Request Created'. Der Timestamp für dieses Event wird direkt aus dem Feld CreatedDateTime des Serviceanfrage-Datensatzes entnommen.
Events aus Audit Trail generieren: Das Skript durchläuft dann die Audit Trail-Datensätze für jede Serviceanfrage. Es analysiert jeden Datensatz, um Änderungen in Schlüsselfeldern wie Status, OwnerTeam, Owner und Priority zu identifizieren.
Änderungen Aktivitäten zuordnen: Eine vordefinierte Mapping-Logik innerhalb des Skripts wandelt diese Feldänderungen in spezifische Aktivitätsnamen um. Zum Beispiel wird eine Änderung im Status-Feld von 'Active' zu 'Resolved' als Aktivität 'Service Request Resolved' erfasst.
Event Log erstellen: Alle generierten Events, sowohl die initiale Erstellung als auch die nachfolgenden Änderungen aus dem Audit Trail, werden in einer strukturierten Liste kompiliert. Jedes Event enthält die Service Request ID, den Aktivitätsnamen, den Timestamp und andere relevante Attribute.
Datentransformation und -formatierung: Die gesammelte Liste der Events wird in einen Pandas DataFrame konvertiert. Das Skript stellt sicher, dass alle Spalten dem erforderlichen Schema für ProcessMind entsprechen, einschließlich ServiceRequestID, ActivityName und EventTime.
Export nach CSV: Sobald alle Serviceanfragen und ihre Historien verarbeitet wurden, speichert das Skript den finalen DataFrame in einer CSV-Datei namens ivanti_servicereq_event_log.csv im selben Verzeichnis, in dem das Skript ausgeführt wurde. Diese Datei ist zum Upload bereit.

Konfiguration

API Endpoint URL: Die Basis-URL für die REST-API Ihres Ivanti Service Manager Tenants. Diese sollte in der Variable TENANT_URL im Skript hinterlegt werden, zum Beispiel https://your-tenant.ivanti.com.
API Key: Ein gültiger REST-API-Schlüssel, der in der Ivanti Administrationskonsole generiert wurde. Dieser Schlüssel muss einer Rolle zugeordnet sein, die Leseberechtigungen für die Business Objects ServiceReq und FRS_Audit_ServiceReq besitzt.
Date Range: Das Skript erfordert ein START_DATE und END_DATE im Format 'JJJJ-MM-TT'. Für eine erste Analyse wird ein Datumsbereich von 3 bis 6 Monaten empfohlen, um ein überschaubares Datenvolumen zu gewährleisten und gleichzeitig genügend Prozessvariationen zu erfassen.
Page Size (TOP_COUNT): Diese Variable im Skript definiert die Anzahl der Datensätze, die pro API-Aufruf abgerufen werden. Der Standardwert ist 500, was ein gutes Gleichgewicht zwischen Leistung und Speichernutzung darstellt. Sie können diesen Wert basierend auf der Leistung Ihres API-Servers anpassen.
Required Fields (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): Das Skript legt fest, welche Felder von der API abgerufen werden sollen, um die Payload-Größe zu minimieren. Stellen Sie sicher, dass alle Felder, die für die erforderlichen und empfohlenen Attribute benötigt werden, in diesen Listen enthalten sind.

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()

Ihr Service Request Management Daten-Template

Ihr Service Request Management Daten-Template

Attribute im Service Request Management

Aktivitäten im Service Request Management

Extraktionsleitfäden

Ivanti Saved Search und Grid-Datenexport nach CSV

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Ivanti REST API

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Beginnen Sie noch heute mit der Optimierung Ihres Service Request Managements

Ihr Service Request Management Daten-Template

Ihr Service Request Management Daten-Template

Attribute im Service Request Management

Aktivitäten im Service Request Management

Extraktionsleitfäden

Ivanti Saved Search und Grid-Datenexport nach CSV

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Ivanti REST API

Schritte

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Beginnen Sie noch heute mit der Optimierung Ihres Service Request Managements