> Continu verbeteren van processen > Incidentbeheer > ServiceNow probleembeheer > Datatemplate

Datatemplate voor incidentbeheer

ServiceNow-probleembeheer

Attributen voor incidentbeheer(19) Activiteiten voor incidentbeheer(13) Extractiegidsen(2)

Datatemplate voor incidentbeheer

Deze template helpt je de data te verzamelen die nodig is om het incidentbeheer te analyseren en te verbeteren. Je vindt er de belangrijkste datavelden om op te nemen, de activiteiten om bij te houden en praktische uitleg over het ophalen van deze informatie uit je bronsysteem. Gebruik deze bron om een bruikbaar event log op te bouwen voor procesanalyse en verbeteringen.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om bij te houden
Uitleg over data-extractie voor ServiceNow-probleembeheer

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

Template downloaden

Attributen voor incidentbeheer

Dit zijn de aanbevolen datavelden voor je event log, zodat je het incidentbeheer goed kunt analyseren.

5 Verplicht 4 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de specifieke gebeurtenis of taak die op een bepaald moment in de levenscyclus van het incident plaatsvond.
Beschrijving De activiteitsnaam beschrijft een specifieke stap of statuswijziging in het incidentbeheerproces, zoals 'Incident aangemaakt', 'Agent toegewezen' of 'Incident gesloten'. Deze data is meestal afgeleid van wijzigingen in belangrijke incidentvelden, zoals 'State' of 'Assignment Group', of van specifieke logvermeldingen. Dit attribuut is belangrijk voor het opbouwen van de proceskaart. Het bepaalt de knooppunten in de procesgrafiek, zodat analisten de incidentstroom kunnen visualiseren, veelvoorkomende routes kunnen herkennen, bottlenecks tussen activiteiten kunnen opsporen en procesvarianten kunnen analyseren. De mate van detail en de nauwkeurigheid van de activiteitsnamen hebben rechtstreeks invloed op de kwaliteit van de procesanalyse. Waarom dit belangrijk is Dit bepaalt de stappen op de proceskaart, de basis voor alle process mining-analyses en visualisaties. Waar vind je dit? Dit is een afgeleid attribuut dat meestal wordt aangemaakt door de datatransformatielogica op basis van wijzigingen in velden zoals state, assignment_group en assigned_to in de tabellen sys_audit of incident. Voorbeelden Incident aangemaaktToewijzingsgroep gewijzigdOplossing voorgesteldIncident gesloten
	Gebeurtenistijd EventTime	De exacte timestamp waarop de activiteit plaatsvond.
Beschrijving Gebeurtenistijd, ook wel timestamp genoemd, legt de exacte datum en tijd vast waarop een activiteit is afgerond of een statuswijziging heeft plaatsgevonden. In ServiceNow wordt dit meestal bijgehouden in het veld sys_updated_on voor elke wijziging in het auditspoor. Dit attribuut is nodig om gebeurtenissen in de juiste volgorde te zetten en tijdsanalyses uit te voeren. Je gebruikt het om doorlooptijden, wachttijden en de tijd tussen activiteiten te berekenen. Die gegevens helpen bottlenecks op te sporen, prestaties ten opzichte van SLA’s te meten en de procesefficiëntie te begrijpen. Nauwkeurige timestamps zijn essentieel voor betrouwbare tijdsmetingen. Waarom dit belangrijk is Deze timestamp zet alle activiteiten chronologisch op een rij en maakt berekeningen mogelijk van tijdsmetingen, zoals doorlooptijden en bottlenecks. Waar vind je dit? ServiceNow-tabel sys_audit, veld sys_created_on, of het veld sys_updated_on uit de tabel incident voor de laatste status. Voorbeelden 2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
	Incident-ID IncidentId	De unieke identificatiecode van elk incidentrecord, die als primaire sleutel dient om de volledige levenscyclus te volgen.
Beschrijving Het Incident-ID is het unieke referentienummer dat in ServiceNow aan elk gemeld incident wordt toegekend. Het is de centrale case-identificatie die alle bijbehorende activiteiten, updates en communicatie met elkaar verbindt, vanaf het aanmaken van een incident tot de afsluiting ervan. Dit ID is onmisbaar voor process mining. De tool gebruikt het om de gebeurtenissen per case in de juiste volgorde samen te voegen. Zo vormt het de basis voor het ontdekken van proceskaarten, het analyseren van varianten en het berekenen van doorlooptijden van begin tot eind. Zonder een uniek Incident-ID per case kun je het verloop van een incident tijdens het oplossingsproces niet volgen. Waarom dit belangrijk is Dit is het unieke Case-ID dat alle gebeurtenissen in de levenscyclus van een incident met elkaar verbindt en analyse van het proces van begin tot eind mogelijk maakt. Waar vind je dit? ServiceNow-tabel incident, veld number. Voorbeelden INC0010001INC0010045INC0010239
	Bronsysteem SourceSystem	Het systeem waaruit deze data is geëxtraheerd.
Beschrijving Dit attribuut geeft aan waar de incidentdata vandaan komt, in dit geval ServiceNow Problem Management. Meestal wordt het als vaste waarde toegevoegd tijdens de data-extractie en -transformatie. Als je data uit meerdere systemen combineert voor analyse, is dit veld belangrijk om de herkomst van data te volgen en bronnen van elkaar te onderscheiden. Zo kun je metrieken en processen in de juiste context analyseren en processen uit verschillende bronsystemen vergelijken. Waarom dit belangrijk is Dit geeft belangrijke context over de herkomst van data, zodat je de herkomst kunt volgen en data uit meerdere systemen goed kunt interpreteren. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie wordt toegevoegd. Voorbeelden ServiceNow-probleembeheerServiceNow
	Laatste data-update LastDataUpdate	De timestamp waarop de data voor dit record voor het laatst vanuit het bronsysteem is bijgewerkt.
Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie of update vanuit ServiceNow. Het is een metadataveld dat aangeeft hoe actueel de geanalyseerde data is, geen gebeurtenis in het proces zelf. Zo weet je hoe recent de analyse is. Dat is belangrijk voor operationele dashboards en beslissingen op basis van recente gebeurtenissen. Het helpt ook om duidelijk te maken hoe relevant en actueel de data is. Waarom dit belangrijk is Dit laat zien hoe actueel de data is, wat belangrijk is voor de relevantie en nauwkeurigheid van de analyse. Waar vind je dit? Deze timestamp wordt tijdens het laden van de data aangemaakt en ingevuld door de data-extractietool of het extractieproces. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Incidentstatus IncidentState	De huidige status van het incident in de levenscyclus.
Beschrijving De incidentstatus geeft de huidige fase van een incident aan, zoals 'New', 'In Progress', 'On Hold' of 'Resolved'. Statuswijzigingen zijn vaak de belangrijkste bron voor het genereren van activiteiten in het event log voor process mining. De tijd in elke status analyseren is een goede manier om bottlenecks op te sporen. Een lange periode in de status 'On Hold' kan bijvoorbeeld wijzen op afhankelijkheden van externe partijen of gebruikers. De volgorde van statuswijzigingen vormt ook de basis van de proceskaart en laat zien hoe incidenten naar een oplossing toewerken. Waarom dit belangrijk is Dit houdt de voortgang van het incident bij en is belangrijk om de tijd in verschillende fasen te analyseren en bottlenecks in het proces op te sporen. Waar vind je dit? ServiceNow-tabel incident, veld incident_state of state. Voorbeelden NieuwIn behandelingWachten op informatie van gebruikerOpgelostGesloten
	Prioriteit Priority	De prioriteit van het incident, die bepaalt hoe snel er moet worden gereageerd.
