Jouw datatemplate voor incidentbeheer
Jouw datatemplate voor incidentbeheer
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Extractie-instructies voor ServiceNow-probleembeheer
Attributen voor incidentbeheer
| 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
|
|||
Incidentbeheeractiviteiten
| 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
|
|||
Extractiegidsen
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.
Je hebt geen creditcard nodig. Begin binnen enkele minuten met optimaliseren.