> Continue verbetering > Beheer van serviceaanvragen > `BMC Helix ITSM` > datatemplate

Uw Service Request Management Data Template

BMC Helix ITSM

Service Request Management `Attributes` (21) Service Request Management Activiteiten (14) Extractie Guides (3)

Uw Service Request Management Data Template

Deze template biedt een duidelijk overzicht van de essentiële data-attributes om te verzamelen en de belangrijkste activiteiten om te volgen voor uw service request management proces. Het bevat ook praktische richtlijnen voor het efficiënt extraheren van deze data uit BMC Helix ITSM. Gebruik deze bron om uw data-voorbereiding te stroomlijnen en uw Process Mining initiatieven met vertrouwen te starten.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen
Extractiehandleiding voor BMC Helix ITSM

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

Template downloaden

Service Request Management `Attributes`

Deze data-velden zijn essentieel voor het creëren van een uitgebreide event log, wat een diepgaande analyse van uw service request management proces mogelijk maakt.

5 Verplicht 6 Aanbevolen 10 Optioneel

	Naam	Omschrijving
	Activiteit ActivityName	De naam van de specifieke `event` of `task` die op een bepaald tijdstip binnen de levenscyclus van de serviceaanvraag plaatsvond.
Omschrijving Dit attribuut beschrijft een specifieke stap of statuswijziging in het serviceaanvraagproces, zoals 'Aanvraag ter beoordeling', 'Afhandeling in uitvoering' of 'Serviceaanvraag opgelost'. Elke activiteit vertegenwoordigt één event in het end-to-end traject van een serviceaanvraag. Het analyseren van de sequentie en frequentie van activiteiten is de kern van Process Mining. Het maakt de ontdekking van proceskaarten, identificatie van bottlenecks en analyse van procesvarianten mogelijk. Begrijpen welke activiteiten plaatsvinden, in welke volgorde en hoe vaak, is cruciaal voor procesoptimalisatie. Het belang Activiteiten vormen de bouwstenen van de proceskaart. Het bijhouden ervan maakt de visualisatie en analyse van de processtroom mogelijk, en onthult hoe werk daadwerkelijk wordt uitgevoerd. Vindplaats Dit wordt doorgaans afgeleid uit wijzigingen in de velden 'Status' en 'Status Reason' op het 'SRM:Request' formulier of gerelateerde fulfillment applicatie logs (bijv. Incident, Work Order). Voorbeelden Aanvraag wacht op goedkeuringUitvoering bezigServiceaanvraag opgelostService Request Gesloten
	Serviceverzoek ID ServiceRequestId	De unieke identifier voor elke serviceaanvraag, dienend als primaire sleutel voor het volgen van de gehele lifecycle.
Omschrijving De Service Request ID identificeert uniek elke individuele serviceaanvraag die door een gebruiker of systeem is ingediend. Het dient als de centrale draad die alle volgende events met elkaar verbindt, van de initiële logging tot de uiteindelijke sluiting, wat een complete, end-to-end analyse van het traject van elke serviceaanvraag mogelijk maakt. Bij Process Mining is deze ID essentieel voor het reconstrueren van de sequentie van activiteiten voor elke case. Het stelt de tool in staat om alle gerelateerde events, zoals 'Aanvraag ingediend', 'Aanvraag toegewezen' en 'Serviceaanvraag gesloten', te groeperen in één procesinstantie, wat de basis vormt voor alle procesanalyse. Het belang Dit is de fundamentele case identifier. Zonder deze is het onmogelijk om het end-to-end traject van een serviceaanvraag te traceren, waardoor procesontdekking en -analyse onmogelijk worden. Vindplaats Dit is doorgaans het veld 'InstanceId' of 'Request Number' in het 'SRM:Request' formulier in BMC Helix ITSM. Voorbeelden SR000010572931SR000010572932SR000010572933
	Starttijd EventStartTime	De timestamp die aangeeft wanneer een specifieke activiteit of event is begonnen.
Omschrijving Dit attribuut registreert de exacte datum en tijd waarop een activiteit is gestart. Elke event in de log, van de initiële indiening tot de uiteindelijke sluiting, moet een starttijd hebben om de chronologische sequentie van het proces vast te stellen. Deze timestamp is cruciaal voor alle tijdgebaseerde Process Mining analyse. Het wordt gebruikt om cyclustijden, de duur van activiteiten, wachttijden tussen stappen en de SLA compliance te controleren. Het maakt de ontdekking van bottlenecks en de analyse van procesprestaties over tijd mogelijk. Het belang De starttijd biedt de chronologische volgorde van events, wat essentieel is voor het berekenen van procesduren, het identificeren van vertragingen en het begrijpen van de procestijdlijn. Vindplaats Dit komt overeen met de timestamp-velden in de audit logs of statusgeschiedenistabellen die gekoppeld zijn aan het 'SRM:Request' formulier, zoals 'Submit Date' voor de initiële event. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Bronsysteem SourceSystem	Identificeert het systeem waaruit de `data` is geëxtraheerd.
Omschrijving Dit attribuut specificeert de oorsprong van de proces data. Voor deze weergave zou het statisch ingesteld zijn op 'BMC Helix ITSM' om aan te geven dat alle events met betrekking tot de serviceaanvragen afkomstig waren van dit systeem. In omgevingen met meerdere geïntegreerde systemen is dit veld cruciaal voor het begrijpen van data lineage en het partitioneren van data op basis van de bron. Het zorgt voor duidelijkheid en traceerbaarheid, vooral bij het samenvoegen van data van verschillende platforms. Het belang Het biedt context over de data-oorsprong, wat belangrijk is voor data governance, traceerbaarheid en probleemoplossing in multi-systeemomgevingen. Vindplaats Dit is een statische waarde die is toegevoegd tijdens het data-extractie- en transformatieproces, geen veld binnen BMC Helix ITSM zelf. Voorbeelden `BMC Helix ITSM`
	Laatste data-update LastDataUpdate	De timestamp waarop de data voor dit proces voor het laatst is ververst vanuit het bronsysteem.