Beschrijving Prioriteit is een belangrijk veld in ServiceNow dat bepaalt in welke volgorde en hoe snel een incident wordt afgehandeld. De prioriteit wordt meestal afgeleid van de impact en urgentie van het incident en heeft rechtstreeks invloed op de SLA-doelen. Dit attribuut is belangrijk voor segmentatie en prestatieanalyse. Het dashboard 'Overzicht SLA-naleving' gebruikt Prioriteit om te beoordelen of incidenten met een hoge prioriteit binnen de afgesproken tijd worden opgelost. Door doorlooptijden per prioriteit te analyseren, kun je controleren of kritieke incidenten inderdaad sneller worden afgehandeld dan minder urgente incidenten. Dit is een belangrijke dimensie voor vrijwel elke KPI en elk dashboard. Waarom dit belangrijk is Hiermee kun je incidenten indelen naar zakelijk belang. Dat is belangrijk om SLA-naleving te volgen en mensen en middelen in te zetten. Waar vind je dit? ServiceNow-tabel incident, veld priority. Voorbeelden 1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
	Toegewezen aan AssignedTo	De gebruiker of agent die op dit moment aan het incident werkt.
Beschrijving Dit attribuut geeft aan welke supportagent op een bepaald moment verantwoordelijk is voor het incident. Deze informatie is belangrijk om de verdeling van de werkdruk, de prestaties van agents en overdrachten tussen personen te begrijpen. Met 'Toegewezen aan' kun je in analyses de verdeling van werk bekijken en zien welke agents overbelast zijn. Het wordt ook gebruikt in het dashboard Overdrachten en herverdelingen om bij te houden hoe vaak een incident van verantwoordelijke wisselt. Dat kan wijzen op inefficiëntie of ontbrekende kennis. Door oplostijden per agent te analyseren, kun je ook zien wie goed presteert en wie extra training nodig heeft. Waarom dit belangrijk is Hiermee kun je de werkdruk en prestaties van agents analyseren, net als overdrachten tussen personen. Dat helpt om de inzet van mensen te beoordelen. Waar vind je dit? ServiceNow-tabel incident, veld assigned_to. Voorbeelden Beth AnglinDavid LooHoward Johnson
	Toewijzingsgroep AssignmentGroup	Het supportteam of de groep die verantwoordelijk is voor de afhandeling van het incident.
Beschrijving De toewijzingsgroep is het team van agents dat het incident moet oplossen. Incidenten worden vaak tussen groepen gerouteerd, bijvoorbeeld van een eerstelijns helpdesk naar een gespecialiseerd netwerkteam. Dit attribuut is belangrijk om overdrachten tussen teams te analyseren en terugkerende bottlenecks op te sporen. Het dashboard 'Overdrachten en herverdelingen' gebruikt deze data om te laten zien welke teams vaak bij overdrachten betrokken zijn. Je kunt er ook prestaties van supportgroepen mee vergelijken en zien waar de kennis voor incidentoplossing binnen de organisatie zit. Waarom dit belangrijk is Dit houdt bij welk team verantwoordelijk is en maakt analyse mogelijk van teamprestaties, werkdruk en overdrachten tussen groepen. Waar vind je dit? ServiceNow-tabel incident, veld assignment_group. Voorbeelden ServicedeskNetwerksupportDatabasebeheerders
	Aantal herindelingen ReassignmentCount	Hoe vaak het incident aan een andere groep of medewerker is toegewezen.
Beschrijving Dit veld registreert hoe vaak een incident tussen verschillende toewijzingsgroepen is overgedragen. Het is een directe maat voor wrijving in het proces en wordt vaak gebruikt als prestatie-indicator. Dit attribuut vormt de basis voor het dashboard ‘Overdrachten en herindelingen’ en de KPI ‘Gemiddeld aantal overdrachten per incident’. Veel herindelingen kunnen wijzen op een verkeerde eerste toewijzing, ontbrekende vaardigheden binnen een supportniveau of onduidelijk proceseigenaarschap. Het aantal herindelingen terugdringen is een veelvoorkomend verbeterdoel en leidt meestal tot kortere oplostijden. Waarom dit belangrijk is Dit meet rechtstreeks hoeveel overdrachten er in het proces plaatsvinden. Veel overdrachten kunnen wijzen op inefficiëntie, een verkeerde toewijzing en kansen voor verbetering. Waar vind je dit? De incidenttabel van ServiceNow, veld reassignment_count. Voorbeelden 0135
	Categorie Category	De algemene classificatie van het incident, zoals Hardware, Software of Netwerk.
Beschrijving De categorie geeft een algemene indeling van het soort incident. Vaak helpt deze, samen met een subcategorie, om het incident naar het juiste supportteam te routeren. De categorie wordt ook gebruikt voor rapportages en trendanalyses. Bij process mining is dit attribuut belangrijk voor de dashboards 'Nauwkeurigheid van incidentcategorisering' en 'Terugkerende incidenten'. Door incidenten te analyseren waarvan de categorie tijdens het proces verandert, kunnen organisaties problemen bij de eerste beoordeling opsporen. Als je de proceskaart op categorie filtert, zie je ook of bepaalde soorten incidenten een andere oplossingsroute volgen of met specifieke bottlenecks te maken hebben. Waarom dit belangrijk is Hiermee kun je incidenttypen analyseren en de nauwkeurigheid van categorisering meten. De categorie is ook belangrijk voor routering en trendanalyse. Waar vind je dit? ServiceNow-tabel incident, veld category. Voorbeelden HardwareSoftwareNetwerkDatabase
	Configuratie-item ConfigurationItem	Het specifieke IT-onderdeel, de service of het bedrijfsmiddel dat door het incident is getroffen.
Beschrijving Het configuratie-item (CI) is het bedrijfsmiddel uit de Configuration Management Database (CMDB) dat door het incident is getroffen. Dit kan bijvoorbeeld een server, applicatie, laptop of netwerkapparaat zijn. Door incidenten per CI te analyseren, zie je welke bedrijfsmiddelen of services vaak problemen geven. Zo wordt duidelijk welke onderdelen van de IT-infrastructuur de meeste incidenten veroorzaken. Dat kan helpen bij beslissingen over upgrades of vervanging. In process mining kun je op CI filteren om te zien of incidenten met kritieke applicaties anders of efficiënter worden afgehandeld. Waarom dit belangrijk is Dit veld geeft aan welk bedrijfsmiddel is getroffen. Zo zie je welke onderdelen van de IT-infrastructuur problemen veroorzaken en waar verbeteringen nodig zijn. Waar vind je dit? De incidenttabel van ServiceNow, veld cmdb_ci. Voorbeelden SAP ERP-productieOracle-databaseserver 05E-mailservice
	Ernst Severity	De mate waarin het incident de bedrijfsvoering beïnvloedt.
Beschrijving Ernst geeft aan hoeveel invloed een incident heeft op de bedrijfsvoering. Samen met urgentie wordt deze waarde vaak gebruikt om de prioriteit van het incident automatisch te bepalen. Bij analyses is ernst een belangrijke dimensie voor het dashboard ‘Overzicht SLA-naleving’. Zo zie je of de serviceniveaus worden gehaald voor incidenten met de grootste impact. Dit geeft een beeld vanuit zakelijk perspectief, naast het operationele beeld op basis van prioriteit. Waarom dit belangrijk is Dit veld meet de impact van een incident op de bedrijfsvoering. Zo kun je werk prioriteren en de afhandeling van kritieke incidenten analyseren. Waar vind je dit? De incidenttabel van ServiceNow, veld severity. Voorbeelden 1 - Hoog2 - Gemiddeld3 - Laag
	Melder CallerId	De gebruiker die het incident als eerste heeft gemeld.
