> Continu verbeteren van processen > Beheer van serviceaanvragen > BMC Helix ITSM > Datatemplate

Datatemplate voor serviceverzoekbeheer

BMC Helix ITSM

Attributen voor serviceverzoekbeheer (20) Activiteiten in het beheer van serviceaanvragen (14) Extractiegidsen (3)

Datatemplate voor serviceverzoekbeheer

Deze template geeft een helder overzicht van de essentiële datavelden die je verzamelt en de belangrijkste activiteiten die je bij het beheer van serviceverzoeken volgt. Je vindt er ook praktische aanwijzingen om deze data efficiënt uit BMC Helix ITSM te halen. Gebruik de template om de datavoorbereiding eenvoudiger te maken en met zekerheid aan de slag te gaan met process mining.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Extractiehandleiding voor BMC Helix ITSM

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

Template downloaden

Attributen voor serviceverzoekbeheer

Deze datavelden zijn essentieel voor een volledig event log. Daarmee kun je het proces voor serviceaanvragen grondig analyseren.

5 Verplicht 6 Aanbevolen 9 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de gebeurtenis of taak die op een bepaald moment in de levenscyclus van het serviceverzoek plaatsvond.
Beschrijving Dit attribuut beschrijft een specifieke stap of statuswijziging in het proces van een serviceverzoek, zoals ‘Verzoek in beoordeling’, ‘Afhandeling bezig’ of ‘Serviceverzoek opgelost’. Elke activiteit staat voor één gebeurtenis in het verloop van een serviceverzoek van begin tot eind. De volgorde en frequentie van activiteiten analyseren is de kern van process mining. Zo ontdek je procesmodellen, spoor je bottlenecks op en analyseer je procesvarianten. Het is belangrijk om te weten welke activiteiten plaatsvinden, in welke volgorde en hoe vaak, zodat je processen kunt verbeteren. Waarom dit belangrijk is Activiteiten vormen de bouwstenen van het procesmodel. Door ze bij te houden, kun je de processtroom visualiseren en analyseren en zien hoe het werk in de praktijk verloopt. Waar vind je dit? Dit wordt meestal afgeleid uit wijzigingen in de velden ‘Status’ en ‘Status Reason’ van het formulier ‘SRM:Request’ of uit gerelateerde aanvraaglogboeken voor de afhandeling, zoals Incident of Work Order. Voorbeelden Verzoek wacht op goedkeuringAfhandeling bezigServiceverzoek opgelostServiceverzoek gesloten
	Service Request-ID ServiceRequestId	De unieke identificatiecode van elk serviceverzoek. Deze wordt gebruikt om de volledige levenscyclus te volgen.
Beschrijving Het Service Request-ID identificeert elk afzonderlijk serviceverzoek dat door een gebruiker of systeem is ingediend. Het vormt de verbindende schakel tussen alle gebeurtenissen, van de eerste registratie tot de definitieve sluiting. Zo kun je elk serviceverzoek van begin tot eind analyseren. Bij process mining is dit ID nodig om de volgorde van activiteiten per case te reconstrueren. De tool groepeert alle bijbehorende gebeurtenissen, zoals ‘Serviceverzoek ingediend’, ‘Verzoek toegewezen’ en ‘Serviceverzoek gesloten’, in één procesinstantie. Dat vormt de basis voor alle procesanalyses. Waarom dit belangrijk is Dit is de belangrijkste identificatiecode van de case. Zonder deze code kun je het serviceverzoek niet van begin tot eind volgen en zijn procesontdekking en -analyse niet mogelijk. Waar vind je dit? Dit is meestal het veld ‘InstanceId’ of ‘Request Number’ in het formulier ‘SRM:Request’ in BMC Helix ITSM. Voorbeelden SR000010572931SR000010572932SR000010572933
	Starttijd EventStartTime	De timestamp die aangeeft wanneer een activiteit of gebeurtenis begon.
Beschrijving Dit attribuut legt de exacte datum en tijd vast waarop een activiteit begon. Elke gebeurtenis in het log, van de eerste indiening tot de definitieve sluiting, moet een starttijd hebben om de chronologische volgorde van het proces vast te leggen. Deze timestamp is nodig voor alle tijdsanalyses met process mining. Je gebruikt hem om doorlooptijden, de duur van activiteiten en wachttijden tussen stappen te berekenen en om de naleving van SLA’s te controleren. Zo kun je bottlenecks opsporen en de procesprestaties door de tijd heen analyseren. Waarom dit belangrijk is De starttijd bepaalt de chronologische volgorde van gebeurtenissen. Dat is nodig om procesduren te berekenen, vertragingen op te sporen en het verloop van het proces te begrijpen. Waar vind je dit? Dit komt overeen met de timestampvelden in de auditlogboeken of statushistorietabellen van het formulier ‘SRM:Request’, zoals ‘Submit Date’ voor de eerste gebeurtenis. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Bronsysteem SourceSystem	Geeft aan uit welk systeem de data zijn gehaald.
Beschrijving Dit attribuut geeft aan waar de procesdata vandaan komen. In dit overzicht krijgt het de vaste waarde ‘BMC Helix ITSM’, om aan te geven dat alle gebeurtenissen rond de serviceverzoeken uit dit systeem komen. In omgevingen met meerdere gekoppelde systemen helpt dit veld om de herkomst van data te begrijpen en data op basis van de bron te verdelen. Zo blijven de herkomst en traceerbaarheid duidelijk, vooral wanneer je data uit verschillende platforms samenvoegt. Waarom dit belangrijk is Dit geeft context over de herkomst van data. Dat is belangrijk voor datagovernance, traceerbaarheid en het oplossen van problemen in omgevingen met meerdere systemen. Waar vind je dit? Dit is een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd. Het is geen veld in BMC Helix ITSM zelf. Voorbeelden BMC Helix ITSM
	Laatste data-update LastDataUpdate	De timestamp waarop de data voor dit proces voor het laatst vanuit het bronsysteem zijn bijgewerkt.