Omschrijving Dit attribuut geeft de datum en tijd aan van de meest recente data-extractie uit BMC Helix ITSM. Het biedt gebruikers context over de versheid van de data die zij analyseren, zodat zij op de hoogte zijn van de periode die door de analyse wordt gedekt. Dit is een kritisch metadata-attribuut voor elk Process Mining dashboard of analyse. Het stelt gebruikers in staat te begrijpen of de inzichten gebaseerd zijn op bijna real-time data of een historische snapshot, wat de geldigheid en relevantie van de getrokken conclusies beïnvloedt. Het belang Het informeert gebruikers over de actualiteit van de data, wat essentieel is voor het nemen van beslissingen op basis van de meest actuele beschikbare procesprestatie-informatie. Vindplaats Deze timestamp wordt gegenereerd en toegevoegd tijdens het data-extractie- en laadproces. Voorbeelden 2024-05-21T08:00:00Z
	Eindtijd EventEndTime	De timestamp waarop een specifieke activiteit of een event is afgerond.
Omschrijving De End Time markeert de voltooiing van een activiteit. Hoewel veel activiteiten in ITSM-systemen directe statuswijzigingen zijn, hebben sommige een meetbare duur. Een End Time maakt een nauwkeurige berekening van de duur van dergelijke activiteiten mogelijk. In analyses wordt de End Time gebruikt in combinatie met de Start Time om de verwerkingstijd voor individuele activiteiten te berekenen. Dit helpt te pinpointen welke specifieke taken, en niet alleen de wachttijd ertussen, de meeste tijd in het proces in beslag nemen. Het belang Het maakt de berekening van activiteitsverwerkingstijden mogelijk, wat cruciaal is voor het identificeren van inefficiënte stappen en het begrijpen waar resources hun tijd aan besteden. Vindplaats Dit kan worden afgeleid. De End Time van de ene activiteit is vaak de Start Time van de volgende sequentiële activiteit voor dezelfde case. Voor de laatste activiteit zou het de afhandelings- of gesloten timestamp zijn. Voorbeelden 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Prioriteit Priority	Het prioriteitsniveau dat aan de serviceaanvraag is toegekend, wat de bedrijfsimpact en urgentie aangeeft.
Omschrijving Prioriteit bepaalt de volgorde en snelheid waarmee aanvragen moeten worden afgehandeld. Gangbare waarden zijn onder meer 'Kritiek', 'Hoog', 'Medium' en 'Laag'. Deze toewijzing is vaak gebaseerd op een combinatie van de impact van de aanvraag op het bedrijf en de urgentie ervan. Analyseren op prioriteit is essentieel om te evalueren of aanvragen met hoge prioriteit sneller worden verwerkt dan die met lage prioriteit. Het is een belangrijke dimensie in dashboards voor oplostijd en SLA-compliance, en helpt ervoor te zorgen dat resources adequaat worden toegewezen aan de meest kritieke bedrijfsbehoeften. Het belang Het helpt te beoordelen of het proces werk correct prioriteert en voldoet aan de verwachte serviceniveaus voor aanvragen met verschillende niveaus van zakelijke impact. Vindplaats Dit is het 'Priority'-veld op het 'SRM:Request'-formulier. Voorbeelden KritiekHoogGemiddeldLaag
	Servicetype ServiceType	De categorie of het type service dat door de gebruiker wordt aangevraagd.
Omschrijving Het Service Type classificeert de aard van de aanvraag, bijvoorbeeld 'Nieuwe software aanvragen', 'Wachtwoord resetten' of 'Nieuwe medewerker onboarden'. Het is een fundamentele dimensie voor het filteren en segmenteren van de proces data. In procesanalyse wordt dit attribuut gebruikt om de prestaties van verschillende typen aanvragen te vergelijken. Het helpt vragen te beantwoorden als: 'Welke servicetypen duren het langst om op te lossen?' of 'Welke servicetypen hebben het meeste herwerk?'. Dit is cruciaal voor de Resolution Time en SLA Compliance dashboards. Het belang Het maakt de segmentatie van serviceaanvragen mogelijk om processtromen te vergelijken, typespecifieke problemen te identificeren en optimalisatie-inspanningen effectief aan te passen. Vindplaats Deze data wordt vaak gevonden in het veld 'Title' of een categorisatieveld op het 'SRM:Request' formulier, afgeleid van de geselecteerde service in de catalogus. Voorbeelden Nieuwe hardwareaanvraagAanvraag softwaretoegangVPN-toegang instellen
	Toegewezen agent AssignedAgent	De individuele gebruiker die momenteel is toegewezen om aan de serviceaanvraag te werken.
Omschrijving Dit attribuut identificeert de specifieke IT agent of supportmedewerker die op een bepaald moment verantwoordelijk is voor de aanvraag. Wijzigingen in dit veld gedurende de lifecycle van een enkele aanvraag duiden op een handoff of her-toewijzing. Dit attribuut is cruciaal voor agent-prestatie- en workloadanalyse. Het maakt het mogelijk om bij te houden hoeveel aanvragen elke agent afhandelt, hun gemiddelde afhandeltijd en de frequentie van her-toewijzingen. Deze data ondersteunt resource management en de identificatie van trainingsmogelijkheden. Het belang Het volgen van de toegewezen agent is essentieel voor het analyseren van handoffs, het meten van individuele prestaties en het begrijpen van de workloadverdeling binnen het supportteam. Vindplaats Dit komt overeen met het 'Assignee' of 'Assigned To' veld op het fulfillment record (bijv. Work Order, Incident) dat gekoppeld is aan de serviceaanvraag. Voorbeelden Bob SmithAlice JohnsonCharlie Brown
	Toegewezen Team AssignedTeam	De supportgroep of het team dat momenteel aan de serviceaanvraag is toegewezen.
Omschrijving Dit attribuut identificeert de functionele groep die verantwoordelijk is voor de afhandeling van de aanvraag, zoals 'Help Desk', 'Netwerkteam' of 'Databasebeheer'. Een wijziging in dit veld duidt op een overdracht van verantwoordelijkheid tussen teams. Analyse op basis van het toegewezen team helpt bij het identificeren van bottlenecks op teamniveau, het analyseren van inter-team handoffs en het evalueren van de efficiëntie van verschillende supportgroepen. Het is essentieel voor de Request Rework and Reassignment en Triage Efficiency dashboards, en onthult patronen in hoe werk door de organisatie wordt gerouteerd. Het belang Het maakt analyse van de processtroom tussen verschillende functionele groepen mogelijk, wat helpt bij het identificeren van routing-inefficiënties en het meten van teamniveauprestaties. Vindplaats Dit komt overeen met het 'Assigned Group' veld op het fulfillment record (bijv. Work Order, Incident) dat gekoppeld is aan de serviceaanvraag. Voorbeelden `Service Desk`Infrastructuur SupportApplication Support Tier 2
	Verzoekstatus RequestStatus	De status van de serviceaanvraag op het moment van de event, zoals 'In behandeling', 'In afwachting' of 'Gesloten'.
