Datatemplate voor incidentbeheer

De Activiteitsnaam beschrijft een afzonderlijke stap of taak binnen het incidentbeheerproces. Deze activiteiten vormen de bouwstenen van de proceskaart. Het kan gaan om automatische systeemgebeurtenissen, zoals ‘SLA-overschrijding gedetecteerd’, of handmatige acties, zoals ‘Medewerker toegewezen’ of ‘Tijdelijke oplossing geboden’.

Dit attribuut is onmisbaar voor process mining. Het bepaalt de knooppunten in de procesgrafiek, zodat analisten de werkstroom kunnen visualiseren, veelvoorkomende routes kunnen herkennen, bottlenecks kunnen opsporen en afwijkingen van de standaardprocedure kunnen analyseren. Hoe duidelijk en specifiek de activiteitsnamen zijn, heeft rechtstreeks invloed op de kwaliteit en bruikbaarheid van de inzichten.

Dit attribuut bepaalt de stappen in het proces en maakt het mogelijk om het verloop van de levenscyclus van een incident te visualiseren en analyseren.

Vaak af te leiden uit een combinatie van event logs, auditsporen, statuswijzigingen of taakbeschrijvingen in het incidentbeheersysteem.

Het Incident-ID is een unieke alfanumerieke code waarmee je een incident van alle andere incidenten in het systeem kunt onderscheiden. De code wordt aangemaakt wanneer een nieuw incident wordt geregistreerd en blijft hetzelfde totdat het incident definitief wordt gearchiveerd of verwijderd.

Bij process mining is het Incident-ID de basis van de analyse en dient het als Case-ID. De software gebruikt het om alle bijbehorende gebeurtenissen, statuswijzigingen en activiteiten samen te voegen tot één procesinstantie. Door alle gebeurtenissen aan hetzelfde Incident-ID te koppelen, kunnen analisten het volledige verloop van elk incident in kaart brengen, van de eerste melding tot de uiteindelijke oplossing en afsluiting.

Dit is essentieel om alle bijbehorende activiteiten en gebeurtenissen aan elkaar te koppelen en zo de volledige levenscyclus van een incident voor process mining te reconstrueren.

Dit is de primaire sleutel van een incident. Je vindt deze meestal in de kop of hoofdregistratie van elke incidenttabel of elk incidentobject.

De timestamp van een gebeurtenis geeft het exacte moment aan waarop een activiteit plaatsvond. Bij elke activiteit in de levenscyclus van een incident hoort een timestamp, zodat de gebeurtenissen in chronologische volgorde staan.

Dit attribuut is nodig voor tijdsanalyses met process mining. Je kunt er doorlooptijden tussen activiteiten, de duur van afzonderlijke stappen en de totale oplostijd van incidenten mee berekenen. Door timestamps te analyseren, kunnen organisaties bottlenecks opsporen, controleren of SLA’s worden gehaald en volgen hoe de procesprestaties veranderen. Timestamps vormen de basis voor KPI’s zoals de gemiddelde oplostijd.

Dit attribuut geeft de chronologische volgorde van gebeurtenissen aan. Die is nodig om doorlooptijden te berekenen, bottlenecks op te sporen en procesprestaties over tijd te analyseren.

Te vinden in event logs, tabellen met de auditgeschiedenis of als ‘laatst gewijzigd’ of ‘aanmaakdatum’ op specifieke gerelateerde records.

Het attribuut Bronsysteem geeft aan waar de data vandaan komt. In omgevingen met meerdere ITSM-tools of gekoppelde systemen helpt dit veld om records uit verschillende bronnen van elkaar te onderscheiden.

Dit attribuut wordt niet rechtstreeks gebruikt om de proceskaart te tekenen, maar is wel nuttig voor datavalidatie en gegevensbeheer. Analisten kunnen de data terugleiden naar de bron, mogelijke verschillen tussen systemen onderzoeken en de analyse opdelen. Zo kun je binnen één organisatie incidentbeheerprocessen in ServiceNow en Jira met elkaar vergelijken.

Dit attribuut geeft context over de herkomst van de data. Dat is belangrijk voor datavalidatie, probleemoplossing en vergelijkende analyses in omgevingen met meerdere systemen.

Dit is vaak een vaste waarde die tijdens de data-extractie wordt toegevoegd, of een veld in de tabellen van het bronsysteem.

