Jouw datatemplate voor incidentbeheer

ServiceNow-probleembeheer
Jouw datatemplate voor incidentbeheer

Jouw datatemplate voor incidentbeheer

Deze template biedt een praktische leidraad voor het verzamelen van de data die je nodig hebt om je incidentbeheerproces te analyseren en te optimaliseren. Je ziet welke data-attributen je moet verzamelen, welke activiteiten je moet volgen en hoe je deze informatie uit je bronsysteem haalt. Gebruik deze bron om een betrouwbaar event log op te bouwen voor grondige procesanalyse en verbetering.
  • Aanbevolen attributen om te verzamelen
  • Belangrijke activiteiten om te volgen
  • Extractie-instructies voor ServiceNow-probleembeheer
Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Attributen voor incidentbeheer

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van je incidentbeheerproces.
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 incidentlevenscyclus plaatsvond.
Beschrijving

De Activiteitsnaam beschrijft een specifieke stap of statuswijziging in het Incident Management-proces, zoals 'Incident Created', 'Assigned To Agent' of 'Incident Closed'. Deze data is meestal afkomstig van wijzigingen in belangrijke incidentvelden zoals 'State' of 'Assignment Group', of van specifieke logvermeldingen.

Dit attribuut is essentieel voor het opbouwen van de proceskaart. Het bepaalt de knooppunten in de procesgrafiek, zodat analisten de incidentstroom kunnen visualiseren, veelvoorkomende routes kunnen vinden, bottlenecks tussen activiteiten kunnen ontdekken en procesvarianten kunnen analyseren. De mate van detail en nauwkeurigheid van deze activiteitsnamen heeft rechtstreeks invloed op de kwaliteit van de procesanalyse.

Waarom dit belangrijk is

Het bepaalt de stappen in de proceskaart, de basis voor alle process mining-analyses en visualisaties.

Waar je het vindt

Dit is een afgeleid attribuut dat meestal wordt gegenereerd 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
Eventtijd
EventTime
De precieze timestamp die aangeeft wanneer de activiteit plaatsvond.
Beschrijving

Eventtijd, vaak timestamp genoemd, registreert de exacte datum en tijd waarop een activiteit is voltooid of een statuswijziging plaatsvond. In ServiceNow wordt dit meestal vastgelegd in het veld sys_updated_on voor elke wijziging in het auditspoor.

Dit attribuut is essentieel om gebeurtenissen in de juiste volgorde te zetten en voor alle tijdgebaseerde analyses. Het wordt gebruikt om doorlooptijden, wachttijden en de duur tussen activiteiten te berekenen. Die gegevens zijn belangrijk om bottlenecks te vinden, prestaties ten opzichte van SLA's te meten en de procesefficiëntie te begrijpen. De nauwkeurigheid van deze timestamps is bepalend voor de betrouwbaarheid van alle metriek op basis van tijdsduur.

Waarom dit belangrijk is

Deze timestamp zet alle activiteiten chronologisch en maakt het berekenen van alle metriek op basis van tijdsduur mogelijk, zoals doorlooptijden en bottlenecks.

Waar je het vindt

ServiceNow-tabel sys_audit, veld sys_created_on of het veld sys_updated_on uit de incidenttabel voor de laatste status.

Voorbeelden
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
Incident-ID
IncidentId
De unieke identificatie voor elk incidentrecord, die als primaire sleutel dient om de volledige levenscyclus te volgen.
Beschrijving

De Incident-ID is het unieke referentienummer dat aan elk gemeld incident in ServiceNow wordt toegewezen. Deze ID is de centrale case-identificatie die alle gerelateerde activiteiten, updates en communicatie koppelt vanaf het moment waarop een incident wordt aangemaakt tot het wordt gesloten.