Beschrijving De melder is de eindgebruiker of klant die door het incident wordt getroffen en het heeft gemeld. Deze informatie geeft context over wie last heeft van serviceonderbrekingen. De melder staat niet altijd centraal in het procesverloop. Toch kan een analyse per melder laten zien of bepaalde personen of afdelingen vaker door problemen worden getroffen. Dat kan wijzen op behoefte aan training of lokale problemen met de IT-omgeving. Ook kun je zo rechtstreeks contact opnemen voor een tevredenheidsonderzoek of om informatie te delen. Waarom dit belangrijk is Dit veld geeft aan welke gebruiker is getroffen. Je kunt incidenten per afdeling of persoon analyseren en ziet wie je moet informeren. Waar vind je dit? De incidenttabel van ServiceNow, veld caller_id. Voorbeelden Abel TuterCarolina PashDon Goodliffe
	Oplossingscode ResolutionCode	Een code die aangeeft hoe het incident uiteindelijk is opgelost.
Beschrijving De oplossingscode geeft aan welke oplossing is toegepast. Zo kan het incident zijn opgelost door een gebruiker, door een bekende fout of met een tijdelijke oplossing. Meestal vult de medewerker dit veld in bij het sluiten van het incident. Dit attribuut is rechtstreeks van belang voor het dashboard ‘Effectiviteit van oplossingstypen’. Je kunt ermee analyseren hoeveel incidenten zijn gesloten met een permanente oplossing en hoeveel met een tijdelijke oplossing. Dat is een belangrijke indicator voor de servicekwaliteit en stabiliteit op de lange termijn. Een hoog aantal tijdelijke oplossingen kan erop wijzen dat onderliggende problemen niet goed worden aangepakt. Waarom dit belangrijk is Dit veld maakt duidelijk hoe het incident is opgelost. Zo kun je permanente oplossingen vergelijken met tijdelijke oplossingen en oorzaken analyseren. Waar vind je dit? De incidenttabel van ServiceNow, veld close_code of een aangepast veld voor de oplossingscode. Voorbeelden Opgelost (tijdelijke oplossing)Opgelost (permanent)Niet opgelost (geannuleerd door gebruiker)Bekende fout
	Opnieuw geopend IsReopened	Een aanduiding die laat zien of een incident na de oplossing opnieuw is geopend.
Beschrijving Deze booleaanse aanduiding krijgt de waarde true als de status van een incident na ‘Resolved’ of ‘Closed’ weer actief wordt, bijvoorbeeld ‘In Progress’. Dit is meestal te herkennen aan de activiteit ‘Incident Reopened’ in het event log. Opnieuw geopende incidenten wijzen vaak op een onvolledige of ineffectieve oplossing. Door deze cases te analyseren, zie je of incidenten te vroeg zijn gesloten of dat terugkerende problemen niet meteen goed zijn opgelost. Een hoog percentage heropeningen kan de gebruikerstevredenheid en productiviteit van teams verlagen. Daarom is dit een belangrijke kwaliteitsmaatstaf. Waarom dit belangrijk is Deze aanduiding laat zien waar de oplossing tekortschiet en welke incidenten na de vermeende oplossing extra werk vereisten. Waar vind je dit? Berekend door de activiteitenreeks van elk incident te controleren op een status ‘open’ na een status ‘resolved’. Voorbeelden truefalse
	Probleem-ID ProblemId	De identificatiecode van het bijbehorende probleemrecord, als het incident deel uitmaakt van een groter probleem.
Beschrijving Met de probleem-ID koppel je een incident aan het bijbehorende record in de module Probleembeheer. Dat gebeurt wanneer een incident een symptoom blijkt van een groter onderliggend probleem dat meerdere gebruikers of services treft. Deze koppeling is belangrijk voor het dashboard ‘Terugkerende incidenten’ en de KPI ‘Percentage terugkerende incidenten’. Analisten kunnen incidenten met dezelfde oorzaak groeperen, de volledige impact van een probleem meten en volgen hoe effectief het probleem wordt opgelost. Veel incidenten die aan problemen zijn gekoppeld, wijzen op een reactieve supportomgeving. Waarom dit belangrijk is Dit veld koppelt incidenten aan een onderliggende oorzaak. Dat is belangrijk om terugkerende problemen te analyseren en de impact van probleembeheer te meten. Waar vind je dit? De incidenttabel van ServiceNow, veld problem_id. Voorbeelden PRB0040001PRB0040015PRB0040102
	SLA overschreden IsSlaBreached	Een aanduiding die aangeeft of de oplossing van het incident na de SLA-deadline kwam.
Beschrijving Dit berekende booleaanse attribuut geeft aan of een incident de Service Level Agreement heeft overschreden. De waarde wordt bepaald door de werkelijke oplostimestamp te vergelijken met de ‘SLA-deadline’. Valt de oplostijd na de deadline, dan krijgt het veld de waarde true. Dit attribuut vormt de basis voor het dashboard ‘Overzicht SLA-naleving’ en de bijbehorende KPI’s. Een ingewikkelde tijdsvergelijking wordt zo een eenvoudige dimensie met de waarde true of false. Je kunt alle incidenten met een overschrijding filteren en hun gemeenschappelijke kenmerken analyseren, zoals categorie, toewijzingsgroep of prioriteit. Waarom dit belangrijk is Dit maakt het eenvoudiger om SLA-naleving te analyseren. Je kunt incidenten die hun deadline niet hebben gehaald makkelijk filteren en verder onderzoeken. Waar vind je dit? Berekend door de timestamp ‘Resolved At’ te vergelijken met de timestamp ‘SlaDueDate’. (Resolved At > SlaDueDate). Voorbeelden truefalse
	SLA-deadline SlaDueDate	De datum en tijd waarop het incident volgens de SLA opgelost moet zijn.
Beschrijving De SLA-deadline is een berekende timestamp die aangeeft wanneer een incident uiterlijk moet zijn opgelost. De deadline wordt bepaald door de Service Level Agreement (SLA) die bij de kenmerken van het incident hoort, zoals de prioriteit. Dit attribuut is belangrijk voor het dashboard ‘Overzicht SLA-naleving’ en de KPI ‘Percentage SLA-overschrijdingen bij kritieke incidenten’. De deadline is het referentiepunt voor de vergelijking met de werkelijke oplostijd. Door incidenten te analyseren die hun SLA-deadline naderen, kun je tijdig escaleren en prioriteiten aanpassen. Waarom dit belangrijk is Dit veld bepaalt de oplosdeadline. Zo kun je SLA-naleving meten en zien welke incidenten hun deadline dreigen te overschrijden. Waar vind je dit? Deze waarde staat meestal in de tabel task_sla, die is gekoppeld aan de incidenttabel. Het relevante timestamp-veld is planned_end_time. Voorbeelden 2023-05-20T17:00:00Z2023-06-01T09:00:00Z

Verplicht Aanbevolen Optioneel

Activiteiten voor incidentbeheer

Dit zijn de belangrijke processtappen en mijlpalen om in je event log vast te leggen voor een nauwkeurige procesanalyse en optimalisatie.