De timestamp Laatste data-update geeft aan wanneer de data voor het laatst uit het bronsysteem is gehaald of ermee is gesynchroniseerd. Dit metadataveld laat zien hoe actueel de geanalyseerde data is.

Bij process mining helpt dit attribuut om te bepalen hoe actueel de inzichten zijn. Zo weet je of je realtime informatie bekijkt of een momentopname van eerder. Die context is belangrijk voor operationele monitoring en om beslissingen op actuele, relevante data te baseren.

Dit attribuut geeft aan hoe actueel de data is, zodat analisten weten hoe recent de procesanalyse is.

Deze waarde wordt meestal tijdens het data-extractie- en transformatieproces (ETL) gegenereerd en aan elk record toegevoegd.

De ernst geeft aan hoeveel impact een incident heeft op de bedrijfsvoering. Het gaat om de vraag hoe groot het probleem is, los van de urgentie. Een storing in het hele systeem is bijvoorbeeld een incident met hoge ernst, terwijl een kleine visuele fout een lage ernst heeft.

Door incidenten op ernst te analyseren, zien organisaties welke problemen de meeste verstoring veroorzaken. Process mining kan laten zien of incidenten met hoge ernst een andere, efficiëntere route naar een oplossing volgen. Dit attribuut is belangrijk voor oorzaakanalyse en voor het inzetten van middelen bij proactief probleembeheer, zodat ernstige incidenten niet terugkeren.

Door incidenten op impact in te delen, kun je nagaan of problemen met grote gevolgen anders of efficiënter worden opgelost dan problemen met beperkte gevolgen.

Een standaardveld in de incidentregistratie, vaak in combinatie met urgentie gebruikt om de prioriteit te bepalen.

De incidentcategorie biedt een vaste structuur om incidenten op basis van hun aard in te delen. Dit is meestal een hiërarchisch veld waarmee je de classificatie steeds verder kunt verfijnen. Zo kun je incidenten voor rapportages en analyses in logische groepen onderbrengen.

Categorisering is belangrijk voor oorzaakanalyse en trendanalyse. Door proceskaarten per categorie te filteren, kunnen organisaties terugkerende problemen en patronen bij specifieke incidenttypen herkennen. De afhandeling van een software-incident kan er bijvoorbeeld heel anders uitzien dan die van een hardware-incident. Deze data wordt gebruikt voor KPI’s zoals de nauwkeurigheid van de eerste categorisering en het percentage terugkerende incidenten.

Dit attribuut is nodig voor oorzaakanalyse, het herkennen van trends in terugkerende incidenten en het vergelijken van de afhandeling van verschillende problemen.

Dit is een standaardset velden in de incidentregistratie, die vaak verplicht is voor de classificatie.

De incidentstatus geeft aan in welke fase een incident zich op een bepaald moment bevindt. Zo zie je in grote lijnen waar het incident staat in het oplossingsproces. Veelvoorkomende statussen zijn nieuw, toegewezen, in behandeling, in afwachting, opgelost en gesloten.

Dit attribuut is belangrijk voor procesanalyse, omdat statuswijzigingen vaak de activiteiten op de proceskaart bepalen. Door te analyseren hoelang incidenten in elke status blijven, kun je bottlenecks opsporen, bijvoorbeeld incidenten die lang op ‘Pending’ blijven staan. Je kunt de status ook gebruiken om het aantal open incidenten te berekenen en de voortgang richting oplossing te volgen.

Dit attribuut laat zien hoe het incident vordert en wordt vaak gebruikt om activiteiten voor de proceskaart te bepalen. Door de tijd per status te analyseren, kun je vertragingen opsporen.

Meestal beschikbaar als standaardveld in de hoofdregistratie van het incident of in de incidentgeschiedenis.

Het meldingskanaal geeft aan via welke weg het incident is gemeld. Dit attribuut laat zien hoe gebruikers contact opnemen met support, bijvoorbeeld rechtstreeks via de telefoon of automatisch via een systeemmelding.

Door het proces per meldingskanaal te analyseren, kunnen verschillen in efficiëntie zichtbaar worden. Incidenten die via een self-serviceportaal worden gemeld, zijn bijvoorbeeld soms sneller opgelost doordat de informatie vooraf al gestructureerd is. Met deze analyse kunnen organisaties hun supportkanalen verbeteren en het gebruik van efficiëntere kanalen stimuleren.