In process mining-analyse is deze ID essentieel. Hiermee kan de tool de reeks gebeurtenissen voor elke afzonderlijke case samenvoegen. Dat vormt de basis voor het ontdekken van proceskaarten, het analyseren van varianten en het berekenen van end-to-end-doorlooptijden. Zonder een unieke Incident-ID per case is het onmogelijk om het verloop van een incident door het oplossingsproces te volgen.

Waarom dit belangrijk is

Dit is de essentiële Case-ID die alle gebeurtenissen in de levenscyclus van een incident koppelt en end-to-end-procesanalyse mogelijk maakt.

Waar je het vindt

ServiceNow-incidenttabel, veld number.

Voorbeelden
INC0010001INC0010045INC0010239
Bronsysteem
SourceSystem
Het systeem waaruit deze data is geëxtraheerd.
Beschrijving

Dit attribuut identificeert de herkomst van de incidentdata, in dit geval ServiceNow Problem Management. Het is meestal een statische waarde die tijdens de data-extractie en -transformatie wordt toegevoegd.

In omgevingen waar data uit meerdere systemen voor analyse wordt gecombineerd, is dit veld belangrijk voor dataherkomst en scheiding. Het helpt ervoor te zorgen dat metriek en processen in de juiste context worden geanalyseerd en stelt analisten in staat processen uit verschillende bronsystemen te vergelijken.

Waarom dit belangrijk is

Het geeft belangrijke context over de herkomst van de data, ondersteunt dataherkomst en maakt een juiste interpretatie in omgevingen met meerdere systemen mogelijk.

Waar je het vindt

Dit is meestal een statische waarde die tijdens het data-extractieproces wordt toegevoegd.

Voorbeelden
ServiceNow-probleembeheerServiceNow
Laatste data-update
LastDataUpdate
De timestamp die aangeeft wanneer de data voor dit record voor het laatst vanuit het bronsysteem is vernieuwd.
Beschrijving

Dit attribuut registreert de datum en tijd van de meest recente data-extractie of update vanuit ServiceNow. Het is een metadataveld dat de actualiteit van de geanalyseerde data weergeeft, niet een gebeurtenis in het proces zelf.

Deze informatie is belangrijk om te begrijpen hoe actueel de analyse is. Je ziet hiermee hoe recent de data is, wat van belang is voor operationele dashboards en beslissingen op basis van recente gebeurtenissen. Het helpt verwachtingen te managen over de relevantie en actualiteit van de data.

Waarom dit belangrijk is

Het informeert gebruikers over de actualiteit van de data, die belangrijk is voor de relevantie en nauwkeurigheid van de analyse.

Waar je het vindt

Deze timestamp wordt door de data-extractietool of het data-extractieproces gegenereerd en ingevuld tijdens het laden van de data.

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 het 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.

Door de tijd in elke status te analyseren, kun je bottlenecks vinden. Een lange duur in de status 'On Hold' kan bijvoorbeeld wijzen op afhankelijkheden van externe factoren of gebruikers. De reeks statuswijzigingen vormt ook de basis van de proceskaart en laat zien hoe incidenten naar een oplossing toe werken.

Waarom dit belangrijk is

Het volgt de voortgang van het incident en is belangrijk voor het analyseren van tijd in verschillende fasen en het vinden van procesbottlenecks.

Waar je het vindt

ServiceNow-incidenttabel, veld incident_state of state.

Voorbeelden
NieuwIn behandelingIn afwachting van gebruikersinformatieOpgelostGesloten
Prioriteit
Priority
Het prioriteitsniveau van het incident, dat bepaalt hoe snel er moet worden gereageerd.
Beschrijving

Prioriteit is een belangrijk veld in ServiceNow dat de volgorde en snelheid voor de afhandeling van een incident bepaalt. De waarde wordt meestal afgeleid van de impact en urgentie van het incident en heeft rechtstreeks invloed op SLA-doelen.