6 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Incident aangemaakt	Dit markeert het begin van de levenscyclus van een incident: het moment waarop een nieuw incident officieel in ServiceNow wordt geregistreerd. De gebeurtenis wordt vastgelegd met de aanmaaktimestamp van het incidentrecord.
Waarom dit belangrijk is Dit is de primaire startgebeurtenis van het proces. De tijd tussen deze activiteit en de oplossing is belangrijk om de totale doorlooptijd en SLA-naleving te meten. Waar vind je dit? De timestamp 'sys_created_on' in de tabel 'incident' is de expliciete eventtimestamp voor deze activiteit. Vastleggen Gebruik de timestamp 'sys_created_on' uit het incidentrecord. Gebeurtenistype explicit
	Incident gesloten	Dit is de laatste activiteit in de levenscyclus. Het incident is volledig opgelost en bevestigd, en er is geen verdere actie nodig. De gebeurtenis wordt expliciet vastgelegd met de afsluitingstimestamp.
Waarom dit belangrijk is Als definitieve eindgebeurtenis is deze activiteit belangrijk voor het berekenen van de totale levensduur van een incident en het analyseren van de tijd die nodig is voor de verwerking na de oplossing. Waar vind je dit? De timestamp 'closed_at' in de tabel 'incident' is de expliciete eventtimestamp. Deze wordt meestal ingesteld wanneer het veld 'state' verandert in 'Closed'. Vastleggen Gebruik de timestamp 'closed_at' uit het incidentrecord. Gebeurtenistype explicit
	Incident toegewezen aan groep	Deze activiteit vindt plaats wanneer een incident wordt toegewezen aan een specifieke supportgroep. Dit is een belangrijke stap in de routering en wordt vastgelegd door wijzigingen in het veld voor de toewijzingsgroep te volgen.
Waarom dit belangrijk is Door toewijzingen te volgen, kun je overdrachten en wachttijden per groep analyseren en inefficiënte routering of bottlenecks opsporen. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door te volgen wanneer het veld 'assignment_group' in de tabel 'incident' wordt ingevuld of gewijzigd. Vastleggen Gebruik de timestamp uit het auditlog van wijzigingen in het veld 'assignment_group'. Gebeurtenistype inferred
	Oplossing voorgesteld	Dit markeert het moment waarop een supportagent een oplossing heeft doorgevoerd en de status van het incident op 'Resolved' heeft gezet. Dit is een belangrijke mijlpaal vóór de definitieve afsluiting.
Waarom dit belangrijk is Deze activiteit markeert het einde van het actieve werk en het begin van de bevestigingsfase. De tijd tussen deze activiteit en 'Incident gesloten' kan vertraging in de bevestiging of controle door de gebruiker zichtbaar maken. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' wanneer het veld 'state' in de tabel 'incident' verandert in 'Resolved'. De timestamp 'resolved_at' wordt vaak op dat moment ingevuld. Vastleggen Gebruik de timestamp waarop het veld 'state' de waarde 'Resolved' krijgt, of de timestamp 'resolved_at'. Gebeurtenistype inferred
	Toewijzingsgroep gewijzigd	Dit is een overdracht waarbij een incident van de ene supportgroep naar de andere gaat. Dit wordt vastgelegd door wijzigingen in het veld 'assignment_group' te volgen nadat het voor het eerst is ingevuld.
Waarom dit belangrijk is Regelmatige herverdelingen kunnen wijzen op een verkeerde eerste routering, een complex proces of ontbrekende kennis. Deze activiteit is belangrijk voor het meten van de KPI 'Gemiddeld aantal overdrachten per incident'. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door wijzigingen in het veld 'assignment_group' na de eerste toewijzing te volgen. Vastleggen Bepaal elke wijziging van het veld 'assignment_group' met timestamp in het auditlog. Gebeurtenistype inferred
	Werk gestart	Dit geeft aan dat een agent actief onderzoek doet naar het incident of eraan werkt. Meestal wordt dit afgeleid uit een statuswijziging van 'New' of 'Assigned' naar een actieve status, zoals 'In Progress'.
Waarom dit belangrijk is Deze mijlpaal markeert het einde van de eerste wachttijd en het begin van de actieve oplossing. De tijd tot de start van het werk meten is belangrijk voor bottleneckanalyse. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door vast te stellen wanneer het veld 'state' in de tabel 'incident' verandert in een waarde die actief werk aangeeft, zoals 'In Progress'. Vastleggen Bepaal de timestamp waarop het veld 'state' verandert in 'In Progress' of een vergelijkbare waarde. Gebeurtenistype inferred
	Incident gecategoriseerd	Dit is de eerste classificatie van het incident, waarbij velden zoals Category, Subcategory en Priority worden ingevuld. Deze gebeurtenis wordt meestal afgeleid uit het auditspoor, wanneer deze velden kort na het aanmaken voor het eerst worden ingevuld of bijgewerkt.
Waarom dit belangrijk is Een juiste categorisering is belangrijk voor een goede routering en prioritering. Door deze activiteit te volgen, kun je zien hoe vaak incidenten opnieuw worden gecategoriseerd en wat het effect daarvan is op de oplostijd. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door de eerste wijziging van velden zoals 'category', 'subcategory' of 'priority' voor een incident te vinden. Vastleggen Bepaal de timestamp van de eerste wijziging van classificatievelden in het auditlog. Gebeurtenistype inferred
	Incident geëscaleerd	Dit gebeurt wanneer de prioriteit of ernst van een incident wordt verhoogd, vaak omdat een snellere reactie of andere bronnen nodig zijn. Dit wordt afgeleid uit een verhoging van de waarde in het veld 'priority'.
Waarom dit belangrijk is Een escalatie kan erop wijzen dat een incident ernstiger is dan eerst gedacht, of dat een SLA-overschrijding dreigt. Door deze gebeurtenissen te analyseren, krijg je zicht op uitzonderingen in het proces. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door een wijziging van het veld 'priority' naar een hogere urgentiewaarde vast te stellen. Vastleggen Detecteer wanneer de waarde van het veld 'priority' stijgt, bijvoorbeeld van '3 - Gemiddeld' naar '2 - Hoog'. Gebeurtenistype inferred
	Incident gekoppeld aan probleem	Deze activiteit vindt plaats wanneer een incident officieel aan een probleemrecord wordt gekoppeld. Dat geeft aan dat het incident deel uitmaakt van een groter onderliggend probleem. Dit wordt afgeleid wanneer het veld 'problem_id' in het incidentrecord wordt ingevuld.
Waarom dit belangrijk is Een incident aan een probleem koppelen is een belangrijke stap van reactief incidentbeheer naar proactieve oorzaakanalyse. Deze koppeling ondersteunt het dashboard 'Terugkerende incidenten'. Waar vind je dit? Afgeleid door vast te stellen wanneer het verwijzingsveld 'problem_id' in de tabel 'incident' een waarde krijgt. Vastleggen Bepaal de timestamp in het auditlog waarop het veld 'problem_id' wordt ingevuld. Gebeurtenistype inferred
	Incident heropend	Dit gebeurt wanneer een gebruiker meldt dat het probleem nog bestaat nadat het als opgelost is gemarkeerd. Dit wordt afgeleid wanneer de incidentstatus van 'Resolved' teruggaat naar een actieve status, zoals 'In Progress'.
Waarom dit belangrijk is Heropende incidenten wijzen op mislukte oplossingen en leiden tot herstelwerk. Door deze activiteit te volgen, kun je de kwaliteit van oplossingen en het percentage oplossingen bij de eerste poging meten. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door een wijziging van het veld 'state' van 'Resolved' terug naar een actieve status, zoals 'In Progress' of 'Assigned', vast te stellen. Vastleggen Bepaal de timestamp waarop 'state' verandert van 'Resolved' naar een actieve waarde. Gebeurtenistype inferred
	Incident toegewezen aan agent	Dit is het moment waarop een specifieke agent binnen een supportgroep de verantwoordelijkheid voor het incident op zich neemt. Dit wordt vastgelegd door wijzigingen in het veld 'assigned_to' te volgen.