Beschrijving Dit attribuut geeft de datum en tijd aan van de meest recente data-extractie uit BMC Helix ITSM. Zo weet je hoe actueel de data zijn en op welke periode de analyse betrekking heeft. Dit is belangrijke metadata voor elk process mining-dashboard of elke analyse. Je ziet hiermee of de inzichten zijn gebaseerd op bijna realtime data of op een historische momentopname. Dat is van invloed op de geldigheid en relevantie van de conclusies. Waarom dit belangrijk is Dit laat zien hoe actueel de data zijn. Dat is belangrijk om beslissingen te nemen op basis van de meest recente informatie over de procesprestaties. Waar vind je dit? Deze timestamp wordt aangemaakt en toegevoegd tijdens het extraheren en laden van de data. Voorbeelden 2024-05-21T08:00:00Z
	Eindtijd EventEndTime	De timestamp die aangeeft wanneer een activiteit of gebeurtenis is afgerond.
Beschrijving De eindtijd markeert het einde van een activiteit. Veel activiteiten in ITSM-systemen zijn directe statuswijzigingen, maar sommige duren meetbaar lang. Met een eindtijd kun je de duur van zulke activiteiten nauwkeurig berekenen. Bij analyses gebruik je de eindtijd samen met de starttijd om de verwerkingstijd van afzonderlijke activiteiten te berekenen. Zo zie je welke taken de meeste tijd kosten, los van de wachttijd ertussen. Waarom dit belangrijk is Hiermee bereken je de verwerkingstijd van activiteiten. Dat is belangrijk om inefficiënte stappen op te sporen en te zien waar medewerkers hun tijd aan besteden. Waar vind je dit? Dit kan worden afgeleid. De eindtijd van een activiteit is vaak de starttijd van de volgende activiteit in dezelfde case. Voor de laatste activiteit gebruik je de timestamp waarop het verzoek is opgelost of gesloten. Voorbeelden 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Prioriteit Priority	De prioriteit van het serviceverzoek, die de impact op de bedrijfsvoering en de urgentie aangeeft.
Beschrijving De prioriteit bepaalt in welke volgorde en hoe snel verzoeken moeten worden afgehandeld. Veelvoorkomende waarden zijn ‘Kritiek’, ‘Hoog’, ‘Gemiddeld’ en ‘Laag’. De prioriteit wordt vaak bepaald op basis van de impact op de bedrijfsvoering en de urgentie van het verzoek. Door op prioriteit te analyseren, zie je of verzoeken met een hoge prioriteit sneller worden afgehandeld dan verzoeken met een lage prioriteit. Dit is een belangrijke dimensie in dashboards voor oplostijd en SLA-naleving. Zo controleer je of bronnen passend worden ingezet voor de belangrijkste behoeften van de organisatie. Waarom dit belangrijk is Hiermee beoordeel je of het proces het werk op de juiste manier prioriteert en de verwachte serviceniveaus haalt voor verzoeken met verschillende niveaus van bedrijfsimpact. Waar vind je dit? Dit is het veld ‘Priority’ in het formulier ‘SRM:Request’. Voorbeelden KritiekHoogGemiddeldLaag
	Servicetype ServiceType	De categorie of het type service dat de gebruiker aanvraagt.
Beschrijving Het servicetype geeft aan wat voor verzoek het is, bijvoorbeeld ‘Nieuwe software aanvragen’, ‘Wachtwoord opnieuw instellen’ of ‘Nieuwe medewerker onboarden’. Het is een belangrijke dimensie om procesdata te filteren en op te splitsen. Bij procesanalyses gebruik je dit attribuut om de prestaties van verschillende soorten verzoeken te vergelijken. Zo beantwoord je vragen als: ‘Welke servicetypen duren het langst om op te lossen?’ en ‘Bij welke servicetypen is het meeste herstelwerk nodig?’ Dit is belangrijk voor de dashboards voor oplostijd en SLA-naleving. Waarom dit belangrijk is Hiermee kun je serviceverzoeken uitsplitsen om processtromen te vergelijken, problemen per type op te sporen en verbeteringen gericht aan te pakken. Waar vind je dit? Deze data staan vaak in het veld ‘Title’ of een categorisatieveld in het formulier ‘SRM:Request’. Ze zijn afgeleid van de geselecteerde service in de catalogus. Voorbeelden Nieuwe hardware aanvragenToegang tot software aanvragenVPN-toegang instellen
	Status van verzoek RequestStatus	De status van het serviceverzoek op het moment van de gebeurtenis, bijvoorbeeld ‘In Progress’, ‘Pending’ of ‘Closed’.
Beschrijving Dit attribuut legt de status van het serviceverzoek op verschillende momenten in de levenscyclus vast. De status geeft context aan elke activiteit en is vaak de bron waaruit het attribuut ‘Activiteit’ wordt afgeleid. Door statussen te analyseren, zie je hoeveel tijd verzoeken in bepaalde statussen doorbrengen, zoals ‘Pending Customer’ of ‘Waiting for Approval’. Dat is nodig om bottlenecks en vertragingen door externe afhankelijkheden of interne wachtrijen op te sporen. Dit attribuut ondersteunt rechtstreeks het dashboard voor bottleneckidentificatie. Waarom dit belangrijk is Dit geeft een momentopname van de status van het verzoek. Zo kun je de tijd in wachtstatussen vergelijken met de tijd in actieve statussen en bottlenecks opsporen. Waar vind je dit? Dit is het veld ‘Status’ in het formulier ‘SRM:Request’. Historische waarden staan in het auditlogboek. Voorbeelden PlanningBezigIn afwachtingOpgelostGesloten
	Toegewezen medewerker AssignedAgent	De gebruiker die op dit moment is toegewezen aan de afhandeling van het serviceverzoek.
Beschrijving Dit attribuut geeft aan welke IT-medewerker of supportmedewerker op een bepaald moment verantwoordelijk is voor het verzoek. Verandert deze waarde tijdens de levenscyclus van een verzoek, dan wijst dat op een overdracht of herverdeling. Dit attribuut is belangrijk voor analyses van de prestaties en werkdruk van medewerkers. Je kunt ermee bijhouden hoeveel verzoeken elke medewerker afhandelt, wat de gemiddelde oplostijd is en hoe vaak verzoeken opnieuw worden toegewezen. Deze data helpt bij het verdelen van capaciteit en het vinden van mogelijkheden voor training. Waarom dit belangrijk is Door bij te houden aan welke medewerker een verzoek is toegewezen, kun je overdrachten analyseren, individuele prestaties meten en zien hoe het werk over het supportteam is verdeeld. Waar vind je dit? Dit komt overeen met het veld 'Assignee' of 'Assigned To' op de afhandelingsregistratie (bijvoorbeeld Work Order of Incident) die bij het serviceverzoek hoort. Voorbeelden Bob SmithAlice JohnsonCharlie Brown
	Toegewezen team AssignedTeam	De supportgroep of het team dat op dit moment aan het serviceverzoek is toegewezen.