Dit attribuut is belangrijk voor segmentatie en prestatieanalyse. Het dashboard 'Overzicht SLA-compliance' gebruikt Priority om te beoordelen of incidenten met hoge prioriteit binnen de beoogde tijd worden opgelost. Door doorlooptijden per prioriteit te analyseren, kun je controleren of kritieke incidenten inderdaad sneller worden afgehandeld dan minder belangrijke incidenten. Het is een belangrijke dimensie voor vrijwel elke KPI en elk dashboard.

Waarom dit belangrijk is

Hiermee kun je incidenten indelen op bedrijfsbelang, wat belangrijk is voor SLA-monitoring en de toewijzing van bronnen.

Waar je het vindt

ServiceNow-incidenttabel, veld priority.

Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
Toegewezen aan
AssignedTo
De individuele gebruiker of medewerker die momenteel aan het incident is toegewezen.
Beschrijving

Dit attribuut identificeert de specifieke supportmedewerker die op een bepaald moment verantwoordelijk is voor het incident. Deze informatie is belangrijk om de verdeling van de werkbelasting, prestaties van medewerkers en overdrachten tussen personen te begrijpen.

In analyses helpt 'Assigned To' om de toewijzing van bronnen zichtbaar te maken en overbelaste medewerkers te vinden. Het wordt ook gebruikt in het dashboard Overdrachten en herverdelingen om te volgen hoe vaak een incident van individuele eigenaar wisselt. Dat kan wijzen op inefficiëntie of kennishiaten. Door oplostijden per medewerker te analyseren, kun je bovendien sterke prestaties en opleidingsbehoeften herkennen.

Waarom dit belangrijk is

Hiermee kun je de werkbelasting, prestaties en individuele overdrachten van medewerkers analyseren. Dat is belangrijk om de efficiëntie van bronnen te begrijpen.

Waar je het vindt

ServiceNow-incidenttabel, 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 staat voor het team van medewerkers dat het incident moet oplossen. Incidenten worden vaak tussen verschillende groepen gerouteerd, bijvoorbeeld van een Level 1-helpdesk naar een gespecialiseerd Level 2-netwerkteam.

Dit attribuut is essentieel voor het analyseren van overdrachten tussen teams en het vinden van structurele bottlenecks. Het dashboard 'Overdrachts- en herverdelingspercentage' gebruikt deze data om te laten zien welke teams vaak bij overdrachten betrokken zijn. Je kunt er ook prestaties van verschillende supportgroepen mee vergelijken en zien waar de oplossingskennis binnen de organisatie zit.

Waarom dit belangrijk is

Dit volgt welk team verantwoordelijk is en maakt analyse van teamprestaties, werkbelasting en overdrachten tussen groepen mogelijk.

Waar je het vindt

ServiceNow-incidenttabel, veld assignment_group.

Voorbeelden
ServicedeskNetwerkondersteuningDatabasebeheerders
Aantal herverdelingen
ReassignmentCount
Het aantal keer dat het incident opnieuw aan een andere groep of medewerker is toegewezen.
Beschrijving

Dit veld volgt het totale aantal keer dat een incident tussen verschillende toewijzingsgroepen is overgedragen. Het is een directe maat voor procesfrictie en wordt vaak als belangrijke prestatie-indicator gebruikt.

Dit attribuut vormt de basis voor het dashboard 'Overdrachts- en herverdelingspercentage' en de KPI 'Gemiddeld aantal overdrachten per incident'. Een hoog aantal herverdelingen wijst vaak op problemen zoals een onjuiste eerste routering, onvoldoende vaardigheden binnen een supportniveau of onduidelijk proceseigenaarschap. Dit aantal verlagen is een veelvoorkomend doel van procesverbetering, omdat het meestal leidt tot kortere oplostijden.

Waarom dit belangrijk is

Dit meet overdrachten binnen het proces rechtstreeks. Het is een belangrijke indicator voor inefficiëntie, onjuiste routering en mogelijkheden voor verbetering.

Waar je het vindt

ServiceNow-incidenttabel, veld reassignment_count.