Waarom dit belangrijk is Zo krijg je gedetailleerd zicht op de werkdruk van agents en de oplossing bij het eerste contact. Je ziet ook hoelang een incident na toewijzing aan een groep wacht voordat iemand ermee aan de slag gaat. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door te volgen wanneer het veld 'assigned_to' in de tabel 'incident' wordt ingevuld of gewijzigd. Vastleggen Gebruik de timestamp uit het auditlog van wijzigingen in het veld 'assigned_to'. Gebeurtenistype inferred
	Supportopmerking toegevoegd	Een supportagent voegt een werkaantekening of een voor de gebruiker zichtbare opmerking toe. Dit is een expliciete gebeurtenis in de activiteitenstroom van het incident.
Waarom dit belangrijk is Deze activiteit houdt de communicatie en onderzoeksinspanningen van het supportteam bij. De frequentie en timing van opmerkingen geven inzicht in het onderzoeksproces. Waar vind je dit? Vastgelegd in de tabel 'sys_journal_field', waarin vermeldingen voor de velden 'work_notes' en 'comments' in de tabel 'incident' worden bijgehouden. Vastleggen Gebruik de aanmaaktimestamp van journaalvermeldingen waarbij het element 'work_notes' of 'comments' is. Gebeurtenistype explicit
	Wachten op bevestiging van gebruiker	Het incident heeft een wachtstatus en wacht op bevestiging van de gebruiker dat de voorgestelde oplossing werkt. Dit wordt meestal afgeleid uit een specifieke status, zoals 'Awaiting User Info', nadat het incident is opgelost.
Waarom dit belangrijk is Deze status kan een aanzienlijke bottleneck vormen als gebruikers traag reageren. Door de tijd in deze activiteit te meten, kun je communicatieproblemen en mogelijkheden voor automatische afsluiting opsporen. Waar vind je dit? Afgeleid uit de tabel 'sys_audit' door na de oplossing een wijziging naar een specifieke wachtstatus vast te stellen. De statusnaam kan aangepast zijn, bijvoorbeeld 'Awaiting Caller'. Vastleggen Bepaal de timestamp waarop 'state' verandert in een waarde die aangeeft dat er op informatie van de gebruiker wordt gewacht. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit ServiceNow-probleembeheer

Stappen

Toegang tot ServiceNow instellen: Vraag inloggegevens aan voor een serviceaccount in ServiceNow. Dit account moet leesrechten (ACL’s) hebben voor de incidenttabel, de tabel sys_audit en alle vereiste velden, waaronder sys_id, number, sys_created_on, resolved_at, closed_at, assignment_group, assigned_to, priority, incident_state, state, category, subcategory, problem_id, comments en work_notes.
Node.js-omgeving configureren: Zorg dat Node.js is geïnstalleerd op de computer waarop het extractiescript wordt uitgevoerd. Installeer de axios-bibliotheek voor HTTP-verzoeken met de opdracht npm install axios in je terminal.
Het extractiescript voorbereiden: Kopieer de opgegeven JavaScript-code naar een bestand, bijvoorbeeld extract_incidents.js. Vul bovenaan het script de URL van je ServiceNow-instantie en de gebruikersnaam en het wachtwoord in.
Extractieparameters instellen: Pas de variabelen startDate en endDate in het script aan om de periode te bepalen waaruit je incidenten wilt ophalen. Gebruik bij de eerste uitvoering bij voorkeur een korte periode, bijvoorbeeld één week, om de resultaten te controleren.
Het script uitvoeren: Voer in je terminal de opdracht node extract_incidents.js uit. Het script haalt incidentdata en de bijbehorende auditlogs op via de ServiceNow API.
De voortgang volgen: Het script toont in de console hoeveel incidenten zijn verwerkt. Bij grote datasets kan dit veel tijd kosten, omdat er veel API-aanroepen nodig zijn.
API-antwoorden verwerken: Het script doorloopt elk incident. Voor elk incident bevraagt het de tabel sys_audit om de volledige wijzigingsgeschiedenis op te halen. Vervolgens zoekt het in die geschiedenis naar de 13 vereiste activiteiten en voegt het timestamps toe.
Afgeleide activiteiten verwerken: Het script leidt activiteiten af uit wijzigingen in velden. Zo wordt ‘Incident Escalated’ aangemaakt wanneer de nieuwe waarde van het veld priority lager is dan de oude waarde, wat op een hogere prioriteit wijst. ‘Work Started’ wordt herkend aan de eerste statuswijziging naar ‘In Progress’.
Het event log opbouwen: Zodra activiteiten zijn gevonden, zet het script ze om in records voor het event log. Elk record bevat de vereiste kolommen, zoals IncidentId, ActivityName en EventTime.
De uitvoer opslaan: Na afloop slaat het script het event log op als JSON-bestand met de naam servicenow_incident_event_log.json in dezelfde map. Dit bestand bevat een lijst met alle opgehaalde gebeurtenissen.
Omzetten naar CSV: Voor upload naar ProcessMind moet je de JSON-uitvoer mogelijk omzetten naar een CSV-bestand. Gebruik een standaarddatatool of een eenvoudig script om de JSON-lijst om te zetten naar een tabel in CSV-formaat. Zorg dat de kolomkoppen overeenkomen met de vereiste attributen.

Configuratie

API-eindpunten: Het script gebruikt twee belangrijke ServiceNow Table API-eindpunten:
- https://[Your ServiceNow Instance].service-now.com/api/now/table/incident
- https://[Your ServiceNow Instance].service-now.com/api/now/table/sys_audit
Authenticatie: Het opgegeven script gebruikt Basic Authentication (gebruikersnaam en wachtwoord). Controleer of de inloggegevens van het serviceaccount kloppen en of het account actief is.
Filteren op periode: De query filtert op de aanmaakdatum van incidenten (sys_created_on). Je stelt de periode in met de variabelen startDate en endDate in het script. Voor een bruikbare analyse wordt aangeraden 3 tot 6 maanden aan data op te halen. Begin voor tests met een kortere periode.
Belangrijke queryparameters:
- sysparm_query: Hiermee filter je records. Het script maakt een gecodeerde querystring om incidenten op aanmaakdatum te filteren.
- sysparm_fields: Hiermee geef je aan welke kolommen je wilt ophalen. Zo wordt de API-payload kleiner en presteert de API beter.
- sysparm_limit: Hiermee stel je paginering in door het aantal records per verzoek op te geven. Het script gebruikt een limiet van 1000, een gangbare instelling.
- sysparm_offset: Hiermee haal je, in combinatie met sysparm_limit, volgende pagina’s met data op.
Aandachtspunten voor de prestaties: De tabel sys_audit voor elk incident opvragen kost veel systeembronnen. Voer de extractie bij grote ServiceNow-instanties bij voorkeur buiten piekuren uit. Het script verwerkt incidenten één voor één om de API niet te zwaar te belasten. Daardoor kan de totale uitvoering wel langer duren.
Vereisten: Voor het uitvoeren van het script is een Node.js-omgeving nodig. De gebruiker of het serviceaccount dat de extractie uitvoert, moet leesrechten (ACL’s) hebben voor de tabellen incident en sys_audit.

Voorbeeldquery javascript

const axios = require('axios');
const fs = require('fs');

// --- Configuration ---
const INSTANCE_URL = 'https://[your-instance].service-now.com';
const USERNAME = '[your-username]';
const PASSWORD = '[your-password]';

// Define the date range for the extraction
const startDate = '2023-01-01 00:00:00';
const endDate = '2023-03-31 23:59:59';

const BATCH_SIZE = 1000; // Records per API call for incidents
const SOURCE_SYSTEM = 'ServiceNow';