Dit attribuut helpt om de efficiëntie en afhandelingsroutes van incidenten per meldingsbron te analyseren. De resultaten kunnen richting geven aan de kanaalstrategie en de inzet van middelen.

Deze informatie wordt meestal automatisch vastgelegd of door de medewerker geselecteerd wanneer een incident wordt aangemaakt.

De oplossingsmethode beschrijft de uitkomst van het incident en hoe het is opgelost. Dit kan een gestandaardiseerde code zijn of een vrije beschrijving van de uitgevoerde acties. Voorbeelden zijn ‘Gebruiker geïnformeerd’, ‘Softwarepatch toegepast’, ‘Geen defect gevonden’ en ‘Dubbel incident’.

Dit attribuut geeft belangrijke context bij het einde van het proces. Door incidenten op oplossingsmethode te analyseren, zie je hoe goed verschillende oplossingen werken. Zo kun je gevallen opsporen die zonder echte reparatie worden gesloten en veelgebruikte oplossingen voor specifieke incidentcategorieën herkennen. Die informatie kun je gebruiken voor een kennisbank en om het percentage oplossingen bij het eerste contact te verbeteren.

Dit attribuut laat zien hoe problemen worden opgelost. Daarmee kun je kansen herkennen om werk te automatiseren, de kennisbank te verbeteren en medewerkers op te leiden.

Dit veld wordt meestal ingevuld door de supportmedewerker wanneer de incidentstatus wordt gewijzigd in ‘Resolved’ of ‘Closed’.

Prioriteit is een belangrijk attribuut om het relatieve belang van een incident en de gewenste reactiesnelheid te bepalen. De prioriteit wordt vaak afgeleid van de impact en urgentie van het incident. De niveaus lopen meestal van kritiek tot laag.

Door incidenten op prioriteit te analyseren, zie je hoe het proces met verschillende urgentieniveaus omgaat. Analisten kunnen de oplostijden van incidenten met hoge en lage prioriteit vergelijken om te controleren of SLA’s worden gehaald en middelen goed worden ingezet. Zo kun je bijvoorbeeld nagaan of de meest kritieke incidenten ook echt het snelst worden afgehandeld.

Hiermee kun je procesprestaties bij verschillende urgentieniveaus analyseren en controleren of kritieke incidenten sneller worden afgehandeld dan minder urgente incidenten.

Beschikbaar als standaardveld in de hoofdregistratie van het incident. De prioriteit kan handmatig worden ingesteld of automatisch worden berekend op basis van impact en urgentie.

De toegewezen groep geeft aan welk team op een bepaald moment verantwoordelijk is voor het incident. Incidenten worden vaak tussen groepen doorgestuurd, bijvoorbeeld van de Servicedesk op niveau 1 naar een netwerkteam op niveau 2 of een applicatiesupportteam op niveau 3.

Dit attribuut is belangrijk voor de analyse van overdrachten en werkdruk. Process mining kan laten zien hoe incidenten tussen teams worden doorgegeven, hoelang ze in de wachtrij van elk team staan en waar bottlenecks ontstaan door veelvuldige hertoewijzingen. Zo krijg je antwoord op vragen over teamefficiëntie en samenwerking. De gegevens vormen ook de basis voor het dashboard Analyse van overdrachten en hertoewijzingen.

Dit attribuut is belangrijk om overdrachten tussen teams en wachttijden te analyseren en inzicht te krijgen in de prestaties en werkdruk per team.

Deze informatie staat meestal in de incidentregistratie en wordt bijgewerkt wanneer het incident aan een ander team wordt toegewezen.

De toegewezen medewerker is de persoon die verantwoordelijk is voor een incident. De toegewezen groep geeft aan welk team verantwoordelijk is; de medewerker is degene die aan de oplossing werkt.

Met dit attribuut kun je prestaties en werkdruk op een gedetailleerder niveau analyseren. Door toewijzingen per medewerker te volgen, kunnen managers de productiviteit beoordelen, opleidingsbehoeften vaststellen en het werk evenwichtig verdelen. Process mining kan patronen in hertoewijzingen zichtbaar maken die op groepsniveau verborgen blijven. Ook krijg je inzicht in de bijdrage van individuele medewerkers aan de oplostijd.

Hiermee kun je de werkdruk, prestaties en patronen in hertoewijzingen van individuele medewerkers binnen en tussen teams analyseren.

