> Continue verbetering > Beheer van serviceaanvragen > Ivanti Service Manager > datatemplate

Uw Service Request Management Data Template

Ivanti Service Manager

Service Request Management `Attributes` (22) Service Request Management Activiteiten (14) Extractie Guides (2)

Uw Service Request Management Data Template

Deze template biedt een uitgebreide gids voor het verzamelen van de essentiële data die nodig is voor effectieve process mining van uw serviceaanvraagbeheer. Het beschrijft de cruciale attributes om te verzamelen, belangrijke activiteiten om te volgen en bevat praktische richtlijnen voor het extraheren van deze informatie uit uw systeem. Gebruik deze bron om een robuust event log voor uw analyse op te bouwen.

Aanbevolen attributen voor uitgebreide analyse
Belangrijkste activities om te volgen voor proces discovery
Begeleiding bij data-extractie uit uw bronsysteem

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Service Request Management `Attributes`

Dit zijn de aanbevolen data fields om op te nemen in uw event log voor een uitgebreide analyse van uw serviceaanvraagbeheerproces.

5 Verplicht 10 Aanbevolen 7 Optioneel

	Naam	Omschrijving
	Activiteitsnaam ActivityName	De naam van de event of taak die op een specifiek punt plaatsvond in de levenscyclus van de serviceaanvraag.
Omschrijving Dit attribuut beschrijft een specifieke stap of statuswijziging binnen het serviceaanvraagproces, zoals 'Aanvraag ingediend voor goedkeuring' of 'Serviceaanvraag afgehandeld'. Het analyseren van de sequentie en frequentie van activiteiten is fundamenteel voor het begrijpen van de processtroom, het identificeren van knelpunten en het ontdekken van afwijkingen van de standaardprocedure. Het belang Het definieert de stappen in de proceskaart, waardoor de visualisatie en analyse van de processtroom mogelijk is, inclusief het identificeren van herstelwerk, knelpunten en afwijkingen. Vindplaats Doorgaans afgeleid van statuswijzigingen, journaalboekingen, of audit log event beschrijvingen binnen Ivanti Service Manager. Voorbeelden Serviceverzoek AangemaaktAanvraag GoedgekeurdServiceaanvraag opgelostService Request Gesloten
	Serviceverzoek ID ServiceRequestID	De unieke identificatie voor elke serviceaanvraag.
Omschrijving De Service Request ID identificeert uniek elke individuele serviceaanvraag die is ingediend door een gebruiker of systeem. Het dient als de centrale draad die alle volgende events met elkaar verbindt, van initiële registratie tot definitieve afsluiting, waardoor een complete, end-to-end analyse van het traject van elke serviceaanvraag mogelijk is. Het belang Dit is de essentiële case identifier die alle gerelateerde activiteiten verbindt tot één procesinstantie, waardoor end-to-end procesanalyse mogelijk wordt. Vindplaats Dit is de primaire sleutel van het Service Request business object, vaak te vinden als ServiceReqNumber in de ServiceReq-tabel. Voorbeelden SR-0012345SR-0012346SR-0012347
	Tijdstip Gebeurtenis EventTime	De tijdstempel die aangeeft wanneer een specifieke activiteit of gebeurtenis heeft plaatsgevonden.
Omschrijving Event Time, ook bekend als de starttijd, is de precieze datum en tijd waarop een activiteit in het systeem werd vastgelegd. Deze timestamp is cruciaal voor het correct sequencen van events en vormt de basis voor alle tijdsgebonden process mining-analyse, zoals het berekenen van doorlooptijden, wachttijden en activiteitsduren. Het belang Deze timestamp is essentieel voor het chronologisch ordenen van events en het berekenen van alle op duur gebaseerde metrieken, die essentieel zijn voor prestatieanalyse. Vindplaats Gevonden in audit logs, journaalposten (bijv. Journal.CreatedDateTime), of statuswijzigingsrecords gerelateerd aan de Serviceaanvraag. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Bronsysteem SourceSystem	Het systeem waaruit de data is geëxtraheerd.
Omschrijving Dit attribuut identificeert de herkomst van de procesdata. Voor deze weergave zal de waarde constant zijn, wat aangeeft dat alle data afkomstig is van Ivanti Service Manager. Dit is belangrijk in omgevingen waar data mogelijk wordt samengevoegd uit meerdere systemen, waardoor een duidelijke data lineage en context wordt gewaarborgd. Het belang Het biedt cruciale context over de herkomst van data, waardoor analyses correct worden toegeschreven aan het specifieke bronsysteem, vooral in multi-systeemomgevingen. Vindplaats Dit is doorgaans een vaste waarde die tijdens het data-extractieproces wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Ivanti Service Manager
	Laatste data-update LastDataUpdate	De timestamp van de meest recente gegevensverversing uit het bronsysteem.
Omschrijving Dit attribuut geeft de datum en tijd aan wanneer de data voor het laatst is geëxtraheerd uit Ivanti Service Manager. Het biedt context over de actualiteit van de geanalyseerde data, waarbij wordt gewaarborgd dat gebruikers op de hoogte zijn van de periode die door de analyse wordt gedekt en wanneer de volgende update kan worden verwacht. Het belang Informeert gebruikers over de actualiteit van de data, wat cruciaal is voor het nemen van beslissingen op basis van de meest actuele beschikbare procesprestatie-informatie. Vindplaats Deze waarde wordt gegenereerd en gestempeld op de dataset op het moment van data-extractie. Voorbeelden 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Afhandeling Timestamp ResolutionDateTime	De datum en tijd waarop de serviceaanvraag officieel is afgehandeld.
Omschrijving Dit is een case-level attribuut dat de uiteindelijke timestamp markeert wanneer de service werd geleverd of het probleem werd opgelost, voordat de aanvraag formeel wordt afgesloten. Deze timestamp is het primaire eindpunt voor het berekenen van de end-to-end doorlooptijd van een serviceaanvraag. Het is een kritiek onderdeel voor het meten van de algehele procesefficiëntie en SLA-naleving. Het belang Definieert het eindpunt voor de berekening van de doorlooptijd van het kernproces, een key performance indicator voor de efficiëntie van dienstverlening. Vindplaats Een specifiek timestamp-veld op het Service Request-object, vaak genaamd 'ResolvedDateTime' of vergelijkbaar. Voorbeelden 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Doorlooptijd CycleTime	De totale tijd vanaf de aanmaak van de serviceaanvraag tot de definitieve afhandeling.
Omschrijving Cycle Time is een berekende metric die de duur meet van de eerste event (Service Request Created) tot de afhandelings-event (Service Request Resolved). Het is een van de belangrijkste key performance indicators voor procesefficiëntie. Deze metric wordt uitgebreid gebruikt in dashboards om de algehele prestaties te volgen en trends over tijd te identificeren. Het belang Dit is een primaire KPI voor het meten van de end-to-end procesefficiëntie en weerspiegelt direct de service-ervaring vanuit het oogpunt van de gebruiker. Vindplaats Berekend door de creatie-timestamp af te trekken van de afhandelings-timestamp voor elke serviceaanvraag. Voorbeelden 25920000060480000086400000
	Eindtijd van het event EventEndTime	De timestamp waarop een activiteit is afgerond.
Omschrijving De Event End Time markeert de voltooiing van een activiteit. De duur tussen de Event Time (start) en Event End Time vertegenwoordigt de verwerkingstijd voor die specifieke activiteit. Dit is cruciaal voor het identificeren welke stappen in het proces de meeste tijd in beslag nemen, en helpt inefficiënties en verbeterpunten aan te wijzen. Het belang Het maakt de berekening van individuele activiteitsduren mogelijk, wat essentieel is voor het identificeren van knelpunten in processen en langdurige taken. Vindplaats Bestaat mogelijk niet als een afzonderlijk veld. Vaak is het de starttijd van de volgende activiteit in de sequentie voor dezelfde case. Voorbeelden 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Prioriteit Priority	Het prioriteitsniveau toegewezen aan de serviceaanvraag.
Omschrijving Prioriteit geeft de urgentie van een serviceaanvraag aan, doorgaans op een schaal zoals 'Laag', 'Medium', 'Hoog', 'Kritiek'. Dit attribuut is fundamenteel voor het evalueren of het proces aanvragen met hoge prioriteit effectief versnelt. Analyse omvat vaak het vergelijken van doorlooptijden en SLA-naleving over verschillende prioriteitsniveaus om te waarborgen dat de prioriteringsregels werken zoals bedoeld. Het belang Cruciaal voor het beoordelen van de effectiviteit van de prioriteringsstrategie en het waarborgen dat aanvragen met hoge prioriteit sneller worden afgehandeld dan die met lage prioriteit. Vindplaats Een standaardveld op het Service Request-object, meestal genaamd 'Prioriteit'. Voorbeelden 1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
	Service Request Status ServiceRequestStatus	De status van de serviceaanvraag op het moment van de event.
Omschrijving Dit attribuut legt de status van de serviceaanvraag vast, zoals 'Geregistreerd', 'In Behandeling', 'In Afwachting', 'Afgehandeld' of 'Gesloten'. Statuswijzigingen definiëren vaak de activiteiten in het proces log. Het analyseren van de tijd doorgebracht in elke status kan knelpunten onthullen, bijvoorbeeld als aanvragen te lang in een 'In Afwachting'-status blijven. Het belang Biedt een momentopname van de status van de aanvraag op elk moment, wat essentieel is voor het berekenen van de tijd besteed in specifieke statussen en het identificeren van processtagnaties. Vindplaats Een standaardveld op het Service Request-object, algemeen genaamd 'Status'. Voorbeelden VastgelegdActiefWachten op `klant`AfgehandeldGesloten
	Serviceaanvraagtype ServiceRequestType	De classificatie of categorie van de serviceaanvraag.
Omschrijving Dit attribuut categoriseert de serviceaanvraag, bijvoorbeeld 'Hardware aanvraag', 'Software installatie' of 'Wachtwoord reset'. Het is een kritieke dimensie voor analyse, waardoor teams procesprestaties, doorlooptijden en SLA-naleving kunnen vergelijken over verschillende typen diensten. Het begrijpen van deze verschillen helpt bij het afstemmen van procesverbeteringen en het effectiever toewijzen van middelen. Het belang Het segmenteren van het proces op type aanvraag maakt gerichte analyse mogelijk en onthult of bepaalde soorten aanvragen gevoeliger zijn voor vertragingen, herbewerking of SLA-schendingen. Vindplaats Waarschijnlijk een veld op het Service Request business object, vaak genaamd 'Service' of 'Categorie'. Raadpleeg de Ivanti Service Manager-documentatie voor specifieke veldnamen zoals 'SvcReqTmplLink_Category'. Voorbeelden Nieuwe hardware aanvraagSoftwaretoegangAccountwijzigingInformatieaanvraag
	SLA-deadline SLADeadline	De timestamp waartegen de serviceaanvraag naar verwachting moet zijn afgehandeld.
Omschrijving De SLA-deadline is de berekende datum en tijd waartegen een serviceaanvraag moet zijn afgehandeld om te voldoen aan de Service Level Agreement. Dit doel wordt doorgaans bepaald op basis van factoren zoals de prioriteit en het type van de aanvraag. Het vergelijken van de werkelijke afhandeltijd met deze deadline is de basis voor het meten van SLA-naleving. Het belang Het is de benchmark waartegen de werkelijke prestaties worden gemeten, wat direct de berekening van SLA-nalevingspercentages ondersteunt en risicovolle aanvragen identificeert. Vindplaats Dit is vaak een berekend veld binnen Ivanti, opgeslagen in velden gerelateerd aan de Service Level Agreement of Offering, zoals 'ResolutionTargetDateTime'. Voorbeelden 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	SLA-Status SLAStatus	Geeft aan of de serviceaanvraag binnen de SLA-deadline is afgehandeld.
Omschrijving Dit is een afgeleid attribuut dat elke serviceaanvraag markeert als 'Voldaan' of 'Overtreden' op basis van de oplostijd ten opzichte van de SLA-deadline. Het is de basis voor het 'SLA Naleving Prestaties' dashboard en de 'Service Level Agreement Nalevingspercentage' KPI. De logica vergelijkt de ResolutionDateTime met de SLADeadline voor elke case. Het belang Meet direct de prestaties ten opzichte van serviceverplichtingen, wat cruciaal is voor het beoordelen van servicekwaliteit en het behouden van gebruikersvertrouwen. Vindplaats Berekend door 'ResolutionDateTime' te vergelijken met de 'SLADeadline'. Als ResolutionDateTime <= SLADeadline, is de status 'Behaald'; anders is deze 'Overtreden'. Voorbeelden BehaaldOverschreden
	Toegewezen agent AssignedAgent	De individuele gebruiker of agent toegewezen aan de serviceaanvraag.
Omschrijving De toegewezen agent is de specifieke persoon die verantwoordelijk is voor de afhandeling van de serviceaanvraag. Dit attribuut maakt analyse op individueel niveau mogelijk, wat nuttig is voor prestatiemanagement, taakverdeling en het identificeren van trainingsmogelijkheden. Het volgen van herverdelingen tussen agenten is essentieel voor het berekenen van KPI's zoals 'Gemiddeld aantal herverdelingen per aanvraag' en voor het begrijpen van procesinefficiënties. Het belang Maakt analyse mogelijk van individuele werkbelasting, prestaties en herverdelingspatronen, wat kan wijzen op problemen met training, vaardigheden of initiële routering. Vindplaats Doorgaans te vinden in een veld zoals 'Eigenaar' op het Service Request object. Dit kan veranderen bij elke herverdeling en moet worden bijgehouden in het event log. Voorbeelden Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Toegewezen Team AssignedTeam	Het supportteam of de groep momenteel toegewezen om de serviceaanvraag af te handelen.
Omschrijving Dit attribuut identificeert het team dat verantwoordelijk is voor het uitvoeren van de serviceaanvraag op een bepaald moment. Het analyseren van overdrachten tussen teams, de tijd doorgebracht met elk team en het volume aan aanvragen afgehandeld door verschillende teams is cruciaal voor het begrijpen van de werklastverdeling, het identificeren van knelpunten en het evalueren van teamprestaties. Het ondersteunt direct dashboards gerelateerd aan SLA-naleving en agentwerklast. Het belang Volgt verantwoordelijkheid en overdrachten, helpt bij het analyseren van vertragingen tussen teams, werklastbalans en welke teams knelpunten vormen in het proces. Vindplaats Deze informatie wordt doorgaans opgeslagen in een veld zoals 'OwnerTeam' op het Service Request object of in gerelateerde toewijzingsrecords. Voorbeelden IT Servicedesk`Netwerkbeheer`HR SupportFaciliteitenbeheer
	Aantal Heropeningen ReopenCount	Het aantal keren dat een afgehandelde serviceaanvraag opnieuw is geopend.
Omschrijving Dit attribuut is een teller die toeneemt telkens wanneer een serviceaanvraag vanuit een 'Afgehandeld' of 'Gesloten' status terug naar een 'Actief' status wordt verplaatst. Een hoog aantal heropeningen is een sterke indicator van een slechte 'first-time resolution' kwaliteit, onvolledige oplossingen of terugkerende problemen. Het ondersteunt direct de 'Service Request Herbewerkingspercentage' KPI. Het belang Meet direct herstelwerk en is een belangrijke indicator van de kwaliteit van de oplossing. Hoge aantallen suggereren dat de initiële oplossing niet effectief was. Vindplaats Dit is doorgaans een teller-veld op het Service Request object dat wordt verhoogd door een bedrijfsregel wanneer de status passend verandert. Het kan 'ReopenCounter' heten. Voorbeelden 0123
	Aantal toewijzingen AssignmentCount	Het totale aantal keren dat een serviceaanvraag is toegewezen of herverdeeld.
Omschrijving Deze berekende metriek telt het aantal toewijzingsgerelateerde activiteiten (bijv. 'Toegewezen aan team', 'Toegewezen aan agent') voor elke serviceaanvraag. Een hoog aantal herverdelingen, vaak 'ticket ping-pong' genoemd, duidt op inefficiënties in routering, gebrek aan 'first-contact resolution' of onduidelijke teamverantwoordelijkheden. Dit attribuut is essentieel voor de 'Gemiddeld aantal herverdelingen per aanvraag' KPI. Het belang Kwantificeert inefficiënte overdrachten en routeringsproblemen. Een hoog aantal is een sterke indicator voor langere oplostijden en frustratie bij gebruikers. Vindplaats Berekend door het aantal toewijzingsgerelateerde activiteiten te tellen voor elke unieke ServiceRequestID tijdens datavoorbereiding. Voorbeelden 12345
	Afdeling aanvrager RequestorDepartment	De zakelijke afdeling van de gebruiker die de serviceaanvraag heeft ingediend.
Omschrijving Dit attribuut identificeert de afdeling van de medewerker of het systeem dat de serviceaanvraag heeft geïnitieerd, zoals 'Verkoop', 'Financiën' of 'Human Resources'. Het maakt analyse van servicekwaliteit en -vraag mogelijk binnen verschillende onderdelen van de organisatie. Het kan bijvoorbeeld helpen identificeren of bepaalde afdelingen langere oplostijden ervaren of een hoger volume aan aanvragen indienen. Het belang Maakt analyse mogelijk van serviceverbruik en -kwaliteit per business unit, wat helpt bij het identificeren van afdelingsspecifieke problemen of trends. Vindplaats Deze informatie wordt meestal opgehaald uit het gebruikersprofiel van de aanvrager, gekoppeld aan de Service Request. Het veld kan 'Department' zijn in het Profile.Employee object. Voorbeelden FinanciënVerkoopMarketingInformatietechnologie
	Afhandelingscategorie ResolutionCategory	Een classificatie van de geboden oplossing voor de serviceaanvraag.
Omschrijving De Afhandelingscategorie biedt een gestructureerde manier om te classificeren hoe een serviceaanvraag uiteindelijk is afgehandeld. Dit is vaak een hiërarchische classificatie (bijv. Categorie, Subcategorie) die helpt bij root cause analysis en trendrapportage. Het kan bijvoorbeeld terugkerende problemen of veelvoorkomende typen afhandelingsacties benadrukken, die kunnen worden gebruikt om diensten te verbeteren of knowledge base artikelen te creëren. Het belang Biedt inzichten in de aard van oplossingen, wat helpt bij het identificeren van veelvoorkomende problemen, serviceverbeteringsmogelijkheden en automatiseringskandidaten. Vindplaats Vaak opgeslagen in categorisatievelden die worden ingevuld bij afhandeling, zoals 'ResolutionCategory' of een aangepast sluitingscodeveld. Voorbeelden Gebruikerstraining vereistSoftware geïmplementeerdHardware gerepareerdToegang verleend
	Is herstelwerk IsRework	Een booleaanse vlag die aangeeft of de serviceaanvraag herstelwerkzaamheden omvatte.
Omschrijving Deze berekende vlag wordt ingesteld op 'waar' als een serviceaanvraag tekenen van herbewerking vertoont, zoals opnieuw worden geopend na afhandeling of bepaalde activiteiten herhaaldelijk in een lus uitvoeren. Het vereenvoudigt de berekening van de 'Service Request Herbewerkingspercentage' KPI en helpt bij het filteren op inefficiënte procesinstanties in dashboards zoals 'Herbewerking en Herverdeling Flows'. Het belang Helpt om eenvoudig het volume aan aanvragen te identificeren en te kwantificeren die extra, ongeplande inspanning vereisen, wat kwaliteits- en efficiëntieproblemen benadrukt. Vindplaats Afgeleid van de data. De logica kan gebaseerd zijn op het 'ReopenCount'-attribuut dat groter is dan nul, of door specifieke activiteitssequenties te detecteren, zoals meerdere 'Toegewezen aan Agent'-events. Voorbeelden truefalse
	Kanaal Channel	De methode of het kanaal waarlangs de serviceaanvraag is ingediend.
Omschrijving Het kanaal geeft aan hoe de serviceaanvraag is aangemaakt, bijvoorbeeld via de Self-Service Portal, e-mail, telefoon, of automatisch door een ander systeem. Het analyseren van aanvraagvolumes en oplostijden per kanaal kan inzicht geven in welke kanalen het meest efficiënt zijn en welke mogelijk procesverbeteringen of gebruikerstraining vereisen. Het belang Helpt bij het begrijpen van gebruikersgedrag en kanaalefficiëntie, wat beslissingen kan informeren over de servicedienstverleningsstrategie en automatiseringsmogelijkheden. Vindplaats Dit wordt vaak opgeslagen in een veld van het type 'Bron' of 'Aangemaakt door' op het Service Request object. Voorbeelden `Self Service`E-mailTelefoonDirecte invoer
	Naam Leverancier VendorName	De naam van de externe leverancier die betrokken is bij het afhandelen van de aanvraag.
Omschrijving Dit attribuut identificeert de externe leverancier die is ingeschakeld om te helpen bij of een serviceaanvraag te voltooien. Het is essentieel voor het 'Externe Leveranciersactiviteit Duur' dashboard, aangezien het meten en vergelijken van de prestaties van verschillende leveranciers mogelijk maakt. Het volgen hiervan helpt bij het beheren van leveranciersrelaties en het identificeren van knelpunten veroorzaakt door externe afhankelijkheden. Het belang Maakt analyse mogelijk van de prestaties van derden en hun impact op de algehele afhandeltijden van serviceaanvragen, ter ondersteuning van leveranciersmanagement. Vindplaats Dit kan een veld zijn op een taakobject geassocieerd met de serviceaanvraag, of een specifiek veld op de Service Request zelf indien een leverancier is toegewezen. Voorbeelden Dell SupportOracle ConsultingMicrosoft Premiernull

Verplicht Aanbevolen Optioneel

Service Request Management Activiteiten

Dit zijn de essentiële processtappen en mijlpalen om vast te leggen in uw event log voor accurate procesontdekking en -analyse.

5 Aanbevolen 9 Optioneel

	Activiteit	Omschrijving
	Aanvraag toegewezen aan medewerker	Een specifieke agent neemt de eigendom van de serviceaanvraag op zich. Deze activiteit wordt doorgaans afgeleid wanneer het 'Eigenaar'-veld, dat de individuele agent aanduidt, voor het eerst wordt ingevuld of bijgewerkt.
Het belang Dit markeert het einde van de initiële wacht- of wachtrijtijd. Het meten van de duur vóór deze activiteit helpt bij het identificeren van problemen met resourceallocatie en ondersteunt het Agent Werklast dashboard. Vindplaats Afgeleid uit het vullen of wijzigen van het 'Eigenaar'-veld in de Service Request-record, zoals te zien in de audithistorie. Vastleggen De eerste timestamp waarbij het veld 'Eigenaar' is ingevuld met de naam van een agent na aanmaak of teamtoewijzing. Gebeurtenistype inferred
	Aanvraag toegewezen aan team	De serviceaanvraag is toegewezen aan een specifiek supportteam voor afhandeling. Dit wordt vastgelegd door het invullen of wijzigen van het veld 'OwnerTeam' in de Service Request record.
Het belang Deze event is cruciaal voor het analyseren van prestaties op teamniveau, werklastverdeling en overdrachtstijden tussen teams. Het helpt identificeren welke teams knelpunten vormen in het proces. Vindplaats Bijgehouden door wijzigingen in het veld 'OwnerTeam' binnen de audithistorie of het journaal van de Service Request. Vastleggen Een update-event van het 'OwnerTeam'-veld, dat doorgaans wordt gelogd in een audittrail. Gebeurtenistype explicit
	Service Request Gesloten	De serviceaanvraag is officieel afgesloten en er kunnen geen verdere acties worden ondernomen. Dit gebeurt vaak automatisch na een ingestelde periode in de status 'Afgehandeld', wat de definitieve afsluiting van de levenscyclus vertegenwoordigt.
Het belang Deze activiteit is het definitieve einde van het proces. De tijd tussen 'Afgehandeld' en 'Gesloten' kan vertragingen benadrukken bij bevestiging of geautomatiseerde systeemprocessen. Vindplaats Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Gesloten', samen met de bijbehorende timestamp. Vastleggen Het detecteren van de update van het 'Status'-veld naar 'Gesloten' uit de audithistorie. Gebeurtenistype inferred
	Serviceaanvraag opgelost	De serviceaanvraag wordt als afgehandeld beschouwd en de oplossing is aan de gebruiker geleverd. Dit is een belangrijke mijlpaal, vastgelegd door een statuswijziging naar 'Afgehandeld', wat vaak de SLA-klok stopt.
Het belang Dit is een kritiek eindpunt voor het meten van de oplostijd en SLA-naleving. De duur vanaf de aanmaak tot deze activiteit is een kern-KPI voor procesprestaties. Vindplaats Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Afgehandeld', samen met de bijbehorende timestamp. Vastleggen Het detecteren van de update van het 'Status'-veld naar 'Afgehandeld' uit de audithistorie. Gebeurtenistype inferred
	Serviceverzoek Aangemaakt	Deze activiteit markeert het begin van de levenscyclus van de serviceaanvraag wanneer een nieuwe aanvraag formeel wordt ingediend en geregistreerd in Ivanti. Deze event wordt vastgelegd wanneer een nieuwe record wordt aangemaakt in het Service Request business object, waarbij een unieke Service Request ID wordt gegenereerd.
Het belang Dit is de primaire start event voor het proces. Het analyseren van de tijd vanaf dit punt tot aan de afhandeling is fundamenteel voor het meten van de totale doorlooptijd en procesefficiëntie. Vindplaats Dit wordt vastgelegd vanuit de aanmaak-timestamp van de Service Request record (bijv. CreatedDateTime veld in het ServiceReq business object). Vastleggen De recordaanmaak event in de ServiceReq-tabel, geïdentificeerd door de creatie-timestamp. Gebeurtenistype explicit
	Aanvraag Goedgekeurd	De serviceaanvraag heeft alle benodigde goedkeuringen ontvangen en kan nu worden afgehandeld. Deze event wordt vastgelegd wanneer de goedkeurings-workflow succesvol wordt afgesloten, waardoor de status van de aanvraag verandert.
Het belang Deze activiteit markeert een belangrijke mijlpaal, die het einde van de goedkeuringsfase en de start van de afhandeling aangeeft. Het maakt het meten van de efficiëntie van het goedkeuringsproces zelf mogelijk. Vindplaats Afgeleid van een statuswijziging van 'Wachten op Goedkeuring' naar 'Goedgekeurd' of 'Vervuld'. Dit kan ook een expliciete event zijn die is gelogd in het FRS_Approval business object. Vastleggen Een wijziging in het 'Status'-veld van de Service Request-record van een goedkeuringsstatus naar een actieve status. Gebeurtenistype inferred
	Aanvraag ingediend voor goedkeuring	De serviceaanvraag is ingediend voor de benodigde goedkeuringen voordat deze kan worden afgehandeld. Dit wordt doorgaans afgeleid wanneer de aanvraagstatus verandert naar 'Ingediend' of 'In afwachting van goedkeuring', wat vaak een goedkeurings-workflow activeert.
Het belang Het volgen van deze activiteit helpt vertragingen te identificeren in de goedkeuringsfase. Lange wachttijden hier kunnen een significant knelpunt zijn, wat de algehele oplostijden en gebruikerstevredenheid beïnvloedt. Vindplaats Afgeleid van een statuswijziging op de Service Request-record, waarschijnlijk naar een status zoals 'Ingediend' of 'Wachten op Goedkeuring'. Dit kan ook worden verkregen uit de FRS_Approval of FRS_ApprovalVoteTracking business objects. Vastleggen Een wijziging in het 'Status'-veld van de Service Request-record naar een goedkeuring-in-afwachting status. Gebeurtenistype inferred
	Externe leverancier ingeschakeld	De afhandeling van de serviceaanvraag is overgedragen aan een externe leverancier of derde partij. Dit wordt doorgaans vastgelegd door een statuswijziging naar 'Wachtend op 3e Partij' of een vergelijkbare status.
Het belang Deze activiteit is essentieel voor het meten van leveranciersprestaties en de impact ervan op de totale doorlooptijd. Het maakt analyse van leveranciersgerelateerde vertragingen mogelijk en ondersteunt het 'Externe Leveranciersactiviteit Duur' dashboard. Vindplaats Afgeleid van een statuswijziging in de Service Request-record naar een status zoals 'Wachten op 3e Partij' of 'In Afwachting van Leverancier'. Vastleggen Het detecteren van een wijziging in het 'Status'-veld naar een aangewezen 'wachten op leverancier'-status. Gebeurtenistype inferred
	Informatie geleverd door gebruiker	De aanvrager heeft de benodigde informatie verstrekt, waardoor de agent het werk kan hervatten. Dit wordt vastgelegd wanneer de aanvraag vanuit een 'Wachtend op Klant'-status terugkeert naar een actieve status.
Het belang Deze event sluit de cirkel van informatieaanvragen. De tijd tussen het aanvragen en ontvangen van informatie is een kritiek onderdeel van procesvertragingen en herbewerkingslussen. Vindplaats Afgeleid wanneer het 'Status'-veld van de Service Request verandert van een 'Wachten op Klant'-status naar een actieve status, zoals 'Actief' of 'In Behandeling'. Vastleggen Het detecteren van een statuswijziging van een 'wachten op gebruiker'-status naar een actieve status. Gebeurtenistype inferred
	Informatie gevraagd van gebruiker	De toegewezen agent heeft meer informatie nodig van de aanvrager om verder te gaan met de afhandeling. Dit wordt vastgelegd wanneer de status van de aanvraag wordt bijgewerkt naar een status zoals 'Wachtend op Klant'.
Het belang Deze activiteit belicht vertragingen veroorzaakt door onvolledige initiële informatie. Het bijhouden van de frequentie en duur ervan is essentieel voor de Impactanalyse van Informatieaanvragen en het identificeren van gebieden voor procesverbetering. Vindplaats Afgeleid van een statuswijziging in de Service Request-record naar een status zoals 'Wachten op Klant' of 'In Afwachting'. Vastleggen Het detecteren van een wijziging in het 'Status'-veld naar een aangewezen 'wachten op gebruiker'-status. Gebeurtenistype inferred
	Prioriteit Gewijzigd	De prioriteit van de serviceaanvraag is bijgewerkt na de initiële aanmaak. Deze event wordt vastgelegd vanuit het audit log of de geschiedenis die veldniveauwijzigingen bijhoudt.
Het belang Het volgen van prioriteitswijzigingen is van vitaal belang voor het Overzicht Effectiviteit Prioritering. Het helpt te bepalen of escalaties correct worden beheerd en of de initiële prioritering accuraat is. Vindplaats Dit is een expliciete event vastgelegd uit de audithistorie van de Service Request record, die wijzigingen in het veld 'Prioriteit' registreert. Vastleggen Een update-event van het 'Prioriteit'-veld vastgelegd in de audittrail van het systeem. Gebeurtenistype explicit
	Service Request Uitgevoerd	Alle taken die nodig zijn om de serviceaanvraag te vervullen, zijn voltooid door de agent of het systeem. Dit wordt vastgelegd door een statuswijziging naar 'Vervuld', wat vaak voorafgaat aan de uiteindelijke 'Afgehandeld' status.
Het belang Deze mijlpaal markeert de voltooiing van het technische of procedurele werk. Het is een belangrijk punt voor het meten van de actieve afhandeltijd vóór de definitieve bevestiging en afsluiting. Vindplaats Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Vervuld'. Vastleggen Een wijziging in het 'Status'-veld naar 'Vervuld' gedetecteerd uit de historiek van de record. Gebeurtenistype inferred
	Serviceaanvraag geannuleerd	De serviceaanvraag is geannuleerd door de gebruiker of een agent voor de afhandeling. Dit is een alternatieve eindstatus, vastgelegd door een statuswijziging naar 'Geannuleerd' of 'Ingetrokken'.
Het belang Dit vertegenwoordigt een niet-standaard procesbeëindiging. Het analyseren waarom aanvragen worden geannuleerd, kan problemen aan het licht brengen met het aanvraagproces zelf of veranderende gebruikersbehoeften. Vindplaats Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Geannuleerd'. Vastleggen Het detecteren van de update van het 'Status'-veld naar 'Geannuleerd' uit de audithistorie. Gebeurtenistype inferred
	Serviceaanvraag Heropend	Een eerder afgehandelde serviceaanvraag is opnieuw geactiveerd omdat het probleem aanhoudt of de oplossing onvoldoende was. Dit wordt vastgelegd wanneer de status verschuift van 'Afgehandeld' terug naar een actieve status zoals 'Actief' of 'Toegewezen'.
Het belang Deze activiteit is een directe indicator van herbewerking en een slechte 'first-time resolution' kwaliteit. Het analyseren van heropenings-events helpt proceszwaktes te identificeren en de 'Service Request Herbewerkingspercentage' KPI te verbeteren. Vindplaats Afgeleid uit de audithistorie wanneer het 'Status'-veld verandert van 'Afgehandeld' of 'Gesloten' naar een actieve status. Vastleggen Een statuswijziging van een eindstatus ('Afgehandeld', 'Gesloten') naar een open status ('Actief', 'Toegewezen'). Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit Ivanti Service Manager krijgt

Stappen

Log in bij Ivanti Service Manager met een rol die leesrechten heeft voor Serviceaanvragen en hun audithistorie.
Navigeer naar de Service Request-werkruimte via het hoofdnavigatiepaneel.
Dit proces vereist twee afzonderlijke data-exports die extern gecombineerd zullen worden. De eerste legt de creatie-event en kernattributen vast, en de tweede legt de gedetailleerde wijzigingshistorie vast.
Eerste export (Creatie-events): Maak een nieuwe Opgeslagen Zoekopdracht aan op het ServiceReq business object. Stel een filter in voor CreatedDateTime om serviceaanvragen te selecteren die zijn aangemaakt binnen de gewenste analyseperiode, bijvoorbeeld de laatste zes maanden.
Configureer de kolommen voor de Creatie-zoekopdracht om RecId, ServiceReqNumber (voor ServiceRequestID), CreatedDateTime (voor EventTime), SvcReqTmplLink_Category (voor ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime en TargetDateTime (voor SLADeadline) op te nemen.
Voer de zoekopdracht uit en gebruik de exportfunctie van het raster, meestal een pictogram dat lijkt op een schijf of pijl, om de data naar een CSV-bestand te exporteren. Noem het ServiceRequests.csv.
Tweede export (Audithistorie-events): Maak een nieuwe Opgeslagen Zoekopdracht, dit keer op het FRS_data_audit_history business object, dat veldwijzigingen logt.
Filter deze zoekopdracht om alleen wijzigingen met betrekking tot Serviceaanvragen op te nemen. Voeg een filter toe waarbij ParentObjectType gelijk is aan 'ServiceReq'. Voeg ook een filter toe op AuditDate voor dezelfde analyseperiode die u eerder hebt gebruikt.
Configureer de kolommen voor de Audit-zoekopdracht om ParentLink_RecID (om terug te koppelen naar de serviceaanvraag), FieldName, OldValue, NewValue en AuditDate (voor EventTime) op te nemen. Exporteer deze data naar een tweede CSV-bestand met de naam AuditHistory.csv.
Datatransformatie en -combinatie: De geëxporteerde CSV-bestanden moeten worden gecombineerd en omgevormd tot een enkele event log. Gebruik een data-voorbereidingstool zoals Power Query in Excel, Python of een databasetool om de volgende stappen uit te voeren:
- Laad zowel ServiceRequests.csv als AuditHistory.csv.
- Gebruik het ServiceRequests.csv-bestand om de 'Service Request Created'-event voor elke aanvraag te genereren.
- Gebruik het AuditHistory.csv-bestand om alle andere events te genereren. Wijs de waarden in de FieldName en NewValue kolommen toe aan de vereiste activiteitsnamen, bijvoorbeeld, als FieldName 'Status' is en NewValue 'Resolved', wordt de ActivityName 'Service Request Resolved'.
- Koppel de getransformeerde audit events terug aan de serviceaanvraagdata met behulp van ParentLink_RecID uit het auditbestand en RecId uit het serviceaanvraagbestand. Dit voegt de case-level attributen toe aan elk event.
- Combineer de 'Created'-events en de audit-afgeleide events in een enkele tabel.
Formatteer de uiteindelijke gecombineerde tabel met de vereiste kolomkoppen: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate en andere aanbevolen attributen. Zorg ervoor dat alle timestamps in een consistent formaat zijn.
Sla de uiteindelijke event log op als een enkel CSV-bestand, klaar voor upload.

Configuratie

Business Objects: Deze methode vereist exporteren vanuit twee afzonderlijke business objects: ServiceReq voor de belangrijkste aanvraagdata en FRS_data_audit_history voor de event data.
Datumbereikfilter: Het is cruciaal om een datumbereikfilter toe te passen op beide exports om het datavolume te beheren. Gebruik het CreatedDateTime-veld op ServiceReq en het AuditDate-veld op FRS_data_audit_history. Een periode van 3-6 maanden wordt aanbevolen voor een eerste analyse.
Belangrijkste filters voor audithistorie:
- ParentObjectType moet worden gefilterd op 'ServiceReq' om ervoor te zorgen dat u alleen wijzigingen extraheert die gerelateerd zijn aan serviceaanvragen.
- U kunt optioneel het FieldName filteren om alleen velden op te nemen die relevant zijn voor uw proces, zoals 'Status', 'Owner', 'OwnerTeam' en 'Priority', wat de exportgrootte aanzienlijk kan verminderen.
Vereisten: Een gebruikersaccount in Ivanti Service Manager met rechten om Opgeslagen Zoekopdrachten te maken en data te exporteren vanuit de ServiceReq en FRS_data_audit_history business objects is vereist.
Overwegingen met betrekking tot prestaties: De FRS_data_audit_history-tabel kan erg groot zijn. Het exporteren van data zonder een beperkend datumfilter kan prestatieproblemen veroorzaken voor de Ivanti-applicatie en kan resulteren in een timeout. Overweeg indien nodig data te exporteren in kleinere maandelijkse of kwartaalbatches.

a Voorbeeldquery 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;

Stappen

Vereisten en installatie: Zorg ervoor dat Python 3.6 of hoger op uw systeem is geïnstalleerd. Installeer de benodigde bibliotheken, requests voor API-aanroepen en pandas voor datamanipulatie, door pip install requests pandas uit te voeren. Verkrijg een API-sleutel van uw Ivanti Service Manager-beheerder met minimaal leesrechten voor de ServiceReq en FRS_Audit_ServiceReq business objects.
Configureer het script: Download het meegeleverde Python-script. Open het script in een teksteditor of IDE en werk de placeholder-variabelen bovenaan bij: TENANT_URL, API_KEY, START_DATE en END_DATE om overeen te komen met uw Ivanti-omgeving en gewenste extractieperiode.
Voer het script uit: Voer het script uit vanaf uw commandoregel met python your_script_name.py. Het script zal eerst een bericht afdrukken dat aangeeft dat het verbinding maakt en authenticeert met de Ivanti API.
Haal Service Request data op: Het script begint met het opvragen van het ServiceReq business object voor alle aanvragen die binnen het opgegeven datumbereik zijn gemaakt. Het script verwerkt automatisch API-paginering om de complete lijst met aanvragen op te halen, en toont voortgangsupdates terwijl het elke datapagina ophaalt.
Haal audithistorie op: Voor elke opgehaalde serviceaanvraag voert het script een secundaire query uit op het FRS_Audit_ServiceReq business object. Dit haalt de complete veldwijzigingshistorie voor die specifieke aanvraag op, wat essentieel is voor het opbouwen van de gedetailleerde event log.
Genereer 'Gemaakt'-event: Terwijl het script elke serviceaanvraag verwerkt, creëert het eerst het 'Service Request Created'-event. De timestamp voor dit event wordt rechtstreeks overgenomen uit het CreatedDateTime-veld van de servicerecord.
Genereer events uit audittrail: Het script doorloopt vervolgens de audittrailrecords voor elke serviceaanvraag. Het analyseert elke record om wijzigingen in belangrijke velden zoals Status, OwnerTeam, Owner en Priority te identificeren.
Wijs wijzigingen toe aan activiteiten: Een vooraf gedefinieerde mapping-logica binnen het script converteert deze veldwijzigingen naar specifieke activiteitsnamen. Een wijziging in het Status-veld van 'Active' naar 'Resolved' wordt bijvoorbeeld vastgelegd als een 'Service Request Resolved'-activiteit.
Stel de event log samen: Alle gegenereerde events, zowel de initiële aanmaak als de daaropvolgende wijzigingen uit de audittrail, worden samengesteld in een gestructureerde lijst. Elk event omvat de Service Request ID, activiteitsnaam, timestamp en andere relevante attributen.
Datatransformatie en -opmaak: De verzamelde lijst met events wordt geconverteerd naar een Pandas DataFrame. Het script zorgt ervoor dat alle kolommen overeenkomen met het vereiste schema voor ProcessMind, inclusief ServiceRequestID, ActivityName en EventTime.
Exporteren naar CSV: Zodra alle serviceaanvragen en hun historiek zijn verwerkt, slaat het script de uiteindelijke DataFrame op in een CSV-bestand met de naam ivanti_servicereq_event_log.csv in dezelfde map waar het script werd uitgevoerd. Dit bestand is klaar voor upload.

Configuratie

API Endpoint URL: De basis-URL voor de REST API van uw Ivanti Service Manager tenant. Deze moet worden ingesteld in de TENANT_URL-variabele in het script, bijvoorbeeld https://your-tenant.ivanti.com.
API Key: Een geldige REST API-sleutel gegenereerd binnen de Ivanti-beheerconsole. Deze sleutel moet gekoppeld zijn aan een rol die leesrechten heeft voor de ServiceReq en FRS_Audit_ServiceReq business objects.
Datumbereik: Het script vereist een START_DATE en END_DATE in 'JJJJ-MM-DD' formaat. Voor een eerste analyse wordt een datumbereik van 3 tot 6 maanden aanbevolen om een beheersbaar datavolume te waarborgen en tegelijkertijd voldoende procesvariaties vast te leggen.
Paginagrootte (TOP_COUNT): Deze variabele in het script definieert het aantal records dat per API-aanroep wordt opgehaald. De standaardwaarde is ingesteld op 500, wat een goede balans biedt tussen prestaties en geheugengebruik. U kunt dit aanpassen op basis van de prestaties van uw API-server.
Vereiste velden (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): Het script specificeert welke velden uit de API moeten worden opgehaald om de payloadgrootte te minimaliseren. Zorg ervoor dat alle velden die nodig zijn voor de vereiste en aanbevolen attributen in deze lijsten zijn opgenomen.

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

Uw Service Request Management Data Template

Uw Service Request Management Data Template

Service Request Management `Attributes`

Service Request Management Activiteiten

Extractie Guides

Ivanti Opgeslagen Zoekopdracht en Grid Data Export naar CSV

Stappen

Configuratie

a Voorbeeldquery config

Python Script via de Ivanti REST API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te starten?

Begin vandaag nog met het optimaliseren van uw Service Request Management

Uw Service Request Management Data Template

Uw Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activiteiten

Extractie Guides

Ivanti Opgeslagen Zoekopdracht en Grid Data Export naar CSV

Stappen

Configuratie

a Voorbeeldquery config

Python Script via de Ivanti REST API

Stappen

Configuratie

a Voorbeeldquery python

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Begin vandaag nog met het optimaliseren van uw Service Request Management

Service Request Management `Attributes`