Voorbeelden
0135
Categorie
Category
De classificatie op hoofdniveau van het incident, zoals Hardware, Software of Netwerk.
Beschrijving

De Categorie geeft een brede classificatie van de aard van een incident. Vaak in combinatie met een subcategorie helpt dit veld om het incident naar het juiste supportteam te routeren en wordt het gebruikt voor rapportage en trendanalyse.

Voor process mining is dit attribuut belangrijk voor de dashboards 'Nauwkeurigheid van incidentcategorisering' en 'Aantal terugkerende incidenten'. Door incidenten te analyseren waarvan de categorie tijdens het proces verandert, kunnen organisaties problemen in de eerste triage vinden. Door de proceskaart op categorie te filteren, zie je ook of bepaalde typen incidenten andere oplossingsroutes volgen of met specifieke bottlenecks te maken hebben.

Waarom dit belangrijk is

Hiermee kun je incidenttypen analyseren, de nauwkeurigheid van categorisering meten en routering en trendanalyse ondersteunen.

Waar je het vindt

ServiceNow-incidenttabel, veld category.

Voorbeelden
HardwareSoftwareNetwerkDatabase
Configuratie-item
ConfigurationItem
De specifieke IT-component, service of asset die door het incident wordt geraakt.
Beschrijving

Het Configuration Item (CI) is de asset uit de Configuration Management Database (CMDB) die door het incident wordt geraakt. Dit kan een server, applicatie, laptop of netwerkapparaat zijn.

Incidenten per CI analyseren is waardevol om onbetrouwbare assets of services te vinden. Je ziet hiermee welke onderdelen van de IT-infrastructuur de meeste incidenten veroorzaken. Dat kan helpen bij beslissingen over upgrades of vervanging. In process mining kan filteren op CI laten zien of incidenten rond kritieke applicaties anders of efficiënter worden afgehandeld dan andere incidenten.

Waarom dit belangrijk is

Het identificeert de getroffen asset, helpt problematische onderdelen in de IT-infrastructuur te vinden en richt verbeteracties op de juiste plek.

Waar je het vindt

ServiceNow-incidenttabel, veld cmdb_ci.

Voorbeelden
SAP ERP ProductionOracle DB Server 05E-mailservice
Ernst
Severity
De mate van bedrijfsimpact die door het incident wordt veroorzaakt.
Beschrijving

Ernst geeft aan hoeveel invloed een incident heeft op de bedrijfsvoering. Samen met urgentie wordt dit veld vaak gebruikt om automatisch de prioriteit van het incident te berekenen.

In analyses is ernst een belangrijke dimensie voor het dashboard 'Overzicht SLA-compliance'. Je ziet hiermee of de serviceniveaus voor incidenten met de grootste impact worden gehaald. Het biedt een bedrijfsperspectief op prestaties en vormt een aanvulling op het operationele perspectief van prioriteit.

Waarom dit belangrijk is

Het meet de bedrijfsimpact van een incident en biedt een belangrijke dimensie voor het prioriteren van acties en het analyseren van prestaties bij kritieke problemen.

Waar je het vindt

ServiceNow-incidenttabel, veld severity.

Voorbeelden
1 - Hoog2 - Gemiddeld3 - Laag
Heropend
IsReopened
Een vlag die aangeeft of een incident na het oplossen opnieuw is geopend.
Beschrijving

Deze boolean-vlag krijgt de waarde true als de status van een incident na de status 'Resolved' of 'Closed' weer verandert naar een actieve status, zoals 'In Progress'. Dit wordt meestal vastgesteld door te zoeken naar de activiteit 'Incident Reopened' in het event log.

Heropende incidenten wijzen vaak op onvolledige of ineffectieve oplossingen. Door deze cases te analyseren, kun je voortijdige sluitingen of terugkerende problemen opsporen die de eerste keer niet goed zijn opgelost. Een hoog percentage heropeningen kan de gebruikerstevredenheid en productiviteit van het team negatief beïnvloeden. Daarom is dit een belangrijke kwaliteitsindicator.