// --- Main Extraction Logic ---
async function extractIncidentData() {
    const auth = { username: USERNAME, password: PASSWORD };
    const allEvents = [];
    let offset = 0;
    let hasMoreRecords = true;

    console.log(`Starting extraction for incidents created between ${startDate} and ${endDate}...`);

    while (hasMoreRecords) {
        try {
            // 1. Fetch a batch of incidents
            const incidentQuery = `sys_created_on>=${startDate}^sys_created_on<=${endDate}`;
            const incidentFields = [
                'sys_id', 'number', 'sys_created_on', 'resolved_at', 'closed_at',
                'assigned_to', 'assignment_group', 'priority', 'incident_state',
                'state', 'sys_updated_on'
            ].join(',');

            console.log(`Fetching incidents, offset: ${offset}...`);
            const incidentResponse = await axios.get(`${INSTANCE_URL}/api/now/table/incident`, {
                auth,
                params: {
                    sysparm_query: incidentQuery,
                    sysparm_fields: incidentFields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset
                }
            });

            const incidents = incidentResponse.data.result;
            if (incidents.length === 0) {
                hasMoreRecords = false;
                continue;
            }

            // 2. For each incident, fetch its audit trail and generate events
            for (const incident of incidents) {
                const lastDataUpdate = new Date().toISOString();

                // --- Explicit Events from Incident Table ---
                allEvents.push(createEvent(incident, 'Incident Created', incident.sys_created_on, lastDataUpdate));
                if (incident.resolved_at) {
                    allEvents.push(createEvent(incident, 'Resolution Proposed', incident.resolved_at, lastDataUpdate));
                }
                if (incident.closed_at) {
                    allEvents.push(createEvent(incident, 'Incident Closed', incident.closed_at, lastDataUpdate));
                }

                // --- Inferred Events from Audit Table ---
                const auditQuery = `documentkey=${incident.sys_id}`;
                const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
                const auditResponse = await axios.get(`${INSTANCE_URL}/api/now/table/sys_audit`, {
                    auth,
                    params: { sysparm_query: auditQuery, sysparm_fields: auditFields, sysparm_display_value: 'true' }
                });

                const auditRecords = auditResponse.data.result.sort((a, b) => new Date(a.sys_created_on) - new Date(b.sys_created_on));
                
                let isCategorized = false, isGroupAssigned = false, isAgentAssigned = false, isWorkStarted = false, isProblemLinked = false, isReopened = false;
                let lastPriority = null;
                
                for (const audit of auditRecords) {
                    const eventTime = audit.sys_created_on;
                    
                    if (!isCategorized && (audit.fieldname === 'category' || audit.fieldname === 'subcategory') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Categorized', eventTime, lastDataUpdate));
                        isCategorized = true;
                    }
                    if (!isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Group', eventTime, lastDataUpdate));
                        isGroupAssigned = true;
                    } else if (isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Assignment Group Changed', eventTime, lastDataUpdate));
                    }
                    if (!isAgentAssigned && audit.fieldname === 'assigned_to' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Agent', eventTime, lastDataUpdate));
                        isAgentAssigned = true;
                    }
                    if (!isWorkStarted && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Work Started', eventTime, lastDataUpdate));
                        isWorkStarted = true;
                    }
                    if ((audit.fieldname === 'comments' || audit.fieldname === 'work_notes') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Support Comment Added', eventTime, lastDataUpdate));
                    }
                    if (audit.fieldname === 'priority') {
                         const oldPriorityVal = parseInt(audit.oldvalue.match(/\d+/), 10);
                         const newPriorityVal = parseInt(audit.newvalue.match(/\d+/), 10);
                         if (lastPriority !== null && newPriorityVal < lastPriority) {
                             allEvents.push(createEvent(incident, 'Incident Escalated', eventTime, lastDataUpdate));
                         }
                         lastPriority = newPriorityVal;
                    }
                    if (!isProblemLinked && audit.fieldname === 'problem_id' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Linked To Problem', eventTime, lastDataUpdate));
                        isProblemLinked = true;
                    }
                    if ((audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('awaiting')) {
                         allEvents.push(createEvent(incident, 'Awaiting User Confirmation', eventTime, lastDataUpdate));
                    }
                    if (!isReopened && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && (audit.oldvalue.toLowerCase().includes('resolved') || audit.oldvalue.toLowerCase().includes('closed')) && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Incident Reopened', eventTime, lastDataUpdate));
                        isReopened = true; 
                    }
                }
            }

            offset += BATCH_SIZE;
            console.log(`Processed ${incidents.length} incidents. Total events so far: ${allEvents.length}`);

        } catch (error) {
            console.error('An error occurred:', error.response ? error.response.data : error.message);
            hasMoreRecords = false; // Stop on error
        }
    }

    // 3. Save results to a file
    fs.writeFileSync('servicenow_incident_event_log.json', JSON.stringify(allEvents, null, 2));
    console.log(`Extraction complete. ${allEvents.length} events saved to servicenow_incident_event_log.json`);
}

// --- Helper Function to create a standard event object ---
function createEvent(incident, activityName, eventTime, lastDataUpdate) {
    return {
        IncidentId: incident.number,
        ActivityName: activityName,
        EventTime: eventTime,
        SourceSystem: SOURCE_SYSTEM,
        LastDataUpdate: lastDataUpdate,
        AssignedTo: incident.assigned_to.display_value || '',
        AssignmentGroup: incident.assignment_group.display_value || '',
        Priority: incident.priority.display_value || '',
        IncidentState: incident.incident_state.display_value || incident.state.display_value || ''
    };
}

// --- Run the script ---
extractIncidentData();

Stappen

Vereisten: Zorg dat Python 3.6 of hoger op je systeem is geïnstalleerd. Installeer de benodigde bibliotheken met pip: pip install requests pandas.
ServiceNow instellen: Maak voor deze extractie een apart serviceaccount aan in ServiceNow. Geef dit account de rollen itil en rest_api_explorer, zodat het de vereiste tabellen kan lezen: incident, sys_audit en sys_journal_field.
Het script configureren: Open het opgegeven Python-script. Vervang bovenaan in het configuratiegedeelte de invulwaarden voor SNOW_INSTANCE, SNOW_USER en SNOW_PASSWORD door de URL van je ServiceNow-instantie en de inloggegevens van het serviceaccount. Pas START_DATE en END_DATE aan om de gewenste periode in te stellen.
Het script uitvoeren: Voer in de opdrachtregel python your_script_name.py uit. Het script maakt verbinding met ServiceNow en voert API-aanroepen uit.
Data ophalen: Het script haalt eerst uit de incidenttabel een lijst op van alle incidenten die in de opgegeven periode zijn aangemaakt. Met de ID’s uit deze lijst haalt het vervolgens de bijbehorende auditgeschiedenis op uit sys_audit en alle opmerkingen uit sys_journal_field.
Het event log maken: Het script verwerkt de onbewerkte data in het geheugen. Het doorloopt de vooraf ingestelde activiteiten en maakt voor elke activiteit een aparte reeks rijen. Zo haalt het de gebeurtenis ‘Incident Created’ op uit het veld sys_created_on en ‘Incident Closed’ uit het veld closed_at. Voor andere gebeurtenissen analyseert het de auditlog om statusovergangen, veldwijzigingen en escalaties te vinden.
Attributen koppelen: Voor elke aangemaakte gebeurtenis zoekt het script de bijbehorende contextuele attributen op in het hoofdrecord van het incident. Denk aan AssignmentGroup, AssignedTo, Priority en IncidentState op het moment van de gebeurtenis.
Data samenvoegen: Alle afzonderlijke event DataFrames, één voor elk activiteitstype, worden samengevoegd tot één compleet event log DataFrame.
Laatste bewerking: Het samengevoegde DataFrame wordt gesorteerd op IncidentId en EventTime, zodat de gebeurtenissen per case in de juiste chronologische volgorde staan. De kolommen SourceSystem en LastDataUpdate worden toegevoegd met vaste waarden.
Exporteren naar CSV: Het uiteindelijke event log wordt opgeslagen als servicenow_incident_event_log.csv in de map waarin het script is uitgevoerd. Dit bestand is klaar om te uploaden naar process mining-software.

Configuratie

ServiceNow-instantie (SNOW_INSTANCE): De volledige URL van je ServiceNow-instantie, bijvoorbeeld https://yourcompany.service-now.com.
Inloggegevens (SNOW_USER, SNOW_PASSWORD): De authenticatiegegevens van het serviceaccount. Gebruik in productieomgevingen bij voorkeur OAuth of authenticatie met tokens in plaats van Basic Authentication.
Periode (START_DATE, END_DATE): Hiermee stel je de periode in op basis van de aanmaakdatum van incidenten. Voor een eerste analyse wordt 3 tot 6 maanden aangeraden. Zo houd je de hoeveelheid data en de informatiewaarde in balans. Bij langere periodes duurt de extractie aanzienlijk langer.
API-queryparameters (sysparm_query): Het script gebruikt sysparm_query om incidenten op aanmaakdatum (sys_created_on) te filteren. Je kunt hier voorwaarden toevoegen om de selectie te beperken, bijvoorbeeld active=false^company=[Your Company Sys ID] om alleen gesloten incidenten van een specifiek bedrijf op te halen.
API-aanroeplimieten: Houd rekening met de aanroeplimieten van de ServiceNow API. Het script verwerkt paginering, maar houdt niet expliciet rekening met deze limieten. Bij zeer grote instanties moet je mogelijk tussen verzoeken time.sleep() gebruiken om te voorkomen dat je de limiet overschrijdt.
Vereiste rechten: De opgegeven gebruiker moet leesrechten (ACL’s) hebben voor de tabellen incident, sys_audit en sys_journal_field. De rol itil geeft deze rechten meestal, maar je ServiceNow-instantie kan aangepaste toegangsregels hebben.

Voorbeeldquery python

import requests
import pandas as pd
from datetime import datetime
import getpass

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your ServiceNow instance URL, e.g., class="hl-string">'https://yourinstance.service-now.com'
SNOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
class=class="hl-string">"hl-comment"># Replace with your ServiceNow user. Consider using a dedicated service account.
SNOW_USER = class="hl-string">"[Your Username]"
class=class="hl-string">"hl-comment"># It's recommended to use a secure way to handle passwords, like environment variables or a secrets manager.
class=class="hl-string">"hl-comment"># getpass is used here for interactive entry to avoid hardcoding.
SNOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># Define the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

SOURCE_SYSTEM_NAME = class="hl-string">"ServiceNow"

class=class="hl-string">"hl-comment"># --- Helper Function for Paginated API Calls ---
def fetch_all_records(url, headers, params):
    class="hl-string">"""Fetches all records from a paginated ServiceNow API endpoint."""
    all_records = []
    offset = 0
    limit = 1000
    while True:
        params[class="hl-string">'sysparm_offset'] = offset
        params[class="hl-string">'sysparm_limit'] = limit
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for bad status codes
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        all_records.extend(data)
        offset += len(data)
        print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
    return all_records

class=class="hl-string">"hl-comment"># --- Main Script ---
if __name__ == class="hl-string">"__main__":
    auth = (SNOW_USER, SNOW_PASSWORD)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 1. Fetch base Incident Data
    print(class="hl-string">"\n--- Fetching Incident Data ---")
    incident_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/incident"
    incident_query = fclass="hl-string">"sys_created_on>={START_DATE} 00:00:00^sys_created_on<={END_DATE} 23:59:59"
    incident_params = {
        class="hl-string">'sysparm_query': incident_query,
        class="hl-string">'sysparm_fields': class="hl-string">'sys_id,number,sys_created_on,closed_at,opened_at,priority,state,assignment_group,assigned_to,problem_id'
    }
    incidents_raw = fetch_all_records(incident_url, headers, auth, incident_params)
    incidents_df = pd.DataFrame(incidents_raw)
    
    if incidents_df.empty:
        print(class="hl-string">"No incidents found for the given date range. Exiting.")
        exit()

    class=class="hl-string">"hl-comment"># Map sys_id to readable values for easier processing later
    for col in [class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'problem_id']:
        if col in incidents_df.columns:
            incidents_df[col] = incidents_df[col].apply(lambda x: x[class="hl-string">'display_value'] if isinstance(x, dict) and x else None)
            
    incident_sys_ids = class="hl-string">','.join(incidents_df[class="hl-string">'sys_id'].unique())

    class=class="hl-string">"hl-comment"># 2. Fetch Audit (sys_audit) Data for these incidents
    print(class="hl-string">"\n--- Fetching Audit Data ---")
    audit_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_audit"
    audit_query = fclass="hl-string">"documentkeyIN{incident_sys_ids}"
    audit_params = {
        class="hl-string">'sysparm_query': audit_query,
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,fieldname,oldvalue,newvalue'
    }
    audit_raw = fetch_all_records(audit_url, headers, auth, audit_params)
    audit_df = pd.DataFrame(audit_raw)
    audit_df.rename(columns={class="hl-string">'documentkey': class="hl-string">'sys_id'}, inplace=True)

    class=class="hl-string">"hl-comment"># 3. Fetch Journal (comments) Data for these incidents
    print(class="hl-string">"\n--- Fetching Journal/Comment Data ---")
    journal_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_journal_field"
    journal_query = fclass="hl-string">"element_idIN{incident_sys_ids}^element=work_notes,comments"
    journal_params = {
        class="hl-string">'sysparm_query': journal_query,
        class="hl-string">'sysparm_fields': class="hl-string">'element_id,sys_created_on'
    }
    journal_raw = fetch_all_records(journal_url, headers, auth, journal_params)
    journal_df = pd.DataFrame(journal_raw)
    journal_df.rename(columns={class="hl-string">'element_id': class="hl-string">'sys_id'}, inplace=True)

    print(class="hl-string">"\n--- Processing Data and Generating Event Log ---")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Merge incident details into audit and journal logs for context
    incidents_context_df = incidents_df[[class="hl-string">'sys_id', class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    incidents_context_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId'}, inplace=True)

    if not audit_df.empty:
        audit_df = pd.merge(audit_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')
    if not journal_df.empty:
        journal_df = pd.merge(journal_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Activity: Incident Created
    created_df = incidents_df[[class="hl-string">'number', class="hl-string">'sys_created_on', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    created_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Created'
    created_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'sys_created_on': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(created_df)

    class=class="hl-string">"hl-comment"># Activity: Incident Closed
    closed_df = incidents_df[incidents_df[class="hl-string">'closed_at'].notna() & (incidents_df[class="hl-string">'closed_at'] != class="hl-string">'')].copy()
    closed_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Closed'
    closed_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'closed_at': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(closed_df.drop(columns=[class="hl-string">'sys_created_on']))

    class=class="hl-string">"hl-comment"># Process audit data for remaining activities
    if not audit_df.empty:
        audit_df.sort_values(by=[class="hl-string">'sys_id', class="hl-string">'sys_created_on'], inplace=True)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Categorized (first change to category, subcategory, or priority)
        categorized_fields = [class="hl-string">'category', class="hl-string">'subcategory', class="hl-string">'priority']
        categorized_df = audit_df[audit_df[class="hl-string">'fieldname'].isin(categorized_fields)].copy()
        categorized_df = categorized_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        categorized_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Categorized'
        event_log_frames.append(categorized_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Group
        assign_group_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assignment_group') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_group_first_df = assign_group_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_group_first_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Group'
        event_log_frames.append(assign_group_first_df)
        
        class=class="hl-string">"hl-comment"># Activity: Assignment Group Changed (subsequent changes)
        assign_group_changed_df = assign_group_df.loc[assign_group_df.index.difference(assign_group_first_df.index)]
        assign_group_changed_df[class="hl-string">'ActivityName'] = class="hl-string">'Assignment Group Changed'
        event_log_frames.append(assign_group_changed_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Agent
        assign_agent_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assigned_to') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_agent_df = assign_agent_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_agent_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Agent'
        event_log_frames.append(assign_agent_df)

        class=class="hl-string">"hl-comment"># Activity: Work Started (State changed to In Progress)
        work_started_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: The class="hl-string">'newvalue' for state is often a numeric ID. Common value for class="hl-string">'In Progress' is class="hl-string">'2'. Adjust if needed.
        work_started_df = work_started_df[work_started_df[class="hl-string">'newvalue'].isin([class="hl-string">'2', class="hl-string">'In Progress', class="hl-string">'Work in Progress'])]
        work_started_df = work_started_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        work_started_df[class="hl-string">'ActivityName'] = class="hl-string">'Work Started'
        event_log_frames.append(work_started_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Escalated (Priority increases)
        priority_map = {class="hl-string">'1 - Critical': 1, class="hl-string">'2 - High': 2, class="hl-string">'3 - Moderate': 3, class="hl-string">'4 - Low': 4, class="hl-string">'5 - Planning': 5}
        escalated_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'priority'].copy()
        escalated_df[class="hl-string">'old_priority_val'] = escalated_df[class="hl-string">'oldvalue'].map(priority_map)
        escalated_df[class="hl-string">'new_priority_val'] = escalated_df[class="hl-string">'newvalue'].map(priority_map)
        escalated_df.dropna(subset=[class="hl-string">'old_priority_val', class="hl-string">'new_priority_val'], inplace=True)
        escalated_df = escalated_df[escalated_df[class="hl-string">'new_priority_val'] < escalated_df[class="hl-string">'old_priority_val']]
        escalated_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Escalated'
        event_log_frames.append(escalated_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Linked To Problem
        linked_problem_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'problem_id') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        linked_problem_df = linked_problem_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        linked_problem_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Linked To Problem'
        event_log_frames.append(linked_problem_df)
        
        class=class="hl-string">"hl-comment"># Activity: Resolution Proposed (State changed to Resolved)
        resolved_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: Common value for class="hl-string">'Resolved' is class="hl-string">'6'. Adjust if needed.
        resolved_df = resolved_df[resolved_df[class="hl-string">'newvalue'].isin([class="hl-string">'6', class="hl-string">'Resolved'])]
        resolved_df[class="hl-string">'ActivityName'] = class="hl-string">'Resolution Proposed'
        event_log_frames.append(resolved_df)
        
        class=class="hl-string">"hl-comment"># Activity: Awaiting User Confirmation (State changed to Awaiting User Info, after resolved)
        class=class="hl-string">"hl-comment"># This logic is complex and dependent on workflow. A simplified version is shown.
        state_changes = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        state_changes[class="hl-string">'prev_state'] = state_changes.groupby(class="hl-string">'sys_id')[class="hl-string">'oldvalue'].shift(-1)
        awaiting_df = state_changes[
            (state_changes[class="hl-string">'newvalue'].isin([class="hl-string">'Awaiting User Info', class="hl-string">'3'])) & 
            (state_changes[class="hl-string">'oldvalue'].isin([class="hl-string">'Resolved', class="hl-string">'6']))
        ].copy()
        awaiting_df[class="hl-string">'ActivityName'] = class="hl-string">'Awaiting User Confirmation'
        event_log_frames.append(awaiting_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Reopened
        reopened_df = audit_df[
            (audit_df[class="hl-string">'fieldname'] == class="hl-string">'state') & 
            (audit_df[class="hl-string">'oldvalue'].isin([class="hl-string">'6', class="hl-string">'7', class="hl-string">'Resolved', class="hl-string">'Closed']))
        ].copy()
        reopened_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Reopened'
        event_log_frames.append(reopened_df)
        
    class=class="hl-string">"hl-comment"># Activity: Support Comment Added
    if not journal_df.empty:
        comment_df = journal_df.copy()
        comment_df[class="hl-string">'ActivityName'] = class="hl-string">'Support Comment Added'
        event_log_frames.append(comment_df)

    class=class="hl-string">"hl-comment"># 4. Consolidate all event dataframes
    print(class="hl-string">"\n--- Consolidating Final Event Log ---")
    final_log = pd.DataFrame()
    for df in event_log_frames:
        if class="hl-string">'sys_created_on' in df.columns:
             df.rename(columns={class="hl-string">'sys_created_on': class="hl-string">'EventTime'}, inplace=True)
        if class="hl-string">'IncidentId' not in df.columns:
            continue class=class="hl-string">"hl-comment"># Skip frames that couldn't be processed
        
        common_cols = {
            class="hl-string">'IncidentId': None,
            class="hl-string">'ActivityName': None,
            class="hl-string">'EventTime': None,
            class="hl-string">'AssignedTo': None,
            class="hl-string">'AssignmentGroup': None,
            class="hl-string">'Priority': None,
            class="hl-string">'IncidentState': None
        }
        
        class=class="hl-string">"hl-comment"># Select and reorder columns, filling missing ones with None
        current_cols = {col: None for col in common_cols.keys()}
        df_subset = df[list(set(df.columns) & set(common_cols.keys()))].copy()
        final_log = pd.concat([final_log, df_subset], ignore_index=True)

    class=class="hl-string">"hl-comment"># 5. Final Cleaning and Formatting
    final_log.dropna(subset=[class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    final_log[class="hl-string">'EventTime'] = pd.to_datetime(final_log[class="hl-string">'EventTime'])
    final_log.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTime'], inplace=True)
    
    final_log[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM_NAME
    final_log[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to the desired format
    final_log = final_log[[
        class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
        class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'IncidentState'
    ]]

    class=class="hl-string">"hl-comment"># 6. Save to CSV
    output_filename = class="hl-string">'servicenow_incident_event_log.csv'
    final_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"\nSuccessfully extracted {len(final_log)} events for {final_log['IncidentId'].nunique()} incidents.")
    print(fclass="hl-string">"Event log saved to {output_filename}")

Klaar om te beginnen?

Met deze template heb je alles wat je nodig hebt om te starten met process mining voor incidentbeheer. Begin vandaag nog met het verbeteren van de afhandeling van incidenten.

Terug naar de verbetergids

Template downloaden

Los incidenten sneller op: verbeter nu de efficiëntie van ServiceNow

Verlaag de MTTR met 35% in ServiceNow. Vind problemen en verhoog de tevredenheid.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Begin binnen enkele minuten met optimaliseren.

Datatemplate voor incidentbeheer

Datatemplate voor incidentbeheer

Attributen voor incidentbeheer

Activiteiten voor incidentbeheer

Extractiegidsen

Rechtstreekse extractie via de ServiceNow Table REST API

Stappen

Configuratie

Voorbeeldquery javascript

Extractie met een Python-script via de ServiceNow REST API

Stappen

Configuratie

Voorbeeldquery python

Klaar om te beginnen?

Los incidenten sneller op: verbeter nu de efficiëntie van ServiceNow