Beschrijving Dit attribuut geeft aan welke functionele groep verantwoordelijk is voor de afhandeling van het verzoek, zoals 'Help Desk', 'Network Team' of 'Database Administration'. Een wijziging in dit veld betekent dat de verantwoordelijkheid naar een ander team is overgedragen. Met analyses per toegewezen team kun je bottlenecks op teamniveau vinden, overdrachten tussen teams analyseren en de efficiëntie van verschillende supportgroepen beoordelen. Dit attribuut is belangrijk voor de dashboards Verzoekherstel en herverdeling en Efficiëntie van triage. Zo zie je hoe het werk door de organisatie wordt gerouteerd. Waarom dit belangrijk is Hiermee kun je de processtroom tussen verschillende functionele groepen analyseren, inefficiënte routering opsporen en de prestaties per team meten. Waar vind je dit? Dit komt overeen met het veld 'Assigned Group' op de afhandelingsregistratie (bijvoorbeeld Work Order of Incident) die bij het serviceverzoek hoort. Voorbeelden ServicedeskInfrastructuurondersteuningApplicatieondersteuning niveau 2
	Aantal overdrachten HandoffCount	Het totale aantal keren dat een serviceverzoek opnieuw is toegewezen aan een andere medewerker of een ander team.
Beschrijving Deze berekende metriek telt hoe vaak de waarde van 'AssignedAgent' of 'AssignedTeam' verandert voor één serviceverzoek. Een hoog aantal overdrachten kan wijzen op versnippering van het proces, een lage first-call resolution of inefficiënte routering. Dit attribuut vormt de basis voor de KPI Gemiddeld aantal overdrachten per verzoek en wordt gebruikt in het dashboard Verzoekherstel en herverdeling. Door cases met veel overdrachten te analyseren, kun je de triage verbeteren, gerichtere training geven of de afhandeling efficiënter maken. Dat helpt vertragingen te beperken en de klanttevredenheid te verhogen. Waarom dit belangrijk is Dit meet hoe versnipperd het proces is en hoeveel communicatie dat vraagt. Veel overdrachten hangen vaak samen met langere oplostijden en een lagere procesefficiëntie. Waar vind je dit? Dit is een berekende metriek. Per unieke Service Request ID wordt het aantal verschillende waarden van het attribuut 'AssignedAgent' of 'AssignedTeam' geteld. Voorbeelden 0135
	Afdeling aanvrager RequestorDepartment	De afdeling of bedrijfseenheid van de gebruiker die het verzoek heeft ingediend.
Beschrijving Dit attribuut geeft aan bij welke afdeling de aanvrager hoort, zoals 'Financiën', 'Personeelszaken' of 'IT'. Deze informatie komt meestal uit het gebruikersprofiel in het systeem. Door de procesanalyse per afdeling uit te splitsen, kun je afdelingsspecifieke behoeften, verzoekpatronen en mogelijke onderwerpen voor gerichte training of serviceverbeteringen vinden. Zo kun je bijvoorbeeld nagaan of verzoeken van de afdeling Financiën langer op zich laten wachten. Waarom dit belangrijk is Hiermee kun je het servicegebruik en de procesprestaties per bedrijfseenheid analyseren. Zo komen afdelingsspecifieke problemen en trends aan het licht. Waar vind je dit? Deze informatie komt meestal uit het gebruikersprofiel van de gebruiker in het veld 'Requested For' op het formulier 'SRM:Request'. Voorbeelden FinanciënVerkoopPersoneelszakenInformatietechnologie
	Afsluitcode CloseCode	Een code die de uiteindelijke uitkomst of reden voor het afsluiten van het serviceverzoek aangeeft.
Beschrijving De afsluitcode biedt een gestandaardiseerde manier om de afhandeling van een serviceverzoek te classificeren. Voorbeelden zijn 'Opgelost door servicedesk', 'Geannuleerd door gebruiker' en 'Dubbel verzoek'. Met analyses van afsluitcodes zie je welke uitkomsten vaak voorkomen. Veel verzoeken die door gebruikers worden geannuleerd, kunnen bijvoorbeeld wijzen op een lang proces. Veel dubbele verzoeken kunnen duiden op een probleem met het systeem of de communicatie. Dit attribuut ondersteunt het dashboard Nauwkeurigheid van oplossingscategorieën. Waarom dit belangrijk is Dit levert gestructureerde data over de uitkomst van verzoeken op. Daarmee kun je de effectiviteit van oplossingen analyseren en zien waarom verzoeken niet zijn afgerond of zijn geannuleerd. Waar vind je dit? Deze informatie staat meestal in het veld 'Resolution' of 'Closure Code' op het afhandelingsticket dat bij het serviceverzoek hoort. Voorbeelden SuccesvolGeannuleerd door gebruikerNiet meer nodigAutomatisch opgelost
	Geëscaleerd IsEscalated	Een booleaanse vlag die aangeeft of het serviceverzoek is geëscaleerd.
Beschrijving Deze vlag krijgt de waarde true als een serviceverzoek functioneel of hiërarchisch is geëscaleerd. Een escalatie vindt meestal plaats als een verzoek niet volgens verwachting vordert, een SLA dreigt te overschrijden of goedkeuring of actie van een hoger niveau nodig is. Dit attribuut is belangrijk voor het dashboard Efficiëntieanalyse van verzoekescalaties. Je kunt de procespaden van geëscaleerde verzoeken filteren en analyseren om te zien wat de escalatie veroorzaakt, hoelang de afhandeling daarna duurt en hoe effectief het escalatieproces is. Waarom dit belangrijk is Hiermee kun je de verzoeken analyseren waarvoor escalatie nodig was. Zo vind je zwakke plekken in het standaardproces en aanleidingen voor complexe problemen. Waar vind je dit? Dit is meestal geen afzonderlijk veld. Je leidt de waarde af uit specifieke escalatieactiviteiten in het auditlogboek of uit wijzigingen in prioriteit of toewijzing die volgens een escalatieprotocol zijn uitgevoerd. Voorbeelden truefalse
	Herstelwerk IsRework	Een booleaanse vlag die aangeeft of een serviceverzoek herstelwerk heeft ondergaan, bijvoorbeeld doordat het naar een eerdere fase is teruggegaan.