Dit veld staat in de hoofdregistratie van het incident en wordt bijgewerkt wanneer een medewerker de verantwoordelijkheid overneemt of het incident toegewezen krijgt.

Het aantal hertoewijzingen is een metriek die bijhoudt hoe vaak een incident tijdens de levenscyclus wordt overgedragen. Een hoog aantal wijst vaak op inefficiëntie, een onjuiste eerste routering of onvoldoende kennis binnen supportteams.

Dit attribuut is nuttig voor process mining. Process mining kan hertoewijzingen zichtbaar maken, maar met een vooraf berekend aantal kun je eenvoudig filteren en KPI’s meten. De metriek wordt rechtstreeks gebruikt in het dashboard Analyse van overdrachten en hertoewijzingen. Je kunt er ook ‘pingpong’-situaties mee opsporen, waarbij tickets heen en weer gaan tussen teams. Dat leidt tot langere oplostijden en frustratie bij gebruikers.

Deze metriek maakt inefficiëntie in het proces meetbaar. Een hoog aantal hertoewijzingen hangt vaak samen met langere oplostijden en kan wijzen op problemen met routering of de kennis binnen teams.

Vaak beschikbaar als standaardteller in de incidentregistratie. Ontbreekt die, dan kun je het aantal afleiden door de toewijzingswijzigingen in het auditlog van het incident te tellen.

De aanvrager is degene die het probleem ervaart en de incidentmelding heeft ingediend. Dit kan een interne medewerker of een externe klant zijn. Het attribuut kan ook de afdeling of organisatie van de aanvrager bevatten.

Door incidenten per aanvrager of afdeling te analyseren, kun je zien of bepaalde groepen gebruikers vaker problemen ervaren. Dat kan wijzen op opleidingsbehoeften of lokale problemen met de werkomgeving. Process mining geeft zo een gebruikersgericht beeld van het supportproces en helpt de ervaring van verschillende gebruikersgroepen te begrijpen.

Hiermee kun je het proces vanuit de gebruiker analyseren en nagaan of bepaalde gebruikers, afdelingen of locaties opvallend veel incidenten melden.

Een standaardveld in de incidentregistratie, meestal ingevuld met de gebruiker die het ticket heeft aangemaakt of namens wie het is aangemaakt.

De getroffen service koppelt een incident aan een specifiek onderdeel van de IT-infrastructuur, zoals een bedrijfsapplicatie, server of netwerkapparaat. Vaak is dit gekoppeld aan een Configuration Management Database (CMDB).

Dit attribuut geeft belangrijke bedrijfscontext aan het incident. Met process mining kun je de betrouwbaarheid van specifieke services of bedrijfsmiddelen analyseren. Organisaties kunnen vaststellen welke services de meeste incidenten veroorzaken, de afhandeling ervan analyseren en probleembeheer prioriteren om belangrijke bedrijfsservices stabieler te maken. Zo wordt duidelijker wat de bredere gevolgen van IT-incidenten zijn voor de bedrijfsvoering.

Dit attribuut koppelt incidenten aan specifieke bedrijfsservices of IT-componenten. Zo kun je analyseren welke services het vaakst problemen geven en wat de impact daarvan is.

Meestal gekoppeld vanuit een Configuration Management Database (CMDB) of geselecteerd uit een servicecatalogus op het incidentformulier.

De SLA-status geeft in één oogopslag weer hoe een incident presteert ten opzichte van vooraf bepaalde tijdsdoelen, zoals de reactietijd of de tijd tot oplossing. Veelvoorkomende statussen zijn ‘In behandeling’, ‘Risico’ en ‘Overschreden’.

Dit attribuut meet rechtstreeks de servicekwaliteit en is een belangrijke invoer voor het dashboard Overzicht van SLA-prestaties. Met process mining kun je processtromen van incidenten die de SLA wel en niet hebben overschreden met elkaar vergelijken. Zo zie je welke activiteiten, vertragingen of herstelwerk de SLA-overschrijdingen veroorzaken en kun je gericht verbeteringen doorvoeren.

Dit meet rechtstreeks hoe de prestaties zich verhouden tot de doelen. Door incidenten te analyseren waarbij de SLA is overschreden, zie je welke procesproblemen tot een slechte dienstverlening leiden.

Dit is meestal een berekend veld in de ITSM-tool. De waarde wordt bijgewerkt op basis van de prioriteit en ouderdom van het incident en de ingestelde SLA-regels.