Waarom dit belangrijk is

Deze vlag identificeert problemen in het oplossingsproces. Hij laat zien welke incidenten extra werk nodig hadden nadat ze als opgelost waren beschouwd.

Waar je het vindt

Berekend door de volgorde van activiteiten per incident te controleren en na te gaan of een status 'open' volgt op een status 'resolved'.

Voorbeelden
truefalse
Melder
CallerId
De gebruiker die het incident oorspronkelijk heeft gemeld.
Beschrijving

De melder is de eindgebruiker of klant die door het incident wordt geraakt en het incident heeft gemeld. Deze informatie laat zien wie last heeft van de serviceonderbreking.

De melder staat niet altijd centraal in de procesflow. Toch kan een analyse per melder laten zien of bepaalde personen of afdelingen onevenredig vaak door problemen worden geraakt. Dat kan wijzen op trainingsbehoeften of lokale problemen in de werkomgeving. Ook biedt het een directe link naar de klant voor tevredenheidsonderzoeken en communicatie.

Waarom dit belangrijk is

Het identificeert de getroffen gebruiker. Zo kun je analyseren per afdeling of persoon en houd je rekening met de communicatie naar gebruikers.

Waar je het vindt

ServiceNow-incidenttabel, veld caller_id.

Voorbeelden
Abel TuterCarolina PashDon Goodliffe
Oplossingscode
ResolutionCode
Een code die aangeeft hoe het incident uiteindelijk is opgelost.
Beschrijving

De Oplossingscode beschrijft de aard van de toegepaste oplossing. Zo kan het incident door de gebruiker zijn opgelost, door een bekende fout zijn verholpen of met een workaround zijn afgehandeld. De medewerker vult dit veld meestal in bij het sluiten van het incident.

Dit attribuut ondersteunt rechtstreeks het dashboard 'Effectiviteit van oplossingstypen'. Je kunt ermee analyseren hoeveel incidenten met een permanente oplossing worden gesloten en hoeveel met een tijdelijke workaround. Dat is een belangrijke indicator voor servicekwaliteit en stabiliteit op lange termijn. Een hoog percentage workarounds kan erop wijzen dat onderliggende problemen niet goed worden aangepakt.

Waarom dit belangrijk is

Het maakt de oplossingsmethode duidelijk, zodat je permanente oplossingen kunt vergelijken met tijdelijke workarounds en de grondoorzaak kunt analyseren.

Waar je het vindt

ServiceNow-incidenttabel, veld close_code of een aangepast veld voor de oplossingscode.

Voorbeelden
Opgelost (tijdelijke oplossing)Opgelost (definitief)Niet opgelost (gebruiker geannuleerd)Bekende fout
Probleem-ID
ProblemId
De identificatie van het gekoppelde probleemrecord als het incident aan een groter probleem is gekoppeld.
Beschrijving

De Probleem-ID koppelt een incident aan een bijbehorend record in de module Problem Management. Dit gebeurt wanneer een incident een symptoom blijkt te zijn van een groter onderliggend probleem dat meerdere gebruikers of services raakt.

Deze koppeling is belangrijk voor het dashboard 'Aantal terugkerende incidenten' en de KPI 'Percentage terugkerende incidenten'. Analisten kunnen er incidenten mee groeperen die dezelfde grondoorzaak hebben, de volledige impact van een probleem meten en de effectiviteit van probleemoplossing volgen. Een groot aantal aan problemen gekoppelde incidenten wijst op een reactieve supportomgeving.

Waarom dit belangrijk is

Het koppelt incidenten aan een grondoorzaak. Dat is belangrijk voor het analyseren van terugkerende problemen en het meten van de impact van probleembeheer.

Waar je het vindt

ServiceNow-incidenttabel, veld problem_id.

Voorbeelden
PRB0040001PRB0040015PRB0040102
SLA overschreden
IsSlaBreached
Een vlag die aangeeft of het oplossen van het incident langer duurde dan de SLA-vervaldatum.
Beschrijving

Dit is een berekend boolean-attribuut dat aangeeft of een incident de Service Level Agreement heeft overschreden. Het wordt bepaald door de werkelijke oplostimestamp te vergelijken met de 'SLA-vervaldatum'. Ligt de oplostijd na de vervaldatum, dan krijgt de vlag de waarde true.

Dit attribuut vormt de basis voor het dashboard 'SLA Compliance Overview' en bijbehorende KPI's. Het maakt analyse eenvoudiger door een complexe tijdsvergelijking om te zetten in een eenvoudige true/false-dimensie. Zo kun je alle overschreden incidenten filteren en hun gemeenschappelijke kenmerken analyseren, zoals categorie, toewijzingsgroep of prioriteit.

Waarom dit belangrijk is

Het vereenvoudigt de analyse van SLA-compliance. Zo kun je eenvoudig filteren op incidenten die hun doel niet hebben gehaald en deze verder analyseren.

Waar je het vindt

Berekend door de timestamp 'Resolved At' te vergelijken met de timestamp 'SlaDueDate'. (Resolved At > SlaDueDate).

Voorbeelden
truefalse
SLA-vervaldatum
SlaDueDate
De datum en tijd waarop het incident volgens de SLA naar verwachting is opgelost.
Beschrijving

Het SLA-vervaldatum is een berekende timestamp die de deadline voor het oplossen van een incident aangeeft. Deze datum wordt bepaald door de Service Level Agreement (SLA) die bij de kenmerken van het incident hoort, zoals de prioriteit.

Dit attribuut is essentieel voor het dashboard 'SLA Compliance Overview' en de KPI 'Critical Incident SLA Breach Rate'. Het is de norm waarmee de werkelijke oplostijd wordt vergeleken. Door incidenten te analyseren die dicht bij hun SLA-vervaldatum komen, kun je proactief escaleren en prioriteiten bepalen.

Waarom dit belangrijk is

Het bepaalt de oplosdoelstelling. Zo kun je SLA-compliance meten en incidenten identificeren die hun doel dreigen te overschrijden.

Waar je het vindt

Deze waarde staat meestal in de tabel task_sla, die is gekoppeld aan de incident-tabel. Het veld planned_end_time bevat de relevante timestamp.

Voorbeelden
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
Verplicht Aanbevolen Optioneel

Incidentbeheeractiviteiten

Dit zijn de belangrijkste processtappen en mijlpalen die je in je event log moet vastleggen voor een nauwkeurige procesontdekking en optimalisatie.
6 Aanbevolen 7 Optioneel
Activiteit Beschrijving
Incident aangemaakt
Dit markeert het begin van de incidentlevenscyclus, wanneer een nieuw incident formeel wordt vastgelegd in ServiceNow. Deze gebeurtenis wordt expliciet 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 analyseren is essentieel om de totale doorlooptijd en SLA-compliance te meten.

Waar je het vindt

De timestamp 'sys_created_on' in de tabel 'incident' dient als de expliciete event-timestamp voor deze activiteit.

Vastleggen

Gebruik de timestamp 'sys_created_on' uit het incidentrecord.

Eventtype 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 sluitingstimestamp.
Waarom dit belangrijk is

Als definitieve eindgebeurtenis is deze activiteit essentieel voor het berekenen van de totale duur van de incidentlevenscyclus en het analyseren van de tijd voor verwerking na de oplossing.

Waar je het vindt

De timestamp 'closed_at' in de tabel 'incident' dient als de expliciete event-timestamp. Deze wordt meestal ingesteld wanneer het veld 'state' verandert naar 'Closed'.

Vastleggen

Gebruik de timestamp 'closed_at' uit het incidentrecord.

Eventtype explicit
Incident toegewezen aan groep
Deze activiteit vindt plaats wanneer een incident wordt toegewezen aan een specifieke supportgroep voor afhandeling. Dit is een belangrijke stap in het routeringsproces en wordt vastgelegd door wijzigingen in het veld voor de toewijzingsgroep te volgen.
Waarom dit belangrijk is

Het volgen van toewijzingen is essentieel om overdrachten en wachttijden per groep te analyseren en inefficiënte routering of bottlenecks te vinden.

Waar je het vindt

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 voor wijzigingen in het veld 'assignment_group'.

Eventtype inferred
Oplossing voorgesteld
Dit markeert het moment waarop een supportmedewerker een oplossing heeft geïmplementeerd en het incident de status 'Resolved' krijgt. Dit is een belangrijke mijlpaal vóór de definitieve sluiting.
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 vertragingen in de bevestiging door de gebruiker of in de controle zichtbaar maken.

Waar je het vindt

Afgeleid uit de tabel 'sys_audit' wanneer het veld 'state' in de tabel 'incident' verandert naar 'Resolved'. De timestamp 'resolved_at' wordt op dat moment vaak ingevuld.

Vastleggen

Gebruik de timestamp waarop het veld 'state' 'Resolved' wordt, of de timestamp 'resolved_at'.

Eventtype inferred
Toewijzingsgroep gewijzigd
Dit staat voor een overdracht waarbij een incident van de ene supportgroep naar een andere wordt overgedragen. Dit wordt vastgelegd door latere wijzigingen in het veld 'assignment_group' na de eerste invulling te volgen.
Waarom dit belangrijk is

Veelvuldige herverdelingen kunnen wijzen op een onjuiste eerste routering, een complex proces of kennishiaten. Deze activiteit is belangrijk voor het meten van de KPI 'Gemiddeld aantal overdrachten per incident'.

Waar je het vindt

Afgeleid uit de tabel 'sys_audit' door elke wijziging in het veld 'assignment_group' na de eerste toewijzing te volgen.

Vastleggen

Identificeer elke wijziging met timestamp in het veld 'assignment_group' in het auditlog.

Eventtype inferred
Werk gestart
Dit geeft aan dat een medewerker actief is begonnen met het onderzoeken of behandelen van het incident. Dit wordt meestal afgeleid wanneer de status van het incident verandert 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 oplossingsfase. De tijd tot de start van het werk meten is belangrijk voor bottleneckanalyse.

Waar je het vindt

Afgeleid uit de tabel 'sys_audit' door vast te stellen wanneer het veld 'state' in de tabel 'incident' verandert naar een waarde die actief werk aangeeft, zoals 'In Progress'.

Vastleggen

Identificeer de timestamp waarop het veld 'state' verandert naar 'In Progress' of een vergelijkbare waarde.

Eventtype inferred
Incident gecategoriseerd
Dit staat voor 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 voor het eerst worden ingevuld of kort na het aanmaken worden bijgewerkt.
Waarom dit belangrijk is

Een juiste categorisering is essentieel voor correcte routering en prioritering. Door deze activiteit te volgen, kun je het aantal hercategoriseringen en de invloed daarvan op de oplostijd analyseren.

Waar je het vindt

Afgeleid uit de tabel 'sys_audit' door de eerste wijziging te identificeren in velden zoals 'category', 'subcategory' of 'priority' voor een bepaald incident.

Vastleggen

Identificeer de timestamp van de eerste update van classificatievelden in het auditlog.

Eventtype 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 door een verhoging van de waarde in het veld 'priority' vast te stellen.
Waarom dit belangrijk is

Escalaties wijzen er vaak op dat een incident ernstiger is dan eerst gedacht of een SLA-overschrijding nadert. Door deze gebeurtenissen te analyseren, krijg je inzicht in uitzonderingen binnen het proces.

Waar je het vindt

Afgeleid uit de tabel 'sys_audit' door een wijziging in het veld 'priority' naar een waarde met hogere urgentie te identificeren.

Vastleggen

Detecteer wanneer de waarde van het veld 'priority' stijgt, bijvoorbeeld van '3 - Moderate' naar '2 - High'.

Eventtype inferred
Incident gekoppeld aan probleem
Deze activiteit vindt plaats wanneer een incident formeel aan een probleemrecord wordt gekoppeld. Dit geeft aan dat het incident onderdeel is van een groter onderliggend probleem. Dit wordt afgeleid wanneer het veld 'problem_id' in het incidentrecord wordt ingevuld.
Waarom dit belangrijk is

Een koppeling met een probleem is een belangrijke stap van reactief incidentherstel naar proactieve analyse van de grondoorzaak. Dit ondersteunt het dashboard 'Aantal terugkerende incidenten'.

Waar je het vindt

Afgeleid door vast te stellen wanneer het referentieveld 'problem_id' in de tabel 'incident' een waarde krijgt.

Vastleggen

Identificeer de timestamp uit het auditlog waarop het veld 'problem_id' wordt ingevuld.

Eventtype inferred
Incident heropend
Dit gebeurt wanneer een gebruiker meldt dat het probleem blijft bestaan 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 vormen herstelwerk. Door deze activiteit te volgen, kun je de oplossingskwaliteit en het percentage oplossingen bij de eerste poging meten.

Waar je het vindt

Afgeleid uit de tabel 'sys_audit' door een overgang in het veld 'state' van 'Resolved' terug naar een actieve status zoals 'In Progress' of 'Assigned' te detecteren.

Vastleggen

Identificeer de timestamp waarop 'state' van 'Resolved' naar een actieve waarde gaat.

Eventtype inferred
Incident toegewezen aan medewerker
Dit staat voor het moment waarop een specifieke medewerker binnen een supportgroep verantwoordelijkheid neemt voor het incident. Dit wordt vastgelegd door wijzigingen in het veld 'assigned_to' te volgen.
Waarom dit belangrijk is

Dit geeft een gedetailleerd beeld van de werkbelasting van medewerkers en de oplossing bij het eerste contact. Je ziet hiermee hoe lang incidenten wachten voordat een individuele medewerker na toewijzing aan een groep aan het werk gaat.

Waar je het vindt

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 voor wijzigingen in het veld 'assigned_to'.

Eventtype inferred
Supportopmerking toegevoegd
Een supportmedewerker 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

Dit volgt de communicatie en onderzoeksactiviteiten van het supportteam. Door de frequentie en timing van deze opmerkingen te analyseren, krijg je inzicht in het onderzoeksproces.

Waar je het vindt

Vastgelegd in de tabel 'sys_journal_field', waarin vermeldingen voor de velden 'work_notes' en 'comments' in de tabel 'incident' worden geregistreerd.

Vastleggen

Gebruik de aanmaaktimestamp van journaalvermeldingen waarbij het element 'work_notes' of 'comments' is.

Eventtype 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 belangrijke bottleneck vormen als gebruikers traag reageren. Door de tijd in deze activiteit te meten, kun je communicatieproblemen en mogelijkheden voor automatische sluiting vinden.

Waar je het vindt

Afgeleid uit de tabel 'sys_audit' door na de oplossing een wijziging naar een specifieke wachtstatus te identificeren. De statusnaam kan aangepast zijn, bijvoorbeeld 'Awaiting Caller'.

Vastleggen

Identificeer de timestamp waarop 'state' verandert naar een waarde die aangeeft dat er op input van de gebruiker wordt gewacht.

Eventtype inferred
Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit ServiceNow-probleembeheer

Klaar om aan de slag te gaan?

Met deze template heb je alles wat je nodig hebt om met process mining voor incidentbeheer te beginnen. Begin vandaag nog met het verbeteren van je incidentoplossing.

Los incidenten sneller op: verbeter je ServiceNow-efficiëntie nu

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

Start je gratis proefperiode

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