Beschrijving Deze vlag markeert serviceverzoeken waarbij het proces een lus of herstelwerk bevat. Een verzoek dat bijvoorbeeld van 'Afhandeling bezig' teruggaat naar 'Verzoek in beoordeling' geldt als herstelwerk. De precieze definitie hangt af van de logica van het bedrijfsproces. Dit attribuut ondersteunt het dashboard Analyse van verzoekherstel en herverdeling en de KPI Herstelwerkpercentage. Je kunt de frequentie van herstelwerk meten en veelvoorkomende oorzaken analyseren, zoals een onjuiste eerste beoordeling of ontbrekende informatie. Zo worden inefficiënties in het proces zichtbaar. Waarom dit belangrijk is Dit maakt inefficiëntie meetbaar door cases te markeren die afwijken van de ideale route. Zo kun je de oorzaken van lussen en dubbel werk vinden. Waar vind je dit? Dit is een berekend attribuut op basis van de volgorde van activiteiten in het event log. De logica moet terugwaartse stappen in de processtroom herkennen. Voorbeelden truefalse
	Indieningskanaal SubmissionChannel	De manier of het kanaal waarmee het serviceverzoek is ingediend.
Beschrijving Dit attribuut registreert hoe het serviceverzoek is ingediend, bijvoorbeeld via een self-serviceportaal, e-mail, een telefoontje naar de servicedesk of een automatische systeemmelding. Het kanaal kan invloed hebben op de procesvarianten en oplostijden. Door het proces per indieningskanaal te analyseren, kun je inefficiënties en goede werkwijzen voor specifieke intakekanalen vinden. Verzoeken via het self-serviceportaal kunnen bijvoorbeeld sneller worden opgelost dankzij betere data bij de start. E-mailverzoeken vragen mogelijk meer handmatige triage. Waarom dit belangrijk is Dit helpt je te begrijpen hoe de intake invloed heeft op de procesefficiëntie, datakwaliteit en totale doorlooptijd. Zo kun je verbeteringen richten op specifieke kanalen. Waar vind je dit? Dit is vaak af te leiden uit velden zoals 'Client Type' of 'Reported Source' op het formulier 'SRM:Request' of op bijbehorende afhandelingstickets. Voorbeelden Self-serviceportaalE-mailTelefoonAutomatisch gegenereerd
	Oplossingscategorie ResolutionCategory	De classificatie van de oplossing waarmee het verzoek is afgehandeld.
Beschrijving Dit attribuut geeft op een gestructureerde manier aan hoe een verzoek is opgelost, bijvoorbeeld met een 'Softwareoplossing', 'Gebruikerstraining' of 'Datacorrectie'. Het beschrijft de aard van de oplossing en gaat daarmee verder dan een eenvoudige afsluitcode. Dit attribuut is belangrijk voor het dashboard Nauwkeurigheid van oplossingscategorieën. Je kunt de categorie vergelijken met het oorspronkelijke servicetype om te controleren of ze overeenkomen. Met analyses van oplossingscategorieën vind je trends in problemen en kun je problemen proactief aanpakken. Veel verzoeken die met gebruikerstraining worden opgelost, kunnen bijvoorbeeld aanleiding zijn voor extra training. Waarom dit belangrijk is Dit geeft inzicht in de aard van oplossingen en helpt terugkerende problemen en mogelijkheden voor proactief probleembeheer of gebruikerstraining te vinden. Waar vind je dit? Deze informatie staat bij de operationele en productcategorisatievelden op het afhandelingsticket, vaak onder de naam 'Resolution Category'. Voorbeelden AccountbeheerHardwarestoringSoftware-upgradeInformatie aangeleverd
	SLA overschreden IsSlaBreached	Een booleaanse vlag die aangeeft of het serviceverzoek na de SLA-streefdatum is opgelost.
Beschrijving Deze berekende vlag krijgt de waarde true als de laatste oplostimestamp van het serviceverzoek na de 'SLA Target Date' valt. Zo zie je per verzoek in één oogopslag of de SLA is gehaald. Dit attribuut is belangrijk voor het dashboard SLA-nalevingsoverzicht en de KPI SLA-nalevingspercentage. Je kunt de waarden optellen om het totale nalevingspercentage te berekenen en verzoeken filteren om de proceskenmerken van overschreden en nagekomen SLA’s te vergelijken. Zo kun je de oorzaken van SLA-overschrijdingen vinden. Waarom dit belangrijk is Dit maakt SLA-prestaties eenvoudiger te analyseren. Een vergelijking van timestamps wordt omgezet in een eenvoudige booleaanse vlag, zodat je nalevingspercentages makkelijk kunt meten en visualiseren. Waar vind je dit? Dit is een berekend veld. De logica is: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Voorbeelden truefalse
	SLA-streefdatum SlaTargetDate	De datum en tijd waarop het serviceverzoek volgens de Service Level Agreement (SLA) opgelost moet zijn.
Beschrijving De SLA-streefdatum is een berekende timestamp die de deadline voor het afhandelen van het serviceverzoek aangeeft. De datum wordt bepaald aan de hand van de regels in de serviceovereenkomst. Daarbij spelen vaak factoren mee zoals de prioriteit en het type verzoek. Dit attribuut is belangrijk voor het dashboard SLA-nalevingsoverzicht. Het vormt de norm waarmee de werkelijke oplostijd wordt vergeleken. Door de 'EventEndTime' van de laatste oplossingsactiviteit met deze streefdatum te vergelijken, kun je vaststellen of de serviceafspraak is nagekomen. Waarom dit belangrijk is Dit is de belangrijkste norm om de serviceprestaties met de gemaakte afspraken te vergelijken. Het is daarom essentieel voor het bewaken en rapporteren van SLA-naleving. Waar vind je dit? Deze datum wordt berekend en opgeslagen door de module Service Level Management (SLM). Je vindt hem op SLM-formulieren die aan het serviceverzoek zijn gekoppeld. Voorbeelden 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z