Omschrijving Dit attribuut legt de status van de serviceaanvraag vast op verschillende punten in de lifecycle. De status biedt context voor elke activiteit en is vaak de bron waaruit het 'Activiteit' attribuut zelf wordt afgeleid. Analyseren op status helpt te begrijpen hoeveel tijd aanvragen doorbrengen in bepaalde statussen, zoals 'Wacht op klant' of 'Wacht op goedkeuring'. Dit is essentieel voor het identificeren van bottlenecks en vertragingen veroorzaakt door externe afhankelijkheden of interne wachtrijen. Het ondersteunt direct het Bottleneck Identification dashboard. Het belang Het biedt een momentopname van de status van de aanvraag, waardoor analyse mogelijk is van de tijd besteed in wachtende versus actieve statussen, wat cruciaal is voor het identificeren van knelpunten. Vindplaats Dit is het 'Status'-veld op het 'SRM:Request'-formulier. Historische waarden zijn te vinden in de audit log. Voorbeelden PlanningIn uitvoeringPendingResolvedGesloten
	`Aantal handoffs` HandoffCount	Het totale aantal keren dat een serviceaanvraag opnieuw is toegewezen tussen verschillende agents of teams.
Omschrijving Deze berekende metric telt het aantal keren dat de 'AssignedAgent' of 'AssignedTeam' verandert voor een enkele serviceaanvraag. Een hoge handoff count kan duiden op procesfragmentatie, gebrek aan first-call resolution of inefficiënte routing. Dit attribuut is de basis voor de Average Agent Handoffs per Request KPI en wordt gebruikt in het Request Rework and Reassignment dashboard. Het analyseren van cases met hoge handoff counts kan mogelijkheden onthullen om triage te verbeteren, betere training te bieden of het afhandelingsproces te stroomlijnen om vertragingen te verminderen en klanttevredenheid te verbeteren. Het belang Het meet procesfragmentatie en communicatieoverhead. Hoge aantallen overdrachten zijn vaak gecorreleerd met langere oplostijden en lagere procesefficiëntie. Vindplaats Dit is een berekende metric, afgeleid door het tellen van het aantal distincte waarden in het 'AssignedAgent' of 'AssignedTeam' attribuut voor elke unieke Service Request ID. Voorbeelden 0135
	Afdeling van aanvrager RequestorDepartment	De afdeling of eenheid van de gebruiker die de aanvraag heeft ingediend.
Omschrijving Dit attribuut identificeert de organisatorische afdeling van de persoon die de service aanvraagt, zoals 'Financiën', 'Human Resources' of 'IT'. Deze informatie wordt doorgaans verkregen uit het gebruikersprofiel in het systeem. Het segmenteren van de procesanalyse per afdeling maakt het mogelijk om afdelingsspecifieke behoeften, aanvraagpatronen en potentiële gebieden voor gerichte training of serviceverbeteringen te identificeren. Het kan helpen vragen te beantwoorden als: 'Ervaart de afdeling Financiën langere wachttijden voor hun aanvragen?'. Het belang Het maakt analyse van serviceverbruik en procesprestaties per bedrijfseenheid mogelijk, wat afdelingspecifieke problemen of trends kan benadrukken. Vindplaats Deze informatie wordt doorgaans opgehaald uit het gebruikersprofiel dat gekoppeld is aan de 'Requested For'-gebruiker op het 'SRM:Request' formulier. Voorbeelden FinanciënVerkoopPersoneelszakenInformatietechnologie
	Afsluitcode CloseCode	Een code die de uiteindelijke uitkomst of reden voor het afsluiten van de serviceaanvraag aangeeft.
Omschrijving De Close Code biedt een gestandaardiseerde manier om de afhandeling van een serviceaanvraag te classificeren. Voorbeelden zijn 'Opgelost door Service Desk', 'Geannuleerd door gebruiker' of 'Dubbele aanvraag'. Het analyseren van close codes helpt bij het begrijpen van de meest voorkomende uitkomsten van aanvragen. Het kan problemen aan het licht brengen, zoals een hoog aantal door gebruikers geannuleerde aanvragen, wat kan duiden op een langdurig proces, of veel duplicaten, wat kan wijzen op een systeem- of communicatieprobleem. Dit attribuut ondersteunt het Resolution Category Accuracy dashboard. Het belang Het biedt gestructureerde data over aanvraagresultaten, waardoor analyse van de effectiviteit van de oplossing en redenen voor niet-voltooiing of annulering mogelijk is. Vindplaats Deze informatie wordt doorgaans gevonden in een 'Resolution' of 'Closure Code' veld op de fulfillment ticket die gekoppeld is aan de serviceaanvraag. Voorbeelden SuccesvolGeannuleerd door gebruikerNiet langer vereistGeautomatiseerde oplossing
	Doorlooptijd CycleTime	De totale verstreken tijd vanaf de creatie van de serviceaanvraag tot de uiteindelijke afhandeling.
Omschrijving Doorlooptijd, ook bekend als end-to-end duur, meet de totale levensduur van een serviceaanvraag. Het wordt berekend als het verschil tussen de timestamp van de eerste event (bijv. 'Service Request Submitted') en de laatste oplossingsevent (bijv. 'Service Request Resolved'). Dit is een van de meest fundamentele KPI's in process mining, en ondersteunt direct het Service Request Oplostijd dashboard. Het analyseren van de gemiddelde doorlooptijd, en het opsplitsen hiervan op basis van dimensies zoals servicetype of prioriteit, onthult de algehele efficiëntie van het proces en belicht gebieden die te lang duren. Het belang Dit is een primaire maatstaf voor procesefficiëntie. Het begrijpen en reduceren van de cyclustijd is vaak een belangrijk doel van procesverbeteringsinitiatieven. Vindplaats Dit is een berekende metric. Het wordt afgeleid door de 'Submit Date' af te trekken van de 'Closed Date' of 'Resolved Date' voor elke unieke Service Request ID. Voorbeelden 2 dagen 4 uur8 uur 30 minuten15 dagen
	Indieningskanaal SubmissionChannel	De methode of het kanaal waarmee de serviceaanvraag is ingediend.
Omschrijving Dit attribuut registreert hoe de serviceaanvraag is geïnitieerd, bijvoorbeeld via een self-service portal, e-mail, telefoongesprek met de servicedesk, of een geautomatiseerde systeemalert. Verschillende kanalen kunnen leiden tot verschillende procesvarianten en afhandeltijden. Het analyseren van het proces per indieningskanaal kan inefficiënties of best practices onthullen die geassocieerd zijn met specifieke intake methoden. Aanvragen ingediend via de self-service portal kunnen bijvoorbeeld sneller worden afgehandeld vanwege betere initiële data-kwaliteit, terwijl die van e-mail meer handmatige triage kunnen vereisen. Het belang Het helpt te begrijpen hoe de intake-methode de procesefficiëntie, datakwaliteit en de algehele doorlooptijd beïnvloedt, wat gerichte verbeteringen in specifieke kanalen mogelijk maakt. Vindplaats Dit kan vaak worden afgeleid uit velden zoals 'Client Type' of 'Reported Source' op het 'SRM:Request' formulier of bijbehorende fulfillment tickets. Voorbeelden SelfserviceportaalE-mailTelefoonSysteem gegenereerd
	Is `SLA` Geschonden IsSlaBreached	Een boolean-flag die aangeeft of de serviceaanvraag na de SLA-doeldatum is opgelost.
Omschrijving Deze berekende flag wordt op 'true' ingesteld als de timestamp van de uiteindelijke afhandeling van de serviceaanvraag later is dan de 'SLA Target Date'. Het biedt een eenvoudig, binair resultaat voor SLA-prestaties per aanvraag. Dit attribuut is essentieel voor het SLA Compliance Overview dashboard en de SLA Adherence Rate KPI. Het maakt eenvoudige aggregatie mogelijk om de algehele compliance rates te berekenen en maakt filtering mogelijk om de proceskenmerken van geschonden aanvragen versus compliant aanvragen te analyseren, wat helpt bij het identificeren van hoofdoorzaken van SLA-fouten. Het belang Het vereenvoudigt de SLA-prestatieanalyse door een timestamp-vergelijking om te zetten in een eenvoudige boolean-flag, waardoor het gemakkelijk wordt om nalevingspercentages te meten en te visualiseren. Vindplaats Dit is een berekend veld. De logica is: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Voorbeelden truefalse
	Is Geëscaleerd IsEscalated	Een boolean-flag die aangeeft of de serviceaanvraag is geëscaleerd.
Omschrijving Deze flag wordt op 'true' ingesteld als een serviceaanvraag een functionele of hiërarchische escalatie heeft ondergaan. Een escalatie vindt doorgaans plaats wanneer een aanvraag niet vordert zoals verwacht, bijna een SLA schendt, of hogere autoriteit vereist voor goedkeuring of actie. Dit attribuut is essentieel voor het Request Escalation Efficiency Analysis dashboard. Het maakt filtering en analyse van de procespaden van geëscaleerde aanvragen mogelijk om te begrijpen wat deze triggert, hoe lang ze duren om na escalatie op te lossen, en hoe effectief het escalatieproces is. Het belang Het maakt het mogelijk om de subset van aanvragen die escalatie vereisten te isoleren en te analyseren, wat helpt bij het identificeren van zwakke punten in het standaardproces of triggers voor complexe problemen. Vindplaats Dit is doorgaans geen enkel veld. Het wordt afgeleid door te controleren op specifieke escalatie-gerelateerde activiteiten in de audit log of wijzigingen in prioriteit of toewijzing die een escalatieprotocol volgen. Voorbeelden truefalse
	Is herstelwerk IsRework	Een boolean-flag die aangeeft of een serviceaanvraag is herwerkt, zoals het teruggaan naar een vorige fase.
Omschrijving Deze flag identificeert serviceaanvragen die een loop of herwerk hebben ondergaan in hun procesflow. Bijvoorbeeld, een aanvraag die van 'Afhandeling in uitvoering' teruggaat naar 'Aanvraag ter beoordeling' zou als herwerk worden beschouwd. De exacte definitie hangt af van de business proceslogica. Dit attribuut ondersteunt direct het Request Rework and Reassignment Analysis dashboard en de Request Rework Rate KPI. Het maakt kwantificering van de frequentie van herwerk en analyse van de veelvoorkomende oorzaken mogelijk, zoals incorrecte initiële beoordeling of onvolledige informatie, wat leidt tot procesinefficiënties. Het belang Het kwantificeert procesinefficiëntie door cases te markeren die afwijken van het 'ideale pad', en helpt zo de hoofdoorzaken van lussen en herhaald werk te identificeren. Vindplaats Dit is een berekend attribuut, afgeleid van de sequentie van activiteiten in de event log. Logica is nodig om achterwaartse bewegingen in de procesflow te detecteren. Voorbeelden truefalse
	Oplossingscategorie ResolutionCategory	De classificatie van de oplossing die is geboden om de aanvraag af te handelen.
Omschrijving Dit attribuut biedt een gestructureerde categorisatie van hoe een aanvraag is opgelost, zoals 'Software Fix', 'Gebruikerstraining' of 'Data Correctie'. Het gaat verder dan een simpele close code om de aard van de oplossing te beschrijven. Dit is essentieel voor het Resolution Category Accuracy dashboard, waar het kan worden vergeleken met het initiële servicetype om consistentie te controleren. Het analyseren van oplossingscategorieën helpt bij het identificeren van trends in problemen en informeert proactief probleembeheer, bijvoorbeeld als veel aanvragen worden opgelost door gebruikerstraining. Het belang Het biedt inzichten in de aard van oplossingen, en helpt bij het identificeren van trends in terugkerende problemen en kansen voor proactief probleembeheer of gebruikerstraining. Vindplaats Deze informatie maakt deel uit van de operationele en productcategorisatievelden op de fulfillment ticket, vaak gelabeld als 'Resolution Category'. Voorbeelden AccountbeheerHardwarestoringSoftware-upgradeInformatie Verstrekt
	SLA-streefdatum SlaTargetDate	De datum en tijd waarop de serviceaanvraag naar verwachting is afgehandeld volgens de Service Level Agreement (SLA).
Omschrijving De SLA Target Date is een berekende timestamp die de deadline voor het voltooien van de serviceaanvraag vertegenwoordigt. Deze wordt bepaald door de serviceovereenkomstregels, die vaak rekening houden met factoren zoals de prioriteit en het type van de aanvraag. Dit attribuut is fundamenteel voor het SLA Compliance Overview dashboard. Het dient als de benchmark waartegen de werkelijke afhandeltijd wordt gemeten. Door de 'EventEndTime' van de uiteindelijke afhandelingsactiviteit te vergelijken met deze target date, kunnen we bepalen of de serviceverplichting is nagekomen. Het belang Dit is de primaire benchmark voor het meten van serviceprestaties ten opzichte van commitments, waardoor het essentieel is voor SLA compliance monitoring en rapportage. Vindplaats Deze datum wordt berekend en opgeslagen door de Service Level Management (SLM) module en kan worden gevonden op gerelateerde SLM-formulieren die gekoppeld zijn aan de serviceaanvraag. Voorbeelden 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z

Verplicht Aanbevolen Optioneel

Service Request Management Activiteiten

Deze belangrijke processtappen en mijlpalen moeten worden vastgelegd in uw event log voor accurate procesontdekking en -visualisatie.

6 Aanbevolen 8 Optioneel

	Activiteit	Omschrijving
	Aanvraag Toegewezen	De serviceaanvraag is toegewezen aan een specifieke fulfillment agent of team dat verantwoordelijk is voor de voltooiing van het werk. Dit markeert het einde van de triagefase.
Het belang Deze mijlpaal is cruciaal voor het meten van triage-tijd en het analyseren van agent workload. Frequente her-toewijzingen kunnen duiden op routingproblemen of vaardigheidstekorten. Vindplaats Deze event kan expliciet worden vastgelegd vanuit de audit log van de velden 'Assigned Group' of 'Assignee' op het SRM:Request of gerelateerde fulfillment applicatieformulieren (bijv. WOI:WorkOrder). Vastleggen Timestamp uit de audit log die de eerste keer een non-null waarde toont die is ingesteld in het veld 'Assignee'. Gebeurtenistype explicit
	Service Request Gesloten	De serviceaanvraag is formeel gesloten en verplaatst naar een alleen-lezen, gearchiveerde status. Dit gebeurt na afhandeling en nadat eventuele bevestigingsperiodes zijn verstreken.
Het belang Deze activiteit vertegenwoordigt het definitieve einde van het proces. De tijd tussen 'Opgelost' en 'Gesloten' kan inefficiënties in de afsluitprocedure benadrukken. Vindplaats Afgeleid van de laatste statuswijziging in het SRM:Request formulier naar 'Afgesloten'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert naar 'Gesloten'. Gebeurtenistype inferred
	Serviceaanvraag geannuleerd	De serviceaanvraag is ingetrokken, hetzij door de aanvrager, hetzij door de servicedesk voordat de afhandeling was voltooid. Dit is een terminale status voor de aanvraag.
Het belang Het bijhouden van annuleringen helpt bij het identificeren van patronen, zoals gebruikers die incorrecte aanvragen indienen of services die niet langer nodig zijn, wat kan leiden tot verbeteringen in de servicecatalogus. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier naar 'Geannuleerd'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert naar 'Geannuleerd'. Gebeurtenistype inferred
	Serviceaanvraag ingediend	Deze activiteit markeert de creatie en indiening van een nieuwe serviceaanvraag door een gebruiker. Het wordt vastgelegd wanneer een nieuwe entry wordt aangemaakt in het SRM:Request formulier met een initiële status, doorgaans 'Ingediend'.
Het belang Dit is het startpunt voor elke serviceaanvraag case, essentieel voor het meten van de totale lifecycle-duur en het analyseren van de aanvraagvolumes. Vindplaats Deze event wordt afgeleid uit de creatie-timestamp en de initiële status (bijv. 'Submitted') van een record in het SRM:Request formulier. Vastleggen Identificeer de aanmaak-timestamp voor een nieuwe Service Request ID in het SRM:Request formulier wanneer de status 'Submitted' is. Gebeurtenistype inferred
	Serviceaanvraag opgelost	De afhandeling van de serviceaanvraag is voltooid en de oplossing is gecommuniceerd aan de aanvrager. De aanvraag wacht op definitieve bevestiging of sluit automatisch na een ingestelde periode.
Het belang Een cruciale mijlpaal die het einde van de serviceleveringscyclus markeert. Het is het primaire eindpunt voor het meten van de oplostijd en SLA-naleving. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier naar 'Opgelost' of 'Voltooid'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert naar 'Opgelost' of 'Voltooid'. Gebeurtenistype inferred
	Uitvoering bezig	De toegewezen agent of het team is actief begonnen met de afhandeling van de serviceaanvraag. Dit geeft aan dat de aanvraag is verschoven van een wachtrij naar een actieve werkstatus.
Het belang Markeert het begin van het waardetoevoegende uitvoeringswerk. Het analyseren van de tijd die in deze fase wordt besteed, helpt bij het begrijpen van de resourceproductiviteit en de complexiteit van de uitvoering. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier naar 'In Uitvoering'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert naar 'In behandeling'. Gebeurtenistype inferred
	Aanvraag Goedgekeurd	De serviceaanvraag is formeel goedgekeurd door de vereiste partij, waardoor het fulfillment proces kan doorgaan. Deze event volgt doorgaans op een 'Wacht op goedkeuring' status.
Het belang Markeert het einde van het goedkeurings-subproces en is een belangrijke mijlpaal voor het bijhouden van de duur van goedkeuringen en hun impact op de totale oplostijd. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier van 'Wacht op goedkeuring' naar een volgende status zoals 'Planning' of 'In Uitvoering'. De goedkeuringsbeslissing zelf wordt gelogd in gerelateerde goedkeuringsformulieren. Vastleggen Timestamp van de statuswijziging van 'Wacht op goedkeuring' na een positieve goedkeuringsbeslissing. Gebeurtenistype inferred
	Aanvraag Hervat	De serviceaanvraag is uit een pending of wachtende status gehaald, meestal nadat de benodigde informatie door de gebruiker is verstrekt. De werkzaamheden aan de aanvraag worden hervat door de fulfillment agent.
Het belang Markeert het einde van een wachtperiode, wat een precieze meting mogelijk maakt van externe wachttijden en hun impact op de SLA-compliance. Vindplaats Afgeleid wanneer de status van de SRM:Request verandert van 'In afwachting' terug naar 'In Uitvoering'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert van 'In afwachting' naar 'In behandeling'. Gebeurtenistype inferred
	Aanvraag ter beoordeling	De serviceaanvraag ondergaat een initiële beoordeling en triage door de servicedesk om de aard, prioriteit en het geschikte fulfillment team te bepalen. Dit wordt doorgaans weergegeven door een statuswijziging in het aanvraagrecord.
Het belang Het bijhouden van deze activiteit helpt de triage-efficiëntie te meten en identificeert vertragingen tussen indiening en toewijzing, wat cruciaal is voor de 'Average Triage Time' KPI. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier naar een waarde zoals 'Ter beoordeling' of 'Planning'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert naar 'Ter beoordeling'. Gebeurtenistype inferred
	Aanvraag wacht op goedkeuring	De serviceaanvraag is ingediend bij een aangewezen goedkeurder of goedkeuringsgroep en wacht op een beslissing voordat de afhandeling kan beginnen. Dit is een veelvoorkomende stap bij aanvragen met betrekking tot kosten of toegangsrechten.
Het belang Deze activiteit isoleert goedkeuringsgerelateerde vertragingen, waardoor analyse van goedkeuringscyclustijden en identificatie van bottlenecks in de goedkeuringsketen mogelijk is. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier naar een waarde zoals 'Wacht op goedkeuring'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert naar 'Wacht op goedkeuring'. Gebeurtenistype inferred
	Informatie gevraagd van gebruiker	De fulfillment agent heeft aanvullende informatie nodig van de aanvrager om de werkzaamheden voort te zetten. De aanvraag wordt doorgaans in een 'Pending' status geplaatst.
Het belang Deze activiteit is cruciaal voor het berekenen van 'Externe Informatie Wachttijd' en identificeert hoe vaak aanvragen stagneren als gevolg van onvolledige informatie. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier naar 'In afwachting' met een statusreden zoals 'Wacht op klant' of 'Wacht op informatie'. Vastleggen Timestamp van de statuswijziging naar 'In afwachting', gecombineerd met een specifieke statusreden. Gebeurtenistype inferred
	Oplossing bevestigd door gebruiker	De aanvrager heeft actief bevestigd dat de service naar tevredenheid is geleverd en de aanvraag is opgelost. Dit activeert vaak de uiteindelijke sluiting van de aanvraag.
Het belang Biedt een duidelijke indicator van klanttevredenheid en sluit de service-interactie formeel af. Het scheidt procesafhandeling van klantacceptatie. Vindplaats Deze event kan worden vastgelegd in de SRM:Request werklogs of activiteitsnotities wanneer een gebruiker bevestigt via de portal of e-mail. Het is niet altijd een discrete status. Vastleggen Scan werklogs (SRM:WorkInfo) op specifieke vermeldingen die gebruikersbevestiging of voltooiing van een enquête aangeven. Gebeurtenistype explicit
	Oplossing Geïmplementeerd	Het technische werk dat nodig is om de serviceaanvraag af te handelen, is voltooid door de agent. De aanvraag is nu klaar voor bevestiging met de gebruiker voordat deze formeel wordt afgehandeld.
Het belang Deze activiteit scheidt de technische voltooiing van de formele afhandeling, en helpt zo vertragingen tussen werkvoltooiing en gebruikersbevestiging te identificeren. Vindplaats Dit kan worden afgeleid uit een statuswijziging op een backend fulfillment ticket (bijv. Work Order status naar 'Completed') voordat de bovenliggende SRM:Request als 'Resolved' wordt gemarkeerd. Vastleggen Timestamp wanneer een backend ticket (Work Order, Incident, etc.) gekoppeld aan de SRM:Request als voltooid wordt gemarkeerd. Gebeurtenistype inferred
	Verzoek Afgewezen	De serviceaanvraag is afgewezen tijdens een goedkeuringsfase. Dit is een terminale status die het proces stopt voordat de afhandeling begint.
Het belang Het analyseren van afgewezen aanvragen kan problemen aan het licht brengen met aanvraagrechtvaardigingen, geschiktheidscriteria of goedkeuringsbeleid. Vindplaats Afgeleid van een statuswijziging in het SRM:Request formulier naar 'Afgewezen'. Vastleggen Timestamp van de update event waarbij het 'Status'-veld van de SRM:Request verandert naar 'Afgewezen'. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit BMC Helix ITSM haalt

Stappen

Toegang tot Smart Reporting: Log in bij uw BMC Helix ITSM-omgeving. Navigeer naar de rapportagesectie en start Smart Reporting. Afhankelijk van uw versie kan dit worden aangeduid als 'Rapporten' of 'Smart Reporting'.
Een nieuw rapport maken: Eenmaal in de Smart Reporting-interface selecteert u de optie om een nieuw rapport te maken. Kies 'Rapport' als type.
Databron en weergave selecteren: U wordt gevraagd een databron te selecteren. Kies uw primaire AR System databron. Zoek voor de weergave naar en selecteer de Service Request-weergave, die doorgaans gebaseerd is op het SRM:Request formulier.
Extra formulieren toevoegen (joins): Om de volledige levenscyclus vast te leggen, moet u het hoofdformulier SRM:Request koppelen aan gerelateerde formulieren. Gebruik het tabblad 'Data' en koppel de volgende formulieren:
- SRM:WorkInfo (op SR ID+ = Request Number) om details over uitvoeringactiviteiten en werklogs te verkrijgen.
- AP:Signature (op Request = SRInstanceID) om goedkeuringsgerelateerde events zoals goedkeuringen en afwijzingen te verkrijgen. Mogelijk heeft u hiervoor een aangepaste join nodig.
Rapportkolommen definiëren: Sleep de vereiste velden van de gekoppelde formulieren naar het 'Kolommen'-gebied. Dit omvat velden zoals Request Number, Submit Date, Status, Description, Priority, Assigned To en Assigned Group van SRM:Request, en gerelateerde velden van de gekoppelde formulieren.
Berekende velden voor activiteiten maken: De kern van deze methode is het creëren van een reeks berekende velden om de timestamp van elke activiteit weer te geven. Ga naar het tabblad 'Data' en maak een nieuw berekend veld voor elke activiteit. Bijvoorbeeld:
- Ingezonden timestamp: Gebruik het veld Submit Date direct.
- Goedkeuring timestamp: Gebruik de Signature Date van het AP:Signature formulier.
- Werk in uitvoering timestamp: Gebruik de MIN(Submit Date) van SRM:WorkInfo gegroepeerd op Request Number.
Het rapport structureren voor een Union: Smart Reporting heeft geen eenvoudige 'UNION ALL'-knop zoals SQL. Om dit te bereiken, maakt u één rapport en gebruikt u geavanceerde functies of subqueries om de data te pivoteren. Een veelgebruikte techniek is het maken van meerdere berekende kolommen, één voor de timestamp van elke activiteit. U moet dan de uiteindelijke export formatteren om deze kolommen om te zetten in afzonderlijke rijen voor elke activiteit.
Filters toepassen: Om de dataomvang te beperken en de prestaties te verbeteren, voegt u filters toe aan uw rapport. Filter minimaal op Submit Date van het SRM:Request formulier om een specifiek datumbereik te selecteren. Voeg ook filters toe voor 'Bedrijf' als u in een multi-tenant omgeving werkt.
Rapport uitvoeren en data bekijken: Voer het rapport uit om er zeker van te zijn dat de data correct wordt opgehaald. Controleer op correcte joins, ingevulde kolommen en of uw berekende velden de verwachte timestamps retourneren.
Het rapport exporteren: Zodra het rapport is gevalideerd, exporteert u de data. Kies CSV of Microsoft Excel als exportformaat, aangezien deze eenvoudig te verwerken zijn voor import in process mining tools.
Uiteindelijke datatransformatie: Na het exporteren moet u de data transformeren van een breed formaat (één rij per serviceaanvraag met veel timestamp-kolommen) naar een lang formaat (één rij per activiteit). Gebruik een script (bijv. Python, PowerShell) of een tool zoals Excel Power Query om de timestamp-kolommen te unpivotten naar twee kolommen: ActivityName en EventStartTime. Deze stap is cruciaal voor het creëren van de vereiste event log-structuur.

Configuratie

Vereisten: U moet beschikken over een gebruikersaccount met rapportagepermissies in BMC Helix ITSM, specifiek toegang tot het aanmaken en uitvoeren van rapporten in Smart Reporting. U heeft ook permissies nodig om data te lezen uit de SRM:Request, SRM:WorkInfo en AP:Signature formulieren.
Kernformulieren: Het rapport wordt opgebouwd door deze kernformulieren te koppelen:
- SRM:Request: Het primaire formulier met de hoofddetails van de serviceaanvraag.
- SRM:WorkInfo: Bevat worklog-entries, die worden gebruikt om uitvoeringactiviteiten af te leiden.
- AP:Signature: Bevat goedkeuringsrecords, die essentieel zijn voor het volgen van goedkeuringsgerelateerde activiteiten.
Datumfilter: Pas altijd een datumfilter toe op het veld SRM:Request.Submit Date. Een bereik van 3 tot 6 maanden data wordt aanbevolen om een representatieve steekproef en rapportprestaties in balans te houden.
Belangrijke filters: Filter naast een datumbereik ook op Company om data voor een specifieke bedrijfsentiteit te isoleren. U kunt er ook voor kiezen om specifieke aanvraagtypen of statussen, zoals 'Concept', uit te filteren die niet relevant zijn voor de procesanalyse.
Prestatieoverwegingen: Rapporten die meerdere formulieren over een breed datumbereik koppelen, kunnen traag zijn om te genereren. Het wordt sterk aanbevolen om het rapport te plannen voor uitvoering buiten piekuren voor grote datavolumes. Overweeg om de extractie op te splitsen in kleinere, maandelijkse stukken als er timeouts optreden.

a Voorbeeldquery config

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

Stappen

Vereisten: Zorg ervoor dat u een databaseclient (zoals DBeaver, SQL Server Management Studio of Oracle SQL Developer) en read-only credentials voor de BMC Helix AR System database heeft.
Verbinden met database: Gebruik uw databaseclient om een verbinding tot stand te brengen met de AR System databaserver.
De query voorbereiden: Kopieer de complete SQL-query, zoals verstrekt in de sectie 'Query' van dit document, naar de query-editor van uw databaseclient.
Parameters instellen: Zoek de placeholder-waarden binnen de query. Vervang :start_date en :end_date door het gewenste datumbereik voor de extractie, bijvoorbeeld '2023-01-01' en '2023-12-31'. Vervang :company_name door de specifieke bedrijfsnaam waarop u wilt filteren, indien van toepassing.
De query uitvoeren: Voer de aangepaste SQL-query uit. Afhankelijk van het datumbereik en de systeemgrootte kan dit enkele minuten duren.
Resultaten bekijken: Zodra de query is voltooid, wordt een resultatenset met de event log weergegeven. Bekijk de data kort om er zeker van te zijn dat deze correct is gevuld en de verwachte kolommen en activiteiten bevat.
Timestamps verwerken: Controleer of alle timestamp-kolommen, specifiek EventStartTime, EventEndTime en LastDataUpdate, consistent zijn geformatteerd, zoals 'YYYY-MM-DD HH:MI:SS'. Als uw database deze in een ander formaat retourneert, pas dan de TO_CHAR of CONVERT functies in de query dienovereenkomstig aan.
Data exporteren: Gebruik de exportfunctionaliteit van uw databaseclient om de volledige resultatenset op te slaan als een CSV-bestand. Kies UTF-8-codering om compatibiliteit te garanderen.
Voorbereiden op upload: Geef het bestand een geschikte naam, bijvoorbeeld servicerequest_eventlog.csv. Dit bestand is nu klaar om geüpload te worden naar het ProcessMind platform.

Configuratie

Database Credentials: Een read-only gebruikersaccount voor de AR System database is vereist. Dit voorkomt onbedoelde datamodificatie en voldoet aan de best practices voor beveiliging.
Datumfilter: De query bevat :start_date en :end_date placeholders. Het is cruciaal om een specifiek en redelijk datumbereik in te stellen, doorgaans 3 tot 12 maanden data, om de query-prestaties en het datavolume te beheren. Filtering wordt toegepast op de Submit_Date van de serviceaanvraag.
Bedrijfsfilter: Een placeholder :company_name is opgenomen om aanvragen voor een specifiek operationeel bedrijf te filteren. Als u data voor alle bedrijven moet extraheren, kunt u de regel AND req.Company = :company_name verwijderen of instellen op een wildcard indien ondersteund.
Statuswaarden: De query gebruikt standaard BMC Helix ITSM status integer waarden (bijv. Submitted = 0, In Review = 1, etc.). Uw systeem kan aangepaste statussen of verschillende integer mappings hebben. Verifieer deze waarden aan de hand van het SYS:Status formulier of de developer studio van uw systeem en pas de WHERE clausules in de query indien nodig aan.
Prestaties: Directe databasequeries op grote tabellen zoals SRM_Request en de audit logs kunnen resource-intensief zijn. Plan de extractie tijdens daluren om de impact op de systeemprestaties te minimaliseren.

a Voorbeeldquery sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

Stappen

Vereisten: Zorg ervoor dat u Python 3.6 of nieuwer op uw systeem heeft geïnstalleerd. Installeer de requests library, die nodig is voor het maken van HTTP API-calls, door pip install requests uit te voeren in uw terminal of commandoregel.
API Credentials verkrijgen: Creëer of verkrijg credentials voor een dedicated service account in BMC Helix ITSM. Dit account vereist minimaal read-only permissies voor het SRM:Request formulier en het corresponderende audit log formulier, dat vaak SRM:Request_AuditLog of iets soortgelijks heet. Noteer uw gebruikersnaam, wachtwoord en de basis-URL voor uw BMC Helix-instantie (bijv. https://[uw-bedrijf].bmc.com).
Het Python Script configureren: Kopieer het geleverde Python script naar een bestand, bijvoorbeeld extract_servicerequests.py. Bewerk het script en vul de placeholder-variabelen bovenaan in: BASE_URL, USERNAME, PASSWORD en AUDIT_FORM_NAME. Pas het STATUS_ACTIVITY_MAP dictionary aan om te matchen met de specifieke statuswaarden die in de serviceaanvraag-workflow van uw organisatie worden gebruikt.
Extractieperiode instellen: Wijzig de START_DATE en END_DATE variabelen in het script. Dit definieert het tijdsvenster voor de extractie op basis van de indieningsdatum van de serviceaanvraag. Gebruik voor initiële tests een klein datumbereik, zoals één enkele dag.
Het script uitvoeren: Voer het script uit vanuit uw terminal met het commando python extract_servicerequests.py. Het script zal eerst authenticeren met de API om een token te verkrijgen.
Initiële data-ophaling: Het script bevraagt het SRM:Request formulier om een lijst op te halen van alle serviceaanvragen die binnen het opgegeven datumbereik zijn aangemaakt. Deze stap verzamelt de case ID en bijbehorende statische attributen zoals prioriteit en servicetype.
Event-historie ophalen: Het script itereert door elke serviceaanvraag ID die in de vorige stap is verkregen. Voor elke ID doet het een tweede API-call naar het geconfigureerde audit log formulier om de gedetailleerde historie van statuswijzigingen voor die specifieke aanvraag op te halen.
Data transformeren naar Event Log: Voor elke record uit de audit log mapt het script de statuswijziging naar een standaard activiteitsnaam met behulp van de STATUS_ACTIVITY_MAP. Het creëert een rij voor elke gemapte activiteit, inclusief de Service Request ID, Activiteitsnaam en de timestamp van de wijziging.
Submitted Event genereren: Het script creëert ook de initiële 'Service Request Submitted' activiteit voor elke aanvraag, met behulp van de Submit Date van het hoofd SRM:Request formulier.
Exporteren naar CSV: Na het verwerken van alle serviceaanvragen en hun histories, consolideert het script de gegenereerde rijen in één lijst en schrijft de data naar een CSV-bestand genaamd servicerequest_event_log.csv. Dit bestand is geformatteerd en klaar voor upload naar een process mining tool.

Configuratie

API Endpoints: Het script gebruikt voornamelijk twee API-endpoints. Authenticatie wordt afgehandeld via api/jwt/login. Data wordt opgevraagd van arsys/v1/entry/SRM:Request voor de lijst met cases en arsys/v1/entry/[AUDIT_FORM_NAME] voor de event-historie.
Service Account Permissies: Een dedicated service account met leesrechten voor het SRM:Request formulier en het audit log formulier van het systeem is vereist. Het gebruik van een service account is cruciaal voor beveiliging en traceerbaarheid.
Datumfilter: Het script is geconfigureerd om serviceaanvragen te filteren op basis van hun Submit Date. Het wordt aanbevolen om data in beheersbare batches, zoals 3-6 maanden per keer, te extraheren om betrouwbare prestaties te garanderen.
Status-naar-Activiteit Mapping: Het STATUS_ACTIVITY_MAP dictionary in het script is de kern van de transformatielogica. Het moet zorgvuldig worden geconfigureerd om de aangepaste statussen van uw organisatie te weerspiegelen en deze te mappen aan de gewenste activiteitsnamen. Elke status in uw workflow die niet in de map aanwezig is, wordt genegeerd.
Audit Log Formulier: De mogelijkheid van het script om gedetailleerde activiteiten vast te leggen, is volledig afhankelijk van een queryable audit log. U moet de juiste formuliernaam in uw omgeving identificeren die de statuswijzigingshistorie voor serviceaanvragen opslaat en de AUDIT_FORM_NAME variabele dienovereenkomstig bijwerken.
Paginatie: Het script verwerkt API-paginatie automatisch om alle records op te halen. De limit parameter in de API-call is ingesteld om 1000 records per verzoek op te halen om prestaties en geheugengebruik in balans te houden.

a Voorbeeldquery python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

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

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

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

BMC Helix ITSM Smart Reporting voor Serviceaanvragen

Stappen

Configuratie

a Voorbeeldquery config

Directe SQL-query op AR System Databasetabellen

Stappen

Configuratie

a Voorbeeldquery sql

Python Script Extractie via de BMC Helix REST API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te starten?

Ontgrendel Efficiëntie: Optimaliseer Service Request Management Vandaag

Uw Service Request Management Data Template

Uw Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activiteiten

Extractie Guides

BMC Helix ITSM Smart Reporting voor Serviceaanvragen

Stappen

Configuratie

a Voorbeeldquery config

Directe SQL-query op AR System Databasetabellen

Stappen

Configuratie

a Voorbeeldquery sql

Python Script Extractie via de BMC Helix REST API

Stappen

Configuratie

a Voorbeeldquery python

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Ontgrendel Efficiëntie: Optimaliseer Service Request Management Vandaag

Service Request Management `Attributes`