> Continu verbeteren van processen > Beheer van serviceaanvragen > Ivanti Service Manager > Datatemplate

Datatemplate voor het beheer van serviceaanvragen

Ivanti Service Manager

Attributen voor het beheer van serviceaanvragen(21) Activiteiten voor het beheer van serviceaanvragen(14) Extractiegidsen(2)

Datatemplate voor het beheer van serviceaanvragen

Deze template laat zien welke data je nodig hebt om het beheer van serviceaanvragen met process mining te analyseren. Je vindt er de attributen die je verzamelt, de activiteiten die je bijhoudt en praktische uitleg over het ophalen van deze informatie uit je systeem. Gebruik deze bron om een event log voor je analyse samen te stellen.

Aanbevolen attributen voor een volledige analyse
Belangrijke activiteiten voor procesontdekking
Uitleg over data-extractie uit het bronsysteem

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor het beheer van serviceaanvragen

Dit zijn de aanbevolen datavelden voor je event log, zodat je het proces voor het beheer van serviceaanvragen volledig kunt analyseren.

5 Verplicht 9 Aanbevolen 7 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de gebeurtenis of taak die op een bepaald moment in de levenscyclus van de serviceaanvraag plaatsvond.
Beschrijving Dit attribuut beschrijft een specifieke stap of statuswijziging in het proces voor serviceaanvragen, zoals 'Aanvraag ter goedkeuring ingediend' of 'Serviceaanvraag opgelost'. Door de volgorde en frequentie van activiteiten te analyseren, krijg je inzicht in het procesverloop, vind je bottlenecks en ontdek je afwijkingen van de standaardprocedure. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart. Zo kun je het procesverloop visualiseren en analyseren, en herstelwerk, bottlenecks en afwijkingen opsporen. Waar vind je dit? Meestal afgeleid uit statuswijzigingen, journaalregels of beschrijvingen van gebeurtenissen in het auditlog van Ivanti Service Manager. Voorbeelden Serviceaanvraag aangemaaktAanvraag goedgekeurdServiceaanvraag opgelostServiceaanvraag gesloten
	Service Request-ID ServiceRequestID	De unieke identificatiecode van elke serviceaanvraag.
Beschrijving Het Service Request-ID identificeert elke afzonderlijke serviceaanvraag die door een gebruiker of systeem is ingediend. Het vormt de centrale koppeling tussen alle gebeurtenissen, van de eerste registratie tot de definitieve afsluiting. Zo kun je het volledige verloop van elke serviceaanvraag analyseren. Waarom dit belangrijk is Dit is de unieke case-ID die alle bijbehorende activiteiten aan één procesinstantie koppelt. Zo kun je het proces van begin tot eind analyseren. Waar vind je dit? Dit is de primaire sleutel van het businessobject Service Request. Je vindt deze vaak als ServiceReqNumber in de tabel ServiceReq. Voorbeelden SR-0012345SR-0012346SR-0012347
	Tijdstip van gebeurtenis EventTime	De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving Tijdstip van gebeurtenis, ook wel starttijd genoemd, is de exacte datum en tijd waarop een activiteit in het systeem is vastgelegd. Deze timestamp is nodig om gebeurtenissen in de juiste volgorde te zetten en vormt de basis voor alle tijdsanalyses in process mining, zoals het berekenen van doorlooptijden, wachttijden en de duur van activiteiten. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen chronologisch te ordenen en alle tijdsgebonden metrieken te berekenen. Die zijn belangrijk voor de prestatieanalyse. Waar vind je dit? Te vinden in auditlogs, journaalregels (bijvoorbeeld Journal.CreatedDateTime) of records met statuswijzigingen van de serviceaanvraag. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Bronsysteem SourceSystem	Het systeem waaruit de data is opgehaald.
Beschrijving Dit attribuut geeft aan waar de procesdata vandaan komt. In dit overzicht is de waarde altijd Ivanti Service Manager, omdat alle data daaruit afkomstig is. Dit is belangrijk wanneer data uit meerdere systemen wordt samengevoegd. Zo blijven de herkomst en context van de data duidelijk. Waarom dit belangrijk is Dit geeft belangrijke context over de herkomst van de data. Zo kun je analyses aan het juiste bronsysteem koppelen, vooral wanneer meerdere systemen worden gebruikt. Waar vind je dit? Dit is meestal een vaste waarde die tijdens het ophalen van de data 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 data-update vanuit het bronsysteem.
Beschrijving Dit attribuut geeft aan wanneer de data voor het laatst uit Ivanti Service Manager is opgehaald. Zo weet je hoe actueel de geanalyseerde data is, welke periode de analyse beslaat en wanneer je de volgende update kunt verwachten. Waarom dit belangrijk is Dit laat zien hoe actueel de data is. Dat is belangrijk om beslissingen te nemen op basis van de meest recente informatie over de procesprestaties. Waar vind je dit? Deze waarde wordt aangemaakt en aan de dataset toegevoegd wanneer de data wordt opgehaald. Voorbeelden 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Eindtijd van gebeurtenis EventEndTime	De timestamp die aangeeft wanneer een activiteit is afgerond.
Beschrijving De eindtijd van een gebeurtenis geeft aan wanneer een activiteit is afgerond. De tijd tussen de Event Time (start) en de eindtijd van de gebeurtenis is de verwerkingstijd van die activiteit. Zo zie je welke processtappen de meeste tijd kosten en waar ruimte is voor verbetering. Waarom dit belangrijk is Hiermee kun je de duur van afzonderlijke activiteiten berekenen. Dat is belangrijk om bottlenecks en langlopende taken in het proces te vinden. Waar vind je dit? Dit is mogelijk geen afzonderlijk veld. Vaak is het de starttijd van de volgende activiteit in dezelfde case. Voorbeelden 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Prioriteit Priority	De prioriteit die aan de serviceaanvraag is toegekend.
Beschrijving De prioriteit geeft aan hoe dringend een serviceaanvraag is, bijvoorbeeld 'Laag', 'Gemiddeld', 'Hoog' of 'Kritiek'. Met dit attribuut kun je beoordelen of aanvragen met een hoge prioriteit daadwerkelijk sneller worden afgehandeld. Vergelijk daarvoor de doorlooptijden en het behalen van SLA’s per prioriteitsniveau. Zo zie je of de prioriteitsregels werken zoals bedoeld. Waarom dit belangrijk is Hiermee beoordeel je of de prioritering werkt en of aanvragen met een hoge prioriteit sneller worden opgelost dan aanvragen met een lage prioriteit. Waar vind je dit? Een standaardveld op het Service Request-object, meestal met de naam 'Priority'. Voorbeelden 1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
	SLA-deadline SLADeadline	Het tijdstip waarop de serviceaanvraag naar verwachting is opgelost.
Beschrijving De SLA-deadline is de berekende datum en tijd waarop een serviceaanvraag moet zijn opgelost om aan de Service Level Agreement te voldoen. De deadline hangt meestal af van factoren zoals de prioriteit en het type aanvraag. Door de werkelijke oplostijd met deze deadline te vergelijken, meet je of de SLA is behaald. Waarom dit belangrijk is Dit is de norm waarmee je de werkelijke prestaties vergelijkt. Zo kun je berekenen hoe vaak SLA’s worden behaald en aanvragen vinden die risico lopen. Waar vind je dit? Dit is vaak een berekend veld in Ivanti, opgeslagen bij de Service Level Agreement of Offering, bijvoorbeeld in '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 opgelost.
Beschrijving Dit afgeleide attribuut geeft per serviceaanvraag aan of de SLA is 'Behaald' of 'Overschreden', op basis van de oplostijd en de SLA-deadline. Het vormt de basis voor het dashboard 'Prestaties bij het behalen van SLA’s' en de KPI 'Percentage behaalde Service Level Agreements'. De berekening vergelijkt voor elke case de ResolutionDateTime met de SLADeadline. Waarom dit belangrijk is Meet rechtstreeks of de dienstverlening aan de afspraken voldoet. Dat is belangrijk om de servicekwaliteit te beoordelen en het vertrouwen van gebruikers te behouden. Waar vind je dit? Berekend door 'ResolutionDateTime' te vergelijken met 'SLADeadline'. Als ResolutionDateTime <= SLADeadline, is de status 'Behaald'. Anders is de status 'Overschreden'. Voorbeelden BehaaldOverschreden
	Status van serviceaanvraag ServiceRequestStatus	De status van de serviceaanvraag op het moment van de gebeurtenis.
Beschrijving Dit attribuut legt de status van de serviceaanvraag vast, zoals 'Geregistreerd', 'In behandeling', 'In afwachting', 'Opgelost' of 'Gesloten'. Statuswijzigingen bepalen vaak de activiteiten in het proceslog. Door te analyseren hoelang aanvragen in elke status blijven, kun je bottlenecks vinden. Zo kan blijken dat aanvragen te lang de status 'In afwachting' hebben. Waarom dit belangrijk is Geeft op elk moment een beeld van de status van de aanvraag. Dat is nodig om de tijd in specifieke statussen te berekenen en stilstand in het proces te vinden. Waar vind je dit? Een standaardveld op het Service Request-object, meestal met de naam 'Status'. Voorbeelden GeregistreerdActiefWacht op klantAfgehandeldGesloten
	Tijdstip van oplossing ResolutionDateTime	De datum en tijd waarop de serviceaanvraag officieel is opgelost.
Beschrijving Dit attribuut op caseniveau legt het laatste tijdstip vast waarop de dienstverlening is geleverd of het probleem is opgelost, voordat de aanvraag formeel wordt gesloten. Dit tijdstip is het eindpunt voor het berekenen van de totale doorlooptijd van een serviceaanvraag. Het is belangrijk om de algehele procesefficiëntie en het behalen van SLA’s te meten. Waarom dit belangrijk is Bepaalt het eindpunt voor de berekening van de doorlooptijd van het kernproces. Dit is een belangrijke KPI voor de efficiëntie van de dienstverlening. Waar vind je dit? Een specifiek timestamp-veld op het Service Request-object, vaak met de naam 'ResolvedDateTime' of iets vergelijkbaars. Voorbeelden 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Toegewezen medewerker AssignedAgent	De gebruiker of medewerker die de serviceaanvraag behandelt.
Beschrijving De toegewezen medewerker is de persoon die verantwoordelijk is voor de serviceaanvraag. Met dit attribuut kun je op individueel niveau analyseren, bijvoorbeeld voor prestatiebeheer, een evenwichtige werkverdeling en het vinden van opleidingsbehoeften. Het bijhouden van overdrachten tussen medewerkers is belangrijk om KPI’s zoals 'Gemiddeld aantal her toewijzingen per aanvraag' te berekenen en inefficiënties in het proces te vinden. Waarom dit belangrijk is Hiermee kun je de werkdruk, prestaties en patronen in her toewijzingen per medewerker analyseren. Die kunnen wijzen op problemen met opleiding, vaardigheden of de eerste routering. Waar vind je dit? Meestal staat dit in een veld zoals 'Owner' op het Service Request-object. De waarde kan bij elke her toewijzing veranderen en moet daarom in het event log worden bijgehouden. Voorbeelden Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Toegewezen team AssignedTeam	Het supportteam of de groep die momenteel de serviceaanvraag behandelt.
Beschrijving Dit attribuut geeft aan welk team op een bepaald moment verantwoordelijk is voor de serviceaanvraag. Door overdrachten tussen teams, de tijd per team en het aantal behandelde aanvragen te analyseren, krijg je inzicht in de werkverdeling, bottlenecks en teamprestaties. Dit attribuut is ook relevant voor dashboards over het behalen van SLA’s en de werkdruk van medewerkers. Waarom dit belangrijk is Houdt bij wie verantwoordelijk is en wanneer aanvragen worden overgedragen. Zo kun je vertragingen tussen teams, de werkverdeling en bottlenecks in het proces analyseren. Waar vind je dit? Deze informatie staat meestal in een veld zoals 'OwnerTeam' op het Service Request-object of in gerelateerde toewijzingsrecords. Voorbeelden IT-servicedeskNetwerkbeheerHR-supportFacilitair beheer
	Type serviceaanvraag ServiceRequestType	De classificatie of categorie van de serviceaanvraag.
Beschrijving Dit attribuut deelt serviceaanvragen in categorieën in, zoals 'Hardwareaanvraag', 'Software-installatie' of 'Wachtwoord opnieuw instellen'. Het is een belangrijke dimensie voor analyses. Teams kunnen hiermee de procesprestaties, doorlooptijden en het behalen van SLA’s vergelijken voor verschillende soorten dienstverlening. Inzicht in die verschillen helpt om procesverbeteringen af te stemmen en middelen doelgerichter in te zetten. Waarom dit belangrijk is Door het proces op type aanvraag in te delen, kun je gericht analyseren of bepaalde aanvragen vaker vertraging oplopen, herstelwerk vragen of de SLA overschrijden. Waar vind je dit? Waarschijnlijk een veld op het bedrijfsobject Service Request, vaak met de naam 'Service' of 'Category'. Raadpleeg de documentatie van Ivanti Service Manager voor specifieke veldnamen, zoals 'SvcReqTmplLink_Category'. Voorbeelden Nieuwe hardwareaanvraagSoftwaretoegangAccount wijzigenInformatie opvragen
	Aantal heropeningen ReopenCount	Het aantal keren dat een opgeloste serviceaanvraag opnieuw is geopend.
Beschrijving Dit attribuut telt elke keer op dat een serviceaanvraag van de status 'Opgelost' of 'Gesloten' teruggaat naar 'Actief'. Een hoog aantal heropeningen wijst vaak op een slechte oplossing bij de eerste poging, een onvolledige oplossing of terugkerende problemen. Dit attribuut helpt bij het berekenen van de KPI 'Percentage herstelwerk bij serviceaanvragen'. Waarom dit belangrijk is Meet herstelwerk rechtstreeks en is een belangrijke indicator voor de kwaliteit van oplossingen. Een hoog aantal betekent vaak dat de eerste oplossing niet werkte. Waar vind je dit? Dit is meestal een teller op het Service Request-object die volgens een bedrijfsregel wordt verhoogd wanneer de status verandert. De veldnaam kan 'ReopenCounter' zijn. Voorbeelden 0123
	Aantal toewijzingen AssignmentCount	Het totale aantal keren dat een serviceaanvraag is toegewezen of opnieuw is toegewezen.
Beschrijving Deze berekende metriek telt per serviceaanvraag het aantal activiteiten rond toewijzingen, zoals 'Toegewezen aan team' en 'Toegewezen aan medewerker'. Veel her toewijzingen, ook wel 'ticket-pingpong' genoemd, wijzen op inefficiënte routering, het uitblijven van een oplossing bij het eerste contact of onduidelijke verantwoordelijkheden tussen teams. Dit attribuut is nodig voor de KPI 'Gemiddeld aantal her toewijzingen per aanvraag'. Waarom dit belangrijk is Meet inefficiënte overdrachten en routeringsproblemen. Een hoog aantal wijst vaak op langere oplostijden en frustratie bij gebruikers. Waar vind je dit? Berekend door tijdens de datavoorbereiding voor elke unieke ServiceRequestID het aantal toewijzingsactiviteiten te tellen. Voorbeelden 12345
	Afdeling van aanvrager RequestorDepartment	De afdeling van de gebruiker die de serviceaanvraag heeft ingediend.
Beschrijving Dit attribuut geeft aan van welke afdeling de medewerker of het systeem komt dat de serviceaanvraag heeft ingediend, bijvoorbeeld 'Verkoop', 'Financiën' of 'Personeelszaken'. Hiermee kun je de servicekwaliteit en de vraag naar dienstverlening in verschillende delen van de organisatie analyseren. Zo zie je of bepaalde afdelingen langer op een oplossing wachten of meer aanvragen indienen. Waarom dit belangrijk is Hiermee kun je het gebruik en de kwaliteit van de dienstverlening per bedrijfseenheid analyseren en afdelingsspecifieke problemen of trends vinden. Waar vind je dit? Deze informatie komt meestal uit het gebruikersprofiel van de aanvrager, dat aan de Service Request is gekoppeld. Het veld kan 'Department' heten in het object Profile.Employee. Voorbeelden FinanciënVerkoopMarketingInformatietechnologie
	Is herstelwerk IsRework	Een booleaanse vlag die aangeeft of er herstelwerk is uitgevoerd voor de serviceaanvraag.
Beschrijving Deze berekende vlag krijgt de waarde true als een serviceaanvraag tekenen van herstelwerk vertoont, bijvoorbeeld als de aanvraag na de oplossing opnieuw wordt geopend of bepaalde activiteiten in een lus worden herhaald. Dit vereenvoudigt de berekening van de KPI 'Percentage herstelwerk bij serviceaanvragen' en helpt inefficiënte procesgevallen te filteren in dashboards zoals 'Herstelwerk- en her toewijzingsstromen'. Waarom dit belangrijk is Helpt het aantal aanvragen te vinden en te meten waarvoor extra, ongepland werk nodig is. Zo komen problemen met kwaliteit en efficiëntie aan het licht. Waar vind je dit? Afgeleid uit de data. De berekening kan uitgaan van een waarde groter dan nul voor het attribuut 'ReopenCount' of specifieke activiteitspatronen herkennen, zoals meerdere gebeurtenissen 'Toegewezen aan medewerker'. Voorbeelden truefalse
	Kanaal Channel	De manier waarop of het kanaal waarlangs de serviceaanvraag is ingediend.
Beschrijving Het kanaal geeft aan hoe de serviceaanvraag is aangemaakt, bijvoorbeeld via het self-serviceportaal, per e-mail of telefoon, of automatisch door een ander systeem. Door het aantal aanvragen en de oplostijden per kanaal te analyseren, zie je welke kanalen het efficiëntst zijn en waar procesverbeteringen of gebruikerstraining nodig zijn. Waarom dit belangrijk is Geeft inzicht in gebruikersgedrag en de efficiëntie van kanalen. Dat helpt bij keuzes over de dienstverlening en mogelijkheden voor automatisering. Waar vind je dit? Dit staat vaak in een veld zoals 'Source' of 'CreatedBy' op het Service Request-object. Voorbeelden SelfserviceE-mailTelefoonHandmatig ingevoerd
	Naam leverancier VendorName	De naam van de externe leverancier die betrokken is bij het oplossen van de aanvraag.
Beschrijving Dit attribuut geeft aan welke externe leverancier is ingeschakeld om een serviceaanvraag te ondersteunen of af te handelen. Het is nodig voor het dashboard 'Duur van activiteiten bij externe leveranciers', waarmee je de prestaties van verschillende leveranciers kunt meten en vergelijken. Door dit bij te houden, kun je leveranciersrelaties beheren en bottlenecks door externe afhankelijkheden vinden. Waarom dit belangrijk is Hiermee kun je de prestaties van externe partijen en hun invloed op de totale oplostijd van serviceaanvragen analyseren. Dat ondersteunt het leveranciersbeheer. Waar vind je dit? Dit kan een veld zijn op een taakobject dat aan de serviceaanvraag is gekoppeld, of een specifiek veld op de Service Request zelf als er een leverancier is toegewezen. Voorbeelden Dell SupportOracle ConsultingMicrosoft Premiernull
	Oplossingscategorie ResolutionCategory	Een classificatie van de oplossing voor de serviceaanvraag.
Beschrijving Met de oplossingscategorie leg je op een vaste manier vast hoe een serviceaanvraag uiteindelijk is opgelost. Vaak is dit een hiërarchische indeling, bijvoorbeeld in categorieën en subcategorieën. Die helpt bij oorzaakanalyse en trendrapportages. Zo kunnen terugkerende problemen of veelvoorkomende afhandelingsacties aan het licht komen. Die informatie kun je gebruiken om de dienstverlening te verbeteren of kennisbankartikelen te maken. Waarom dit belangrijk is Geeft inzicht in de aard van oplossingen en helpt veelvoorkomende problemen, kansen om de dienstverlening te verbeteren en mogelijkheden voor automatisering te vinden. Waar vind je dit? Dit staat vaak in categorisatievelden die bij het oplossen worden ingevuld, zoals 'ResolutionCategory' of een aangepast veld voor de afsluitcode. Voorbeelden Gebruikerstraining nodigSoftware geïnstalleerdHardware gerepareerdToegang verleend

Verplicht Aanbevolen Optioneel

Activiteiten voor het beheer van serviceaanvragen

Leg deze essentiële processtappen en mijlpalen vast in je event log voor een nauwkeurige procesontdekking en analyse.

5 Aanbevolen 9 Optioneel

	Activiteit	Beschrijving
	Aanvraag aan medewerker toegewezen	Een specifieke medewerker neemt de serviceaanvraag in behandeling. Dit wordt meestal afgeleid uit het moment waarop het veld 'Owner', dat de medewerker aanduidt, voor het eerst wordt ingevuld of gewijzigd.
Waarom dit belangrijk is Dit markeert het einde van de eerste wachttijd of wachtrij. Door de tijd tot deze activiteit te meten, kun je problemen met de verdeling van middelen opsporen. De meting ondersteunt ook het dashboard voor de werklast van medewerkers. Waar vind je dit? Afgeleid uit het invullen of wijzigen van het veld 'Owner' in het Service Request-record, zoals te zien is in de auditgeschiedenis. Vastleggen De eerste timestamp waarop het veld 'Owner' na het aanmaken of toewijzen aan een team wordt ingevuld met de naam van een medewerker. Gebeurtenistype inferred
	Aanvraag aan team toegewezen	De serviceaanvraag wordt toegewezen aan een specifiek supportteam. Dit wordt vastgelegd wanneer het veld 'OwnerTeam' in het Service Request-record wordt ingevuld of gewijzigd.
Waarom dit belangrijk is Deze gebeurtenis helpt bij het analyseren van prestaties per team, de verdeling van de werklast en overdrachtstijden tussen teams. Zo zie je welke teams bottlenecks in het proces vormen. Waar vind je dit? Te volgen aan de hand van wijzigingen in het veld 'OwnerTeam' in de auditgeschiedenis of het journaal van de serviceaanvraag. Vastleggen Een wijziging van het veld 'OwnerTeam', die doorgaans wordt vastgelegd in een auditspoor. Gebeurtenistype explicit
	Serviceaanvraag aangemaakt	Deze activiteit markeert het begin van de levenscyclus van een serviceaanvraag. De aanvraag wordt ingediend en geregistreerd in Ivanti. Dit moment wordt vastgelegd wanneer een nieuw record wordt aangemaakt in het businessobject Service Request. Daarbij krijgt de aanvraag een uniek Service Request-ID.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het proces. De tijd tussen dit moment en de oplossing is essentieel om de totale doorlooptijd en procesefficiëntie te meten. Waar vind je dit? Dit wordt vastgelegd aan de hand van de aanmaaktimestamp van het Service Request-record, bijvoorbeeld het veld CreatedDateTime in het businessobject ServiceReq. Vastleggen De gebeurtenis waarbij een record wordt aangemaakt in de tabel ServiceReq, herkenbaar aan de aanmaaktimestamp. Gebeurtenistype explicit
	Serviceaanvraag gesloten	De serviceaanvraag is officieel gesloten en er zijn geen verdere acties mogelijk. Dit gebeurt vaak automatisch nadat de aanvraag een bepaalde tijd de status 'Resolved' heeft gehad. Daarmee is de levenscyclus afgerond.
Waarom dit belangrijk is Deze activiteit markeert het definitieve einde van het proces. De tijd tussen 'Resolved' en 'Closed' kan wijzen op vertraging bij de bevestiging of in geautomatiseerde systeemprocessen. Waar vind je dit? Afgeleid uit een wijziging van het veld 'Status' in het Service Request-record naar 'Closed', met de bijbehorende timestamp. Vastleggen Een wijziging van het veld 'Status' naar 'Closed', vastgesteld aan de hand van de auditgeschiedenis. Gebeurtenistype inferred
	Serviceaanvraag opgelost	De serviceaanvraag is opgelost en de oplossing is aan de gebruiker geleverd. Dit belangrijke moment wordt vastgelegd bij een statuswijziging naar 'Resolved'. Vaak stopt dan ook de SLA-klok.
Waarom dit belangrijk is Dit is het belangrijkste eindpunt voor het meten van de oplostijd en naleving van de SLA. De tijd tussen het aanmaken en deze activiteit is een belangrijke KPI voor de procesprestaties. Waar vind je dit? Afgeleid uit een wijziging van het veld 'Status' in het Service Request-record naar 'Resolved', met de bijbehorende timestamp. Vastleggen Een wijziging van het veld 'Status' naar 'Resolved', vastgesteld aan de hand van de auditgeschiedenis. Gebeurtenistype inferred
	Aanvraag goedgekeurd	De serviceaanvraag heeft alle benodigde goedkeuringen gekregen en kan worden afgehandeld. Deze gebeurtenis wordt vastgelegd wanneer de goedkeuringsworkflow succesvol is afgerond en de status van de aanvraag verandert.
Waarom dit belangrijk is Deze activiteit markeert een belangrijk moment: de goedkeuringsfase is afgerond en de afhandeling kan beginnen. Zo kun je de efficiëntie van het goedkeuringsproces zelf meten. Waar vind je dit? Afgeleid uit een statuswijziging van 'Waiting for Approval' naar 'Approved' of 'Fulfilled'. De gebeurtenis kan ook expliciet zijn vastgelegd in het businessobject FRS_Approval. Vastleggen Een wijziging van het veld 'Status' in het Service Request-record van een goedkeuringsstatus naar een actieve status. Gebeurtenistype inferred
	Aanvraag ter goedkeuring ingediend	De serviceaanvraag is ingediend voor de benodigde goedkeuringen voordat deze kan worden afgehandeld. Dit wordt meestal afgeleid uit een statuswijziging naar 'Submitted' of 'Pending Approval', die vaak een goedkeuringsworkflow start.
Waarom dit belangrijk is Door deze activiteit te volgen, zie je waar vertraging ontstaat tijdens de goedkeuringsfase. Lange wachttijden kunnen een belangrijke bottleneck vormen en de totale oplostijd en gebruikerstevredenheid beïnvloeden. Waar vind je dit? Afgeleid uit een statuswijziging van het Service Request-record, waarschijnlijk naar 'Submitted' of 'Waiting for Approval'. De gegevens kunnen ook afkomstig zijn uit de businessobjecten FRS_Approval of FRS_ApprovalVoteTracking. Vastleggen Een wijziging van het veld 'Status' in het Service Request-record naar een status waarin goedkeuring wordt afgewacht. Gebeurtenistype inferred
	Externe leverancier ingeschakeld	De afhandeling van de serviceaanvraag is overgedragen aan een externe leverancier of derde partij. Dit wordt meestal vastgelegd bij een statuswijziging naar 'Waiting for 3rd Party' of een vergelijkbare status.
Waarom dit belangrijk is Deze activiteit is belangrijk om de prestaties van leveranciers en hun invloed op de totale doorlooptijd te meten. Je kunt vertragingen door leveranciers analyseren en het dashboard voor de duur van activiteiten van externe leveranciers gebruiken. Waar vind je dit? Afgeleid uit een statuswijziging van het Service Request-record naar bijvoorbeeld 'Waiting for 3rd Party' of 'Pending Vendor'. Vastleggen Een wijziging van het veld 'Status' naar een status waarin op een leverancier wordt gewacht. Gebeurtenistype inferred
	Informatie aangeleverd door gebruiker	De aanvrager heeft de benodigde informatie aangeleverd, zodat de medewerker verder kan. Dit wordt vastgelegd wanneer de aanvraag niet langer de status 'Waiting for Customer' heeft en weer een actieve status krijgt.
Waarom dit belangrijk is Met deze gebeurtenis is het informatieverzoek afgehandeld. De tijd tussen het opvragen en ontvangen van informatie draagt bij aan vertragingen en herstelwerk in het proces. Waar vind je dit? Afgeleid wanneer het veld 'Status' van het Service Request-record verandert van 'Waiting for Customer' naar een actieve status, zoals 'Active' of 'In Progress'. Vastleggen Een statuswijziging van een status waarin op informatie van de gebruiker wordt gewacht naar een actieve status. Gebeurtenistype inferred
	Informatie opgevraagd bij gebruiker	De toegewezen medewerker heeft meer informatie nodig van de aanvrager om verder te kunnen met de afhandeling. Dit wordt vastgelegd wanneer de status van de aanvraag verandert naar bijvoorbeeld 'Waiting for Customer'.
Waarom dit belangrijk is Deze activiteit laat zien welke vertragingen ontstaan doordat de aanvraag bij aanvang niet volledig is. Door de frequentie en duur te volgen, kun je de impact van informatieverzoeken analyseren en verbeterpunten vinden. Waar vind je dit? Afgeleid uit een statuswijziging van het Service Request-record naar bijvoorbeeld 'Waiting for Customer' of 'Pending'. Vastleggen Een wijziging van het veld 'Status' naar een status waarin op informatie van de gebruiker wordt gewacht. Gebeurtenistype inferred
	Prioriteit gewijzigd	De prioriteit van de serviceaanvraag is na het aanmaken gewijzigd. Deze gebeurtenis wordt vastgelegd in het auditlog of de geschiedenis waarin wijzigingen op veldniveau worden bijgehouden.
Waarom dit belangrijk is Door prioriteitswijzigingen te volgen, kun je beoordelen hoe goed prioriteiten worden gesteld. Je ziet of escalaties goed worden afgehandeld en of de prioriteit bij aanvang juist is bepaald. Waar vind je dit? Dit is een expliciete gebeurtenis uit de auditgeschiedenis van het Service Request-record, waarin wijzigingen van het veld 'Priority' worden vastgelegd. Vastleggen Een wijziging van het veld 'Priority', vastgelegd in het auditspoor van het systeem. Gebeurtenistype explicit
	Serviceaanvraag afgehandeld	De medewerker of het systeem heeft alle taken uitgevoerd die nodig zijn om de serviceaanvraag af te handelen. Dit wordt vastgelegd bij een statuswijziging naar 'Fulfilled', vaak gevolgd door de definitieve status 'Resolved'.
Waarom dit belangrijk is Dit moment markeert het einde van het technische of procedurele werk. Het is een belangrijk meetpunt voor de actieve behandeltijd vóór de definitieve bevestiging en afsluiting. Waar vind je dit? Afgeleid uit een wijziging van het veld 'Status' in het Service Request-record naar 'Fulfilled'. Vastleggen Een wijziging van het veld 'Status' naar 'Fulfilled', vastgesteld aan de hand van de geschiedenis van het record. Gebeurtenistype inferred
	Serviceaanvraag geannuleerd	De gebruiker of een medewerker heeft de serviceaanvraag geannuleerd voordat deze was opgelost. Dit is een alternatieve eindstatus, vastgelegd als een statuswijziging naar 'Cancelled' of 'Withdrawn'.
Waarom dit belangrijk is Dit is een afwijkende beëindiging van het proces. Door te analyseren waarom aanvragen worden geannuleerd, kun je problemen in het aanvraagproces of veranderende behoeften van gebruikers ontdekken. Waar vind je dit? Afgeleid uit een wijziging van het veld 'Status' in het Service Request-record naar 'Cancelled'. Vastleggen Een wijziging van het veld 'Status' naar 'Cancelled', vastgesteld aan de hand van de auditgeschiedenis. Gebeurtenistype inferred
	Serviceaanvraag heropend	Een eerder opgeloste serviceaanvraag is opnieuw actief gemaakt omdat het probleem nog bestaat of de oplossing niet voldeed. Dit wordt vastgelegd wanneer de status verandert van 'Resolved' naar een actieve status, zoals 'Active' of 'Assigned'.
Waarom dit belangrijk is Deze activiteit wijst direct op herstelwerk en een lage kans op een goede oplossing bij de eerste poging. Door heropeningen te analyseren, kun je zwakke plekken in het proces vinden en de KPI voor herstelwerk bij serviceaanvragen verbeteren. Waar vind je dit? Afgeleid uit de auditgeschiedenis wanneer het veld 'Status' verandert van 'Resolved' of 'Closed' naar een actieve status. Vastleggen Een statuswijziging van een eindstatus ('Resolved', 'Closed') naar een open status ('Active', 'Assigned'). Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Ivanti Service Manager

Stappen

Meld je aan bij Ivanti Service Manager met een rol die leestoegang heeft tot serviceaanvragen en hun auditgeschiedenis.
Open de werkruimte Service Request via het hoofdnavigatiemenu.
Voor dit proces zijn twee aparte data-exports nodig. Die voeg je buiten Ivanti samen. De eerste bevat de aanmaakgebeurtenis en de belangrijkste attributen. De tweede bevat de gedetailleerde wijzigingsgeschiedenis.
Eerste export (aanmaakgebeurtenissen): Maak een nieuwe Saved Search op het business object ServiceReq. Stel een filter in op CreatedDateTime om serviceaanvragen te selecteren die binnen de gewenste analyseperiode zijn aangemaakt, bijvoorbeeld in de afgelopen zes maanden.
Stel de kolommen voor de zoekopdracht naar aanmaakgebeurtenissen in op RecId, ServiceReqNumber (voor ServiceRequestID), CreatedDateTime (voor EventTime), SvcReqTmplLink_Category (voor ServiceRequestType), OwnerTeam, Eigenaar, Priority, Status, ResolutionDateTime en TargetDateTime (voor SLADeadline).
Voer de zoekopdracht uit en gebruik de exportfunctie van het grid, meestal herkenbaar aan een pictogram van een schijf of pijl, om de data naar een CSV-bestand te exporteren. Noem het bestand ServiceRequests.csv.
Tweede export (auditgeschiedenis): Maak een nieuwe Saved Search, dit keer op het business object FRS_data_audit_history, waarin veldwijzigingen worden vastgelegd.
Filter deze zoekopdracht zodat alleen wijzigingen voor serviceaanvragen worden meegenomen. Voeg een filter toe waarbij ParentObjectType gelijk is aan 'ServiceReq'. Filter ook op AuditDate voor dezelfde analyseperiode als bij de eerste export.
Stel de kolommen voor de zoekopdracht naar de auditgeschiedenis in op ParentLink_RecID (om te koppelen aan de serviceaanvraag), FieldName, OldValue, NewValue en AuditDate (voor EventTime). Exporteer de data naar een tweede CSV-bestand met de naam AuditHistory.csv.
Data omzetten en samenvoegen: Voeg de geëxporteerde CSV-bestanden samen en zet ze om naar één event log. Gebruik hiervoor bijvoorbeeld Power Query in Excel, Python of een databasetool:
- Laad zowel ServiceRequests.csv als AuditHistory.csv.
- Gebruik ServiceRequests.csv om voor elke aanvraag de gebeurtenis 'Serviceaanvraag aangemaakt' te maken.
- Gebruik AuditHistory.csv om alle overige gebeurtenissen te maken. Koppel de waarden in de kolommen FieldName en NewValue aan de vereiste activiteitsnamen. Als FieldName bijvoorbeeld 'Status' is en NewValue 'Resolved', wordt ActivityName 'Serviceaanvraag opgelost'.
- Koppel de omgezette auditgebeurtenissen weer aan de data van de serviceaanvragen. Gebruik daarvoor ParentLink_RecID uit het auditbestand en RecId uit het serviceaanvragenbestand. Zo voeg je de attributen op caseniveau toe aan elke gebeurtenis.
- Voeg de gebeurtenissen 'Aangemaakt' en de gebeurtenissen uit de auditgeschiedenis samen in één tabel.
Geef de samengevoegde tabel de vereiste kolomkoppen: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate en andere aanbevolen attributen. Zorg dat alle timestamps hetzelfde formaat hebben.
Sla het uiteindelijke event log op als één CSV-bestand. Dit bestand is klaar om te uploaden.

Configuratie

Business objects: Voor deze methode exporteer je data uit twee aparte business objects: ServiceReq voor de belangrijkste aanvraaggegevens en FRS_data_audit_history voor de gebeurtenisdata.
Filter op datumbereik: Pas op beide exports een filter op datumbereik toe om de hoeveelheid data beheersbaar te houden. Gebruik het veld CreatedDateTime in ServiceReq en het veld AuditDate in FRS_data_audit_history. Voor een eerste analyse raden we een periode van 3 tot 6 maanden aan.
Belangrijke filters voor de auditgeschiedenis:
- Filter ParentObjectType op 'ServiceReq', zodat je alleen wijzigingen voor serviceaanvragen ophaalt.
- Je kunt FieldName optioneel filteren op velden die relevant zijn voor je proces, zoals 'Status', 'Owner', 'OwnerTeam' en 'Priority'. Zo wordt het exportbestand een stuk kleiner.
Vereisten: Je hebt een gebruikersaccount in Ivanti Service Manager nodig met rechten om Saved Searches te maken en data te exporteren uit de business objects ServiceReq en FRS_data_audit_history.
Prestaties: De tabel FRS_data_audit_history kan erg groot zijn. Als je data exporteert zonder een strikt datumbereikfilter, kan dat de prestaties van Ivanti beïnvloeden en een time-out veroorzaken. Exporteer de data zo nodig in kleinere maandelijkse of driemaandelijkse delen.

Voorbeeldquery sql

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

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

UNION ALL

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

Stappen

Vereisten en installatie: Zorg dat Python 3.6 of hoger op je systeem is geïnstalleerd. Installeer de benodigde bibliotheken, requests voor API-aanroepen en pandas voor dataverwerking, met pip install requests pandas. Vraag de Ivanti Service Manager-beheerder om een API-sleutel met minimaal leestoegang tot de business objects ServiceReq en FRS_Audit_ServiceReq.
Het script instellen: Download het meegeleverde Python-script. Open het in een teksteditor of IDE en pas de placeholders bovenaan aan: TENANT_URL, API_KEY, START_DATE en END_DATE. Vul de gegevens van je Ivanti-omgeving en de gewenste extractieperiode in.
Het script uitvoeren: Voer het script uit vanaf de opdrachtregel met python your_script_name.py. Het script meldt eerst dat het verbinding maakt met de Ivanti API en zich aanmeldt.
Serviceaanvraagdata ophalen: Het script haalt uit het business object ServiceReq alle aanvragen op die binnen het opgegeven datumbereik zijn aangemaakt. Het verwerkt API-paginering automatisch, zodat de volledige lijst wordt opgehaald. Tijdens het ophalen van elke pagina toont het script de voortgang.
Auditgeschiedenis ophalen: Voor elke opgehaalde serviceaanvraag voert het script een tweede query uit op het business object FRS_Audit_ServiceReq. Zo wordt de volledige wijzigingsgeschiedenis van die aanvraag opgehaald, die nodig is om het gedetailleerde event log samen te stellen.
Gebeurtenis 'Aangemaakt' genereren: Tijdens de verwerking van elke serviceaanvraag maakt het script eerst de gebeurtenis 'Serviceaanvraag aangemaakt'. De timestamp komt rechtstreeks uit het veld CreatedDateTime van de aanvraag.
Gebeurtenissen uit het auditspoor genereren: Vervolgens doorloopt het script de auditrecords van elke serviceaanvraag. Het controleert daarin op wijzigingen in belangrijke velden, zoals Status, OwnerTeam, Eigenaar en Priority.
Wijzigingen aan activiteiten koppelen: Met vooraf ingestelde koppelregels zet het script veldwijzigingen om in specifieke activiteitsnamen. Een wijziging van 'Active' naar 'Resolved' in het veld Status wordt bijvoorbeeld vastgelegd als de activiteit 'Serviceaanvraag opgelost'.
Het event log samenstellen: Het script verzamelt alle gebeurtenissen in een gestructureerde lijst: de aanmaakgebeurtenis en de latere wijzigingen uit het auditspoor. Elke gebeurtenis bevat het ID van de serviceaanvraag, de activiteitsnaam, de timestamp en andere relevante attributen.
Data omzetten en formatteren: De lijst met gebeurtenissen wordt omgezet in een Pandas DataFrame. Het script zorgt dat alle kolommen overeenkomen met het vereiste schema voor ProcessMind, waaronder ServiceRequestID, ActivityName en EventTime.
Exporteren naar CSV: Nadat alle serviceaanvragen en hun geschiedenis zijn verwerkt, slaat het script de uiteindelijke DataFrame op in een CSV-bestand met de naam ivanti_servicereq_event_log.csv. Het bestand staat in dezelfde map als het script en is klaar om te uploaden.

Configuratie

URL van het API-eindpunt: De basis-URL van de REST API voor je Ivanti Service Manager-tenant. Vul deze in bij de variabele TENANT_URL in het script, bijvoorbeeld https://your-tenant.ivanti.com.
API-sleutel: Een geldige REST API-sleutel die je in de Ivanti-beheerconsole hebt aangemaakt. De sleutel moet gekoppeld zijn aan een rol met leestoegang tot de business objects ServiceReq en FRS_Audit_ServiceReq.
Datumbereik: Het script heeft een START_DATE en END_DATE nodig in de notatie 'YYYY-MM-DD'. Voor een eerste analyse raden we een periode van 3 tot 6 maanden aan. Zo blijft de hoeveelheid data beheersbaar en krijg je toch voldoende procesvarianten in beeld.
Paginagrootte (TOP_COUNT): Deze variabele bepaalt hoeveel records het script per API-aanroep ophaalt. De standaardwaarde is 500, een goede balans tussen prestaties en geheugengebruik. Pas de waarde zo nodig aan op basis van de prestaties van je API-server.
Vereiste velden (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): Het script haalt alleen de opgegeven velden uit de API op om de omvang van de gegevensoverdracht te beperken. Controleer of deze lijsten alle velden bevatten die nodig zijn voor de vereiste en aanbevolen attributen.

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

Klaar om aan de slag te gaan?

Met deze datatemplate krijg je een helder beeld van het beheer van serviceaanvragen. Begin vandaag met het optimaliseren van je bedrijfsvoering.

Terug naar de verbetergids

Template downloaden

Begin vandaag met het optimaliseren van het beheer van serviceaanvragen

Maak een einde aan trage afhandeling, verminder frustratie bij gebruikers en bereik een automatiseringspercentage van 70%.

Start je gratis proefperiode

Geen creditcard nodig. Je bent binnen enkele minuten aan de slag.

Datatemplate voor het beheer van serviceaanvragen

Datatemplate voor het beheer van serviceaanvragen

Attributen voor het beheer van serviceaanvragen

Activiteiten voor het beheer van serviceaanvragen

Extractiegidsen

Ivanti Saved Search en griddata exporteren naar CSV

Stappen

Configuratie

Voorbeeldquery sql

Python-script met de Ivanti REST API

Stappen

Configuratie

Voorbeeldquery python

Klaar om aan de slag te gaan?

Begin vandaag met het optimaliseren van het beheer van serviceaanvragen