Verplicht Aanbevolen Optioneel

Activiteiten in het beheer van serviceaanvragen

Leg deze belangrijke processtappen en mijlpalen vast in het event log. Zo kun je het proces nauwkeurig ontdekken en visualiseren.

6 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Afhandeling bezig	De toegewezen medewerker of het team is begonnen met de afhandeling van het serviceverzoek. Het verzoek is daarmee niet langer in de wachtrij, maar wordt actief behandeld.
Waarom dit belangrijk is Dit markeert het begin van de afhandeling die waarde toevoegt. Door de tijd in deze fase te analyseren, krijg je zicht op de productiviteit van medewerkers en de complexiteit van de afhandeling. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request naar ‘In Progress’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert in ‘In Progress’. Gebeurtenistype inferred
	Serviceverzoek geannuleerd	De aanvrager of de servicedesk heeft het serviceverzoek ingetrokken voordat de afhandeling was afgerond. Dit is een eindstatus voor het verzoek.
Waarom dit belangrijk is Door annuleringen bij te houden, ontdek je patronen. Gebruikers dienen bijvoorbeeld onjuiste verzoeken in of hebben een dienst niet meer nodig. Die informatie kan helpen om de servicecatalogus te verbeteren. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request naar ‘Canceled’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert in ‘Canceled’. Gebeurtenistype inferred
	Serviceverzoek gesloten	Het serviceverzoek is formeel gesloten en heeft de alleen-lezenstatus ‘Gearchiveerd’ gekregen. Dit gebeurt nadat het verzoek is opgelost en de bevestigingsperiode is verstreken.
Waarom dit belangrijk is Deze activiteit markeert het definitieve einde van het proces. De tijd tussen ‘Resolved’ en ‘Closed’ kan inefficiënties in de sluitingsprocedure aan het licht brengen. Waar vind je dit? Af te leiden uit de laatste statuswijziging in het formulier SRM:Request naar ‘Closed’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert in ‘Closed’. Gebeurtenistype inferred
	Serviceverzoek ingediend	Deze activiteit markeert het aanmaken en indienen van een nieuw serviceverzoek door een gebruiker. De activiteit wordt vastgelegd wanneer in het formulier SRM:Request een nieuwe regel met een beginstatus wordt aangemaakt, meestal ‘Submitted’.
Waarom dit belangrijk is Dit is het beginpunt van elke case voor een serviceverzoek. Het is nodig om de totale doorlooptijd te meten en het aantal binnenkomende verzoeken te analyseren. Waar vind je dit? Deze gebeurtenis wordt afgeleid uit de aanmaaktimestamp en de beginstatus, bijvoorbeeld ‘Submitted’, van een regel in het formulier SRM:Request. Vastleggen Bepaal de aanmaaktimestamp van een nieuw Service Request-ID in het formulier SRM:Request wanneer de status ‘Submitted’ is. Gebeurtenistype inferred
	Serviceverzoek opgelost	De afhandeling van het serviceverzoek is klaar en de oplossing is aan de aanvrager doorgegeven. Het verzoek wacht op de definitieve bevestiging of wordt na een ingestelde periode automatisch gesloten.
Waarom dit belangrijk is Dit belangrijke meetpunt markeert het einde van de dienstverlening. Het is het belangrijkste eindpunt voor het meten van de oplostijd en de naleving van SLA’s. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request naar ‘Resolved’ of ‘Completed’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert in ‘Resolved’ of ‘Completed’. Gebeurtenistype inferred
	Verzoek toegewezen	Het serviceverzoek is toegewezen aan een specifieke medewerker of een team dat verantwoordelijk is voor de afhandeling. Hiermee eindigt de triagefase.
Waarom dit belangrijk is Dit meetpunt is belangrijk om de triagetijd en werkdruk per medewerker te analyseren. Regelmatige hertoewijzingen kunnen wijzen op problemen met de routering of ontbrekende vaardigheden. Waar vind je dit? Deze gebeurtenis kan rechtstreeks worden vastgelegd in het auditlogboek van de velden ‘Assigned Group’ of ‘Assignee’ in SRM:Request of in gerelateerde formulieren voor de afhandeling, zoals WOI:WorkOrder. Vastleggen Timestamp uit het auditlogboek waarop voor het eerst een niet-lege waarde wordt ingevuld in het veld ‘Assignee’. Gebeurtenistype explicit
	Informatie opgevraagd bij gebruiker	De medewerker die het verzoek afhandelt, heeft aanvullende informatie nodig van de aanvrager om verder te kunnen. Het verzoek krijgt dan meestal de status ‘Pending’.
Waarom dit belangrijk is Deze activiteit is nodig om de ‘wachttijd op externe informatie’ te berekenen en te zien hoe vaak verzoeken stilliggen door ontbrekende informatie. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request naar ‘Pending’ met een reden zoals ‘Customer Hold’ of ‘Awaiting Information’. Vastleggen Timestamp van de statuswijziging naar ‘Pending’, in combinatie met een specifieke statusreden. Gebeurtenistype inferred
	Oplossing bevestigd door gebruiker	De aanvrager heeft bevestigd dat de service naar tevredenheid is geleverd en het verzoek is opgelost. Dit leidt vaak tot de definitieve sluiting van het verzoek.
Waarom dit belangrijk is Dit geeft een duidelijke indicatie van de klanttevredenheid en rondt de dienstverlening formeel af. Zo maak je onderscheid tussen het oplossen van het verzoek en de acceptatie door de klant. Waar vind je dit? Deze gebeurtenis kan worden vastgelegd in de werklogboeken of activiteitsnotities van SRM:Request wanneer een gebruiker via het portaal of e-mail bevestigt. Er is niet altijd een aparte status voor. Vastleggen Doorzoek de werklogboeken (SRM:WorkInfo) op specifieke vermeldingen van een gebruikersbevestiging of ingevulde enquête. Gebeurtenistype explicit
	Oplossing uitgevoerd	De medewerker heeft het technische werk voor het serviceverzoek afgerond. De oplossing kan nu aan de gebruiker worden voorgelegd voordat het verzoek formeel wordt opgelost.
Waarom dit belangrijk is Deze activiteit maakt onderscheid tussen het afronden van het technische werk en het formeel oplossen van het verzoek. Zo zie je eventuele vertragingen tussen de afronding en de bevestiging door de gebruiker. Waar vind je dit? Dit kan worden afgeleid uit een statuswijziging van een achterliggend afhandelingsticket, bijvoorbeeld de status van een Work Order naar ‘Completed’, voordat het bovenliggende SRM:Request de status ‘Resolved’ krijgt. Vastleggen Timestamp waarop een achterliggend ticket, zoals een Work Order of Incident, dat aan SRM:Request is gekoppeld als afgerond wordt gemarkeerd. Gebeurtenistype inferred
	Verzoek afgewezen	Het serviceverzoek is tijdens de goedkeuringsfase afgewezen. Dit is een eindstatus: de afhandeling begint niet.
Waarom dit belangrijk is Een analyse van afgewezen verzoeken kan problemen met de onderbouwing, toelatingscriteria of het goedkeuringsbeleid aan het licht brengen. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request naar ‘Rejected’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert in ‘Rejected’. Gebeurtenistype inferred
	Verzoek goedgekeurd	De bevoegde partij heeft het serviceverzoek formeel goedgekeurd. De afhandeling kan nu verdergaan. Deze gebeurtenis volgt meestal op de status ‘Waiting for Approval’.
Waarom dit belangrijk is Dit markeert het einde van het goedkeuringsproces. Het is een belangrijk meetpunt om te bepalen hoe lang goedkeuringen duren en wat hun invloed is op de totale oplostijd. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request van ‘Waiting Approval’ naar een volgende status, zoals ‘Planning’ of ‘In Progress’. Het goedkeuringsbesluit zelf wordt vastgelegd in gerelateerde goedkeuringsformulieren. Vastleggen Timestamp van de statuswijziging vanuit ‘Waiting Approval’ na een positief goedkeuringsbesluit. Gebeurtenistype inferred
	Verzoek hervat	Het serviceverzoek is niet langer in de wachtstand, meestal nadat de gebruiker de gevraagde informatie heeft aangeleverd. De medewerker hervat de afhandeling.
Waarom dit belangrijk is Dit markeert het einde van een wachttijd. Zo kun je de wachttijd op externe informatie nauwkeurig meten en de invloed ervan op de naleving van SLA’s bepalen. Waar vind je dit? Af te leiden wanneer de status van SRM:Request verandert van ‘Pending’ naar ‘In Progress’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert van ‘Pending’ naar ‘In Progress’. Gebeurtenistype inferred
	Verzoek in beoordeling	De servicedesk beoordeelt en triageert het serviceverzoek om de aard en prioriteit ervan vast te stellen en het juiste afhandelingsteam te bepalen. Dit is meestal zichtbaar als een statuswijziging in de verzoekregistratie.
Waarom dit belangrijk is Door deze activiteit bij te houden, meet je hoe efficiënt de triage verloopt en zie je vertragingen tussen het indienen en toewijzen van een verzoek. Dit is belangrijk voor de KPI ‘Gemiddelde triagetijd’. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request naar bijvoorbeeld ‘In Review’ of ‘Planning’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert in ‘In Review’. Gebeurtenistype inferred
	Verzoek wacht op goedkeuring	Het serviceverzoek is voorgelegd aan een aangewezen goedkeurder of goedkeuringsgroep. De afhandeling kan pas beginnen nadat er een besluit is genomen. Dit is een gebruikelijke stap bij verzoeken met kosten of toegangsrechten.
Waarom dit belangrijk is Deze activiteit maakt vertragingen rond goedkeuring zichtbaar. Zo kun je de doorlooptijd van goedkeuringen analyseren en bottlenecks in de goedkeuringsketen opsporen. Waar vind je dit? Af te leiden uit een statuswijziging in het formulier SRM:Request naar bijvoorbeeld ‘Waiting Approval’. Vastleggen Timestamp van de update waarbij het veld ‘Status’ in SRM:Request verandert in ‘Waiting Approval’. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit BMC Helix ITSM

Stappen

Open Smart Reporting: Meld je aan bij je BMC Helix ITSM-omgeving. Ga naar het gedeelte voor rapportages en open Smart Reporting. Afhankelijk van je versie heet dit mogelijk 'Rapporten' of 'Smart Reporting'.
Maak een nieuw rapport: Kies in Smart Reporting de optie om een nieuw rapport te maken. Selecteer 'Rapport' als type.
Selecteer een databron en weergave: Je wordt gevraagd een databron te selecteren. Kies je primaire AR System-databron. Zoek bij de weergave naar de weergave Service Request en selecteer deze. Deze is meestal gebaseerd op het formulier SRM:Request.
Voeg aanvullende formulieren toe (joins): Om de volledige levenscyclus vast te leggen, moet je het hoofdformulier SRM:Request koppelen aan gerelateerde formulieren. Gebruik het tabblad 'Data' en voeg de volgende koppelingen toe:
- SRM:WorkInfo (op SR ID+ = Request Number) voor details over afhandelingsactiviteiten en werklogboeken.
- AP:Signature (op Request = SRInstanceID) voor goedkeuringsgebeurtenissen, zoals goedkeuringen en afwijzingen. Hiervoor heb je mogelijk een aangepaste koppeling nodig.
Bepaal de rapportkolommen: Sleep de benodigde velden uit de gekoppelde formulieren naar het gedeelte 'Kolommen'. Neem onder meer Request Number, Submit Date, Status, Beschrijving, Priority, Assigned To en Assigned Group uit SRM:Request op, plus relevante velden uit de gekoppelde formulieren.
Maak berekende velden voor activiteiten: Voor deze methode maak je een reeks berekende velden die de timestamp van elke activiteit weergeven. Ga naar het tabblad 'Data' en maak voor elke activiteit een berekend veld. Bijvoorbeeld:
- Timestamp van indiening: Gebruik rechtstreeks het veld Submit Date.
- Timestamp van goedkeuring: Gebruik Signature Date uit het formulier AP:Signature.
- Timestamp van werk in uitvoering: Gebruik MIN(Submit Date) uit SRM:WorkInfo, gegroepeerd op Request Number.
Maak het rapport geschikt voor een union: Smart Reporting heeft geen eenvoudige knop 'UNION ALL' zoals SQL. Maak hiervoor één rapport en gebruik geavanceerde functies of subquery’s om de data te draaien. Een gebruikelijke aanpak is om voor elke activiteit een aparte berekende kolom met de timestamp te maken. Vervolgens moet je de uiteindelijke export zo bewerken dat elke activiteit een aparte rij wordt.
Pas filters toe: Voeg filters toe om de hoeveelheid data te beperken en de prestaties te verbeteren. Filter minimaal op Submit Date uit het formulier SRM:Request om een specifieke periode te selecteren. Voeg ook een filter voor 'Company' toe als je met meerdere tenants werkt.
Voer het rapport uit en bekijk de data: Controleer of de data correct wordt opgehaald. Kijk of de koppelingen kloppen, de kolommen gevuld zijn en de berekende velden de verwachte timestamps opleveren.
Exporteer het rapport: Exporteer de data nadat je het rapport hebt gecontroleerd. Kies CSV of Microsoft Excel als bestandsformaat. Deze formaten zijn geschikt om de data te importeren in process mining-tools.
Zet de data om: Zet de geëxporteerde data om van een breed formaat (één rij per serviceaanvraag met meerdere timestampkolommen) naar een lang formaat (één rij per activiteit). Gebruik een script, bijvoorbeeld in Python of PowerShell, of een tool zoals Excel Power Query om de timestampkolommen om te zetten naar twee kolommen: ActivityName en EventStartTime. Zo krijgt het event log de vereiste structuur.

Configuratie

Vereisten: Je hebt een gebruikersaccount met rapportagerechten in BMC Helix ITSM nodig. Dit account moet rapporten kunnen maken en uitvoeren in Smart Reporting. Ook heb je leesrechten nodig voor de formulieren SRM:Request, SRM:WorkInfo en AP:Signature.
Belangrijke formulieren: Het rapport wordt opgebouwd door deze kernformulieren te koppelen:
- SRM:Request: het hoofdformulier met de belangrijkste gegevens van de serviceaanvraag.
- SRM:WorkInfo: bevat werklogboekregels waarmee je afhandelingsactiviteiten kunt afleiden.
- AP:Signature: bevat goedkeuringsgegevens die nodig zijn om goedkeuringsactiviteiten te volgen.
Filter op periode: Pas altijd een periodefilter toe op het veld SRM:Request.Submit Date. Een periode van 3 tot 6 maanden data is aan te raden. Zo krijg je een representatieve steekproef zonder dat het rapport te traag wordt.
Belangrijke filters: Filter naast de periode ook op Company om data van een specifieke bedrijfseenheid te selecteren. Je kunt ook aanvraagtypen of statussen uitsluiten die niet relevant zijn voor de procesanalyse, zoals 'Concept'.
Prestaties: Rapporten die meerdere formulieren over een lange periode koppelen, kunnen traag zijn. Plan rapporten met grote hoeveelheden data bij voorkeur buiten piekuren. Als er time-outs optreden, kun je de extractie opdelen in kleinere maandelijkse perioden.

a Voorbeeldquery sql

/*
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 dat je een databaseclient hebt, zoals DBeaver, SQL Server Management Studio of Oracle SQL Developer, en leesrechten voor de BMC Helix AR System-database.
Maak verbinding met de database: Gebruik je databaseclient om verbinding te maken met de AR System-databaseserver.
Bereid de query voor: Kopieer de volledige SQL-query uit het gedeelte 'Query' van dit document naar de query-editor van je databaseclient.
Stel parameters in: Zoek de tijdelijke waarden in de query. Vervang :start_date en :end_date door de gewenste periode, bijvoorbeeld '2023-01-01' en '2023-12-31'. Vervang :company_name door de naam van het bedrijf waarop je wilt filteren, indien van toepassing.
Voer de query uit: Voer de aangepaste SQL-query uit. Afhankelijk van de periode en de omvang van het systeem kan dit enkele minuten duren.
Controleer de resultaten: Na afloop verschijnt een resultatenset met het event log. Controleer kort of de data correct is opgehaald en de verwachte kolommen en activiteiten bevat.
Controleer de timestamps: Controleer of alle timestampkolommen, met name EventStartTime, EventEndTime en LastDataUpdate, hetzelfde formaat gebruiken, bijvoorbeeld 'YYYY-MM-DD HH:MI:SS'. Geeft je database een ander formaat terug, pas dan de functies TO_CHAR of CONVERT in de query aan.
Exporteer de data: Gebruik de exportfunctie van je databaseclient om de volledige resultatenset op te slaan als CSV-bestand. Kies UTF-8-codering voor compatibiliteit.
Maak het bestand klaar om te uploaden: Geef het bestand een duidelijke naam, bijvoorbeeld servicerequest_eventlog.csv. Daarna kun je het uploaden naar het ProcessMind-platform.

Configuratie

Databasegegevens: Je hebt een gebruikersaccount met alleen-lezenrechten voor de AR System-database nodig. Zo voorkom je dat data per ongeluk wordt gewijzigd en voldoe je aan de aanbevolen beveiligingspraktijken.
Filter op periode: De query bevat de tijdelijke waarden :start_date en :end_date. Stel een specifieke, redelijke periode in, meestal 3 tot 12 maanden, om de prestaties van de query en de hoeveelheid data beheersbaar te houden. Er wordt gefilterd op Submit_Date van de serviceaanvraag.
Bedrijfsfilter: De tijdelijke waarde :company_name filtert aanvragen van een specifiek bedrijf. Wil je data van alle bedrijven ophalen, verwijder dan de regel AND req.Company = :company_name of gebruik een jokerteken als dat wordt ondersteund.
Statuswaarden: De query gebruikt de standaard integerwaarden voor statussen in BMC Helix ITSM, bijvoorbeeld Submitted = 0 en In Review = 1. Je systeem kan aangepaste statussen of andere integerwaarden gebruiken. Controleer deze waarden in het formulier SYS:Status of in Developer Studio en pas zo nodig de WHERE-clausules in de query aan.
Prestaties: Rechtstreekse databasequery’s op grote tabellen zoals SRM_Request en de bijbehorende auditlogboeken kunnen veel systeembronnen vragen. Plan de extractie buiten piekuren om de invloed op de systeemprestaties te beperken.

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 dat Python 3.6 of hoger op je systeem is geïnstalleerd. Installeer de bibliotheek requests, die nodig is voor HTTP API-aanroepen, door pip install requests uit te voeren in je terminal of opdrachtprompt.
Verkrijg API-inloggegevens: Maak een serviceaccount aan in BMC Helix ITSM of vraag er een aan. Dit account heeft minimaal alleen-lezenrechten nodig voor het formulier SRM:Request en het bijbehorende auditlogformulier, dat vaak SRM:Request_AuditLog of iets vergelijkbaars heet. Noteer de gebruikersnaam, het wachtwoord en de basis-URL van je BMC Helix-instance, bijvoorbeeld https://[your-company].bmc.com.
Stel het Python-script in: Kopieer het meegeleverde Python-script naar een bestand, bijvoorbeeld extract_servicerequests.py. Bewerk het script en vul bovenaan de tijdelijke variabelen in: BASE_URL, USERNAME, PASSWORD en AUDIT_FORM_NAME. Pas de dictionary STATUS_ACTIVITY_MAP aan zodat deze overeenkomt met de statuswaarden in de workflow voor serviceaanvragen van je organisatie.
Stel de extractieperiode in: Pas de variabelen START_DATE en END_DATE in het script aan. Hiermee bepaal je de periode voor de extractie op basis van de indieningsdatum van de serviceaanvraag. Gebruik voor de eerste test een korte periode, bijvoorbeeld één dag.
Voer het script uit: Start het script vanuit je terminal met de opdracht python extract_servicerequests.py. Het script meldt zich eerst aan bij de API om een token op te halen.
Haal de eerste data op: Het script doorzoekt het formulier SRM:Request en haalt een lijst op van alle serviceaanvragen die binnen de opgegeven periode zijn aangemaakt. Zo verzamelt het de case-ID en vaste attributen, zoals prioriteit en servicetype.
Haal de gebeurtenisgeschiedenis op: Het script doorloopt elke serviceaanvraag-ID uit de vorige stap. Voor elke ID doet het een tweede API-aanroep naar het ingestelde auditlogformulier om de gedetailleerde geschiedenis van statuswijzigingen voor die aanvraag op te halen.
Zet de data om naar een event log: Het script koppelt elke statuswijziging uit het auditlog aan een standaardactiviteit met STATUS_ACTIVITY_MAP. Voor elke gekoppelde activiteit maakt het een rij met de ID van de serviceaanvraag, de activiteitsnaam en de timestamp van de wijziging.
Maak de gebeurtenis voor indiening aan: Het script maakt voor elke aanvraag ook de eerste activiteit 'Serviceaanvraag ingediend' aan, met de waarde van Submit Date uit het hoofdformulier SRM:Request.
Exporteer naar CSV: Nadat alle serviceaanvragen en hun geschiedenis zijn verwerkt, voegt het script de rijen samen in één lijst en schrijft het de data naar een CSV-bestand met de naam servicerequest_event_log.csv. Dit bestand is klaar om te uploaden naar een process mining-tool.

Configuratie

API-eindpunten: Het script gebruikt voornamelijk twee API-eindpunten. De authenticatie verloopt via api/jwt/login. De data wordt opgehaald uit arsys/v1/entry/SRM:Request voor de lijst met cases en uit arsys/v1/entry/[AUDIT_FORM_NAME] voor de gebeurtenisgeschiedenis.
Rechten voor het serviceaccount: Je hebt een speciaal serviceaccount nodig met leesrechten voor het formulier SRM:Request en het auditlogformulier van het systeem. Zo kun je de toegang beveiligen en acties herleiden.
Filter op periode: Het script filtert serviceaanvragen op basis van Submit Date. Haal de data bij voorkeur op in behapbare perioden, bijvoorbeeld 3 tot 6 maanden per keer, zodat het script betrouwbaar blijft werken.
Statussen koppelen aan activiteiten: De dictionary STATUS_ACTIVITY_MAP in het script vormt de kern van de omzetting. Stel deze zorgvuldig in op de aangepaste statussen van je organisatie en koppel ze aan de gewenste activiteitsnamen. Statussen die niet in de dictionary staan, worden genegeerd.
Auditlogformulier: Het script kan alleen gedetailleerde activiteiten ophalen als er een doorzoekbaar auditlog beschikbaar is. Zoek uit welk formulier in je omgeving de statusgeschiedenis van serviceaanvragen bevat en pas de variabele AUDIT_FORM_NAME daarop aan.
Paginering: Het script verwerkt API-paginering automatisch en haalt zo alle records op. De parameter limit in de API-aanroep staat op 1000 records per verzoek, als balans tussen prestaties en geheugengebruik.

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

Klaar om aan de slag te gaan?

Gebruik deze template om data te verzamelen en te beginnen met process mining voor het beheer van serviceaanvragen. Begin vandaag met het verbeteren van dit proces.

Terug naar de verbetergids Template downloaden

Verbeter de efficiëntie van het beheer van serviceaanvragen

Bereik 70% automatisering, voorkom trage afhandeling en help gebruikers sneller.

Start je gratis proefperiode

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

Datatemplate voor serviceverzoekbeheer

Datatemplate voor serviceverzoekbeheer

Attributen voor serviceverzoekbeheer

Activiteiten in het beheer van serviceaanvragen

Extractiegidsen

BMC Helix ITSM Smart Reporting voor serviceaanvragen

Stappen

Configuratie

a Voorbeeldquery sql

Rechtstreekse SQL-query op AR System-databasetabellen

Stappen

Configuratie

a Voorbeeldquery sql

Data-extractie met een Python-script via de BMC Helix REST API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Verbeter de efficiëntie van het beheer van serviceaanvragen

Datatemplate voor serviceverzoekbeheer

Datatemplate voor serviceverzoekbeheer

Attributen voor serviceverzoekbeheer

Activiteiten in het beheer van serviceaanvragen

Extractiegidsen

BMC Helix ITSM Smart Reporting voor serviceaanvragen

Stappen

Configuratie

a Voorbeeldquery sql

Rechtstreekse SQL-query op AR System-databasetabellen

Stappen

Configuratie

a Voorbeeldquery sql

Data-extractie met een Python-script via de BMC Helix REST API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Verbeter de efficiëntie van het beheer van serviceaanvragen

We gaan zorgvuldig om met je privacy