Datatemplate voor incidentbeheer
Datatemplate voor incidentbeheer
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om bij te houden
- Instructies voor data-extractie uit je systeem
Attributen voor incidentbeheer
| Naam | Beschrijving | ||
|---|---|---|---|
|
Incident-ID
IncidentId
|
De unieke identificatiecode van elke incidentregistratie. | ||
|
Beschrijving
Het Incident-ID is de primaire sleutel van elk incident en identificeert het incident vanaf de aanmaak tot de afsluiting. Het koppelt alle bijbehorende activiteiten, logs en wijzigingen aan elkaar, zodat je het volledige verloop van het incident kunt bekijken. Bij process mining is dit attribuut essentieel, omdat het de case bepaalt. Elke gebeurtenis met hetzelfde Incident-ID hoort bij dezelfde procesinstantie. Zo kun je reconstrueren en analyseren hoe afzonderlijke incidenten worden afgehandeld.
Waarom dit belangrijk is
Dit is de unieke case-identificatiecode die alle gebeurtenissen in de levenscyclus van een incident met elkaar verbindt. Zo wordt end-to-endprocesanalyse mogelijk.
Waar vind je dit?
Dit is het veld 'Incident Number' (Field ID: 1000000161) in het formulier 'HPD:Help Desk'.
Voorbeelden
INC000001234567INC000002345678INC000003456789
|
|||
|
Activiteitsnaam
ActivityName
|
De naam van de specifieke gebeurtenis of taak die plaatsvond tijdens de levenscyclus van het incident. | ||
|
Beschrijving
Dit attribuut beschrijft welke activiteit op een bepaald moment voor een incident is uitgevoerd, zoals 'Incident gemeld', 'Groep toegewezen' of 'Incident opgelost'. Deze activiteiten vormen de bouwstenen van de proceskaart. Door de volgorde en frequentie van activiteiten te analyseren, zie je hoe het proces werkelijk verloopt, welke routes vaak voorkomen en waar het proces afwijkt van de standaardprocedure. Dit is belangrijk om te begrijpen welke acties worden uitgevoerd om een incident op te lossen.
Waarom dit belangrijk is
Activiteiten bepalen de stappen op de proceskaart en maken het mogelijk de workflow voor incidentbeheer te visualiseren en analyseren.
Waar vind je dit?
Meestal afgeleid uit wijzigingen in 'Status' (Field ID: 7) en 'Status_Reason' in het formulier 'HPD:Help Desk', of uit het formulier 'HPD:Help Desk Audit Log'.
Voorbeelden
Incident gemeldGroep toegewezenOplossing doorgevoerdIncident afgesloten
|
|||
|
Timestamp van gebeurtenis
EventTimestamp
|
De exacte datum en tijd waarop de activiteit plaatsvond. | ||
|
Beschrijving
Deze timestamp legt vast wanneer een specifieke gebeurtenis in de levenscyclus van een incident plaatsvond. De chronologische volgorde maakt het mogelijk om het procesverloop uit ruwe data te reconstrueren. De timestamp van een gebeurtenis is nodig voor alle tijdsanalyses. Je gebruikt deze om doorlooptijden tussen activiteiten te berekenen, bottlenecks op te sporen waar incidenten lang wachten en de totale oplostijd te meten. De timestamp vormt de tijdsbasis voor de procesanalyse.
Waarom dit belangrijk is
Deze timestamp geeft de chronologische volgorde van gebeurtenissen aan. Dat is nodig om doorlooptijden te berekenen, bottlenecks op te sporen en het verloop van het proces te begrijpen.
Waar vind je dit?
Het veld 'Last Modified Date' (Field ID: 6) of specifieke datumvelden uit het formulier 'HPD:Help Desk'. Bij historische gebeurtenissen komt de timestamp uit het timestampveld van het auditlog.
Voorbeelden
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
Incidentcategorie
IncidentCategory
|
De classificatie van het incident, vaak opgebouwd uit meerdere niveaus. | ||
|
Beschrijving
Met incidentcategorisatie classificeer je incidenten volgens een vaste structuur, meestal met meerdere niveaus (bijvoorbeeld niveau 1: hardware, niveau 2: laptop, niveau 3: batterij). Deze data is belangrijk voor routering, rapportages en trendanalyses. Bij process mining kun je met categorisatie verschillende soorten incidenten apart analyseren. Het dashboard voor de nauwkeurigheid van incidentcategorisatie vergelijkt de oorspronkelijke en uiteindelijke categorie. Ook helpt categorisatie trends te vinden voor het dashboard met trends in oorzaken.
Waarom dit belangrijk is
Met categorisatie kun je incidenten goed routeren, trends analyseren en prestaties van verschillende soorten incidenten vergelijken.
Waar vind je dit?
Dit zijn de velden 'Operational Categorization Tier 1/2/3' in het formulier 'HPD:Help Desk'.
Voorbeelden
Hardware > Laptop > BatterijSoftware > Bedrijfsapplicatie > AanmeldfoutNetwerk > Verbinding > Wifi
|
|||
|
Incidentstatus
IncidentStatus
|
De huidige of historische status van het incident op het moment van de gebeurtenis. | ||
|
Beschrijving
Dit attribuut geeft de status van het incident aan, zoals 'New', 'In Progress', 'Pending', 'Resolved' of 'Closed'. Het laat zien waar het incident zich in de levenscyclus bevindt. Statuswijzigingen analyseren is belangrijk om het incidentbeheerproces te begrijpen. Je gebruikt ze om activiteiten te bepalen, de tijd in verschillende statussen te meten, bijvoorbeeld hoelang incidenten op 'Pending' staan, en incidenten op te sporen die mogelijk vastzitten of niet meer actief zijn.
Waarom dit belangrijk is
Statuswijzigingen bijhouden is belangrijk om de voortgang van een incident te begrijpen en te meten hoelang het in een bepaalde status blijft, zoals 'Pending' of 'In Progress'.
Waar vind je dit?
Dit is het veld 'Status' (Field ID: 7) in het formulier 'HPD:Help Desk'.
Voorbeelden
NieuwToegewezenIn behandelingIn afwachtingOpgelostAfgesloten
|
|||
|
Opnieuw geopend
IsReopened
|
Een indicator die aangeeft of een incident opnieuw is geopend nadat de status op 'Resolved' was gezet. | ||
|
Beschrijving
Dit booleaanse attribuut is waar als de status van een incident weer actief wordt, bijvoorbeeld 'In Progress', nadat het als 'Resolved' is gemarkeerd. Dit betekent dat de eerste oplossing niet werkte of niet volledig was. Dit meet herstelwerk rechtstreeks en wordt gebruikt om de KPI 'Percentage opnieuw geopende incidenten' te berekenen. Door opnieuw geopende incidenten te analyseren, kun je oplossingen van lage kwaliteit, onvoldoende tests of terugkerende problemen vinden die niet goed zijn aangepakt. Dit ondersteunt het dashboard met herstel- en escalatieroutes.
Waarom dit belangrijk is
Meet herstelwerk en de kwaliteit van oplossingen rechtstreeks. Een hoog percentage opnieuw geopende incidenten wijst op ineffectieve oplossingen en zwakke plekken in het proces.
Waar vind je dit?
Berekend door de activiteitenreeks van een incident te analyseren. Als na de activiteit 'Incident Reopened' of een vergelijkbare activiteit de activiteit 'Resolution Implemented' voorkomt, wordt deze indicator op waar gezet.
Voorbeelden
truefalse
|
|||
|
Prioriteit
Priority
|
De prioriteit van het incident, die bepaalt hoe snel het moet worden afgehandeld. | ||
|
Beschrijving
De prioriteit wordt meestal bepaald door de impact en urgentie samen en bepaalt de volgorde en snelheid waarmee incidenten worden opgelost. Veelgebruikte waarden lopen van 'Kritiek' tot 'Laag'. Bij process mining is het belangrijk om incidenten per prioriteit te analyseren. Zo kun je vragen beantwoorden als: 'Halen we de SLA’s voor incidenten met hoge prioriteit?' en 'Lopen incidenten met lage prioriteit meer vertraging op?'. Door op prioriteit te filteren, kun je je richten op de belangrijkste bedrijfsproblemen.
Waarom dit belangrijk is
Dit attribuut is essentieel om analyses op te splitsen, zodat incidenten met hoge prioriteit sneller worden afgehandeld en aan de bijbehorende serviceniveaudoelen voldoen.
Waar vind je dit?
Dit is het veld 'Priority' (Field ID: 1000000164) in het formulier 'HPD:Help Desk'.
Voorbeelden
KritiekHoogGemiddeldLaag
|
|||
|
Service
Service
|
De bedrijfs- of technische service die door het incident is getroffen. | ||
|
Beschrijving
Dit attribuut koppelt een incident aan een specifieke service in de Configuration Management Database (CMDB), zoals 'E-mailservice', 'VPN-toegang' of 'SAP Financials'. Deze koppeling helpt je de impact van incidenten op de bedrijfsvoering te begrijpen. Door incidenten per service te analyseren, zie je welke services veel incidenten veroorzaken en welke problemen steeds terugkomen bij bepaalde technologieën. Ook ondersteunt dit trendanalyses voor probleembeheer.
Waarom dit belangrijk is
Door incidenten aan bedrijfsservices te koppelen, kun je de impact analyseren en zien welke services het vaakst problemen geven.
Waar vind je dit?
Dit is het veld 'ServiceCI' of een vergelijkbaar veld voor het getroffen configuratie-item (CI) in het formulier 'HPD:Help Desk'.
Voorbeelden
Bedrijfse-mailSAP ERPVPN voor externe toegangPersoneelsportaal
|
|||
|
SLA overschreden
IsSlaBreached
|
Een indicator die aangeeft of het incident na de SLA-streefdatum is opgelost. | ||
|
Beschrijving
Dit booleaanse attribuut is waar als de oplostijd van het incident de vastgelegde SLA overschrijdt. Per incident geeft het een duidelijke ja-of-nee-uitkomst voor de SLA-prestaties. Deze indicator is nodig voor het dashboard Overzicht van SLA-prestaties voor incidenten en voor de berekening van de KPI 'Percentage incidenten dat aan de SLA voldoet'. Je kunt eenvoudig filteren op incidenten die hun serviceniveaudoelen niet hebben gehaald en de oorzaken onderzoeken.
Waarom dit belangrijk is
Met deze indicator analyseer je SLA-compliance eenvoudiger. Je kunt alle incidenten filteren waarbij de SLA is overschreden en de oorzaken onderzoeken.
Waar vind je dit?
Berekend door de timestamp van de gebeurtenis 'Incident Resolved' te vergelijken met 'SlaTargetDate'. Als de timestamp van de oplossing na de streefdatum valt, is deze indicator waar.
Voorbeelden
truefalse
|
|||
|
Toegewezen groep
AssignedGroup
|
De supportgroep die verantwoordelijk is voor de afhandeling van het incident. | ||
|
Beschrijving
Dit attribuut geeft aan welk team of welke afdeling het incident afhandelt, bijvoorbeeld 'Servicedesk', 'Netwerkteam' of 'Databasebeheerders'. Door toewijzingen bij te houden, krijg je inzicht in de werkverdeling tussen teams. Met dit attribuut analyseer je overdrachten tussen teams, spoor je bottlenecks op die door specifieke groepen ontstaan en meet je het percentage incidenten dat opnieuw wordt toegewezen. Ook maakt het zichtbaar welke route een incident door de organisatie aflegt en waar de routering inefficiënt is of kennis ontbreekt.
Waarom dit belangrijk is
Door bij te houden aan welke groep een incident is toegewezen, kun je overdrachten analyseren, herhaalde toewijzingen opsporen en bottlenecks binnen specifieke teams vinden.
Waar vind je dit?
Dit is het veld 'Assigned Group' (Field ID: 1000000217) in het formulier 'HPD:Help Desk'.
Voorbeelden
ServicedeskNetwerkbeheerApplicatieondersteuning niveau 2Infrastructuurdiensten
|
|||
|
Toegewezen medewerker
Assignee
|
De medewerker die aan het incident is toegewezen. | ||
|
Beschrijving
De toegewezen medewerker is de specifieke supportmedewerker of technicus die op een bepaald moment verantwoordelijk is voor het incident. Dit geeft meer detail dan de toegewezen groep. Door prestaties per medewerker te analyseren, zie je wie goed presteert, wie mogelijk extra training nodig heeft en hoe het werk is verdeeld. Ook kun je precies nagaan welke acties medewerkers hebben uitgevoerd bij een complex incident.
Waarom dit belangrijk is
Geeft gedetailleerd inzicht in de werkverdeling en individuele prestaties. Zo zie je wie goed presteert en wie ondersteuning nodig heeft.
Waar vind je dit?
Dit is het veld 'Assignee' (Field ID: 1000000218) in het formulier 'HPD:Help Desk'.
Voorbeelden
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Aantal nieuwe toewijzingen
ReassignmentCount
|
Het totale aantal keer dat een incident aan een andere groep is toegewezen. | ||
|
Beschrijving
Deze metriek telt hoe vaak het veld 'AssignedGroup' tijdens de levenscyclus van het incident is gewijzigd. Een hoog aantal kan wijzen op problemen met de eerste routering, weinig oplossingen bij het eerste contact of complexe problemen waarvoor meerdere teams nodig zijn. Dit attribuut ondersteunt rechtstreeks de KPI 'Percentage opnieuw toegewezen incidenten' en het dashboard 'Analyse van de toewijzingscyclus van incidenten'. Het maakt het heen-en-weer doorsturen van tickets tussen teams meetbaar. Dat leidt vaak tot flinke vertragingen en een inefficiënt proces.
Waarom dit belangrijk is
Maakt inefficiënte routering en overdrachten meetbaar. Zo kun je incidenten vinden die vastlopen doordat ze steeds opnieuw tussen teams worden toegewezen.
Waar vind je dit?
Berekend door in het event log te tellen hoe vaak de waarde van 'AssignedGroup' verandert voor een bepaalde Incident ID.
Voorbeelden
0135
|
|||
|
Afsluitcode
CloseCode
|
De code die bij het sluiten van een incident wordt geselecteerd en aangeeft wat de uitkomst van de oplossing is. | ||
|
Beschrijving
De afsluitcode geeft op een vaste manier aan hoe een incident is opgelost. Voorbeelden zijn 'Door gebruiker opgelost', 'Geen probleem gevonden', 'Dubbel incident' en 'Definitieve oplossing toegepast'. Met dit attribuut analyseer je hoe effectief oplossingen zijn en wat de uitkomst is. Je kunt bijvoorbeeld incidenten vinden die zonder echte oplossing zijn gesloten, of categorieën waarin gebruikers vaak zelf hun probleem oplossen. Dat kan aanleiding zijn om betere kennisbankartikelen of self-servicefuncties aan te bieden.
Waarom dit belangrijk is
Geeft gestructureerde data over de uitkomst van oplossingen. Zo kun je de effectiviteit van oplossingen analyseren en trends zien in de manier waarop incidenten worden gesloten.
Waar vind je dit?
Dit staat meestal bij de oplossings- of afsluitgegevens in het formulier 'HPD:Help Desk'.
Voorbeelden
Op afstand opgelostDubbel probleemGebruikersfoutGeen actie nodig
|
|||
|
Beschrijving van de oplossing
Resolution
|
Een beschrijving in vrije tekst van de stappen waarmee het incident is opgelost. | ||
|
Beschrijving
Dit veld bevat een gedetailleerde, door een medewerker geschreven samenvatting van de uiteindelijke oplossing. Er staat in wat is gedaan om het probleem op te lossen en de service voor de gebruiker te herstellen. De tekst is niet gestructureerd, maar je kunt die met tekstanalyse onderzoeken om veelvoorkomende oplossingspatronen te vinden, trefwoorden voor specifieke problemen te herkennen of de oorzaakanalyse aan te vullen. Zo krijg je context die vaak ontbreekt in gestructureerde datavelden.
Waarom dit belangrijk is
Geeft kwalitatieve informatie over de oplossing. Met tekstanalyse kun je patronen vinden die niet zichtbaar zijn in gestructureerde data.
Waar vind je dit?
Dit is het veld 'Resolution' (Field ID: 1000000156) in het formulier 'HPD:Help Desk'.
Voorbeelden
Het wachtwoord van de gebruiker is opnieuw ingesteld via Active Directory.De cache en cookies in de browser zijn gewist. Daarmee is het aanmeldprobleem opgelost.De netwerkswitch in IDF-kast 3B is opnieuw opgestart.
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de incidentdata is opgehaald. | ||
|
Beschrijving
Dit attribuut geeft aan waar de data vandaan komt. Dat is vooral handig in omgevingen met meerdere ITSM-tools of gekoppelde systemen. Het bevestigt dat de data uit de verwachte bron komt, bijvoorbeeld een specifieke BMC Helix ITSM-instantie. Bij analyses helpt dit attribuut om processen of data-eigenschappen te onderscheiden die kunnen verschillen tussen productie-, ontwikkel- of oudere systemen. Zo blijft de herkomst van de data duidelijk en betrouwbaar.
Waarom dit belangrijk is
Geeft de herkomst van de data aan. Dit is belangrijk voor datavalidatie en voor analyses van meerdere gekoppelde systemen.
Waar vind je dit?
Dit is meestal een vaste waarde die tijdens het ETL-proces (extractie, transformatie en laden) aan de data wordt toegevoegd.
Voorbeelden
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
|
|||
|
Impact
Impact
|
De mate waarin het incident bedrijfsprocessen beïnvloedt. | ||
|
Beschrijving
Impact geeft aan hoe groot de nadelige gevolgen van een incident voor de bedrijfsvoering zijn. Vaak wordt dit op een schaal aangegeven, bijvoorbeeld 'Uitgebreid/organisatiebreed', 'Aanzienlijk/groot', 'Gemiddeld/beperkt' of 'Klein/lokaal'. Samen met urgentie bepaalt de impact de prioriteit van het incident. Door incidenten op impact te analyseren, zie je welke de bedrijfsvoering het meest verstoren, ongeacht de technische complexiteit. Dat helpt om verbeteringen in processen te prioriteren.
Waarom dit belangrijk is
Helpt de ernst van een incident voor de bedrijfsvoering te bepalen. Dit is belangrijk voor de prioriteit en om analyses te richten op incidenten met veel impact.
Waar vind je dit?
Dit is het veld 'Impact' (Field ID: 1000000163) in het formulier 'HPD:Help Desk'.
Voorbeelden
1-Uitgebreid/organisatiebreed2-Aanzienlijk/groot3-Gemiddeld/beperkt4-Klein/lokaal
|
|||
|
Kanaal
Channel
|
De manier waarop het incident is gemeld. | ||
|
Beschrijving
Dit attribuut geeft aan hoe het incident is gemeld, bijvoorbeeld telefonisch, per e-mail, via een self-serviceportaal of persoonlijk aan de balie. Het laat zien via welk kanaal het incident in het supportproces terechtkwam. Door incidenten per kanaal te analyseren, zie je welke kanalen het effectiefst zijn en via welke kanalen incidenten makkelijker of juist moeilijker op te lossen zijn. De analyse kan ook helpen bepalen waar je investeert in automatisering of gebruikerstraining. Je kunt bijvoorbeeld het gebruik van een self-serviceportaal stimuleren dat bij de eerste melding betere data verzamelt.
Waarom dit belangrijk is
Als je weet via welk kanaal incidenten worden gemeld, kun je de efficiëntie van de verschillende intakekanalen analyseren en bepalen waar investeringen in self-service of automatisering zinvol zijn.
Waar vind je dit?
Dit is het veld 'Reported Source' (Field ID: 1000000215) in het formulier 'HPD:Help Desk'.
Voorbeelden
E-mailTelefoonSelf-serviceRechtstreeks ingevoerd
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst uit het bronsysteem is bijgewerkt. | ||
|
Beschrijving
Dit attribuut registreert de datum en tijd van de meest recente data-extractie. Zo zie je hoe actueel de geanalyseerde data is en hoe recent de procesinzichten zijn. De tijd van de laatste update is belangrijk voor rapportages en dashboards. Gebruikers zien zo hoe actueel de data is en weten of de meest recente incidentactiviteiten al zijn opgenomen.
Waarom dit belangrijk is
Geeft aan hoe actueel de data is, zodat gebruikers weten hoe recent de procesanalyse en de bijbehorende inzichten zijn.
Waar vind je dit?
Deze waarde wordt meestal tijdens het data-extractieproces (ETL) gegenereerd en aan de dataset toegevoegd.
Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
Melder
Submitter
|
De persoon die het incident als eerste heeft gemeld. | ||
|
Beschrijving
De melder is de eindgebruiker of klant die het probleem heeft ervaren en gemeld. Dit is niet dezelfde persoon als de toegewezen medewerker, die het incident afhandelt. Door data per melder of afdeling te analyseren, kun je gebruikersgroepen vinden die extra training nodig hebben of groepen die door een bepaald type probleem worden getroffen. Zo bekijk je incidentbeheer vanuit het perspectief van de klant.
Waarom dit belangrijk is
Geeft aan wie het probleem heeft gemeld. Zo kun je trends vinden per afdeling, locatie of functie van de gebruiker.
Waar vind je dit?
Deze informatie staat in het veld 'Submitter' of in velden met klantgegevens in het formulier 'HPD:Help Desk'.
Voorbeelden
John DoeJane SmithPeter Jones
|
|||
|
Oorzaak
RootCause
|
De onderliggende reden of uiteindelijke oorzaak van het incident. | ||
|
Beschrijving
De hoofdoorzaak is het onderliggende probleem dat, als je het aanpakt, voorkomt dat het incident opnieuw optreedt. Vaak wordt deze vastgesteld tijdens het onderzoek naar een gerelateerd probleem. Niet bij elk incident is de hoofdoorzaak vastgelegd. Toch is analyse van dit attribuut belangrijk voor proactief probleembeheer. Het ondersteunt de KPI 'Percentage vastgestelde hoofdoorzaken' en helpt dashboards te maken die trends in terugkerende problemen volgen. Zo kun je werken aan blijvende oplossingen.
Waarom dit belangrijk is
De hoofdoorzaak vaststellen is belangrijk voor probleembeheer en voor analyses die gericht zijn op het terugdringen van terugkerende incidenten.
Waar vind je dit?
Deze informatie staat mogelijk in een apart veld 'Root Cause' bij het incident, maar meestal in een gekoppeld formulier 'PBI:Problem Investigation'.
Voorbeelden
Onvoldoende schijfruimte op de serverFout in de netwerkconfiguratieSoftwarefout in versie 2.1Verlopen beveiligingscertificaat
|
|||
|
SLA-streefdatum
SlaTargetDate
|
De datum en tijd waarop het incident volgens de SLA naar verwachting is opgelost. | ||
|
Beschrijving
Dit attribuut bevat de deadline voor het oplossen van het incident, zoals vastgelegd in de toepasselijke Service Level Agreement (SLA). De deadline wordt berekend op basis van de prioriteit van het incident en de afgesproken servicetijden. Deze timestamp is het referentiepunt voor de vergelijking met de werkelijke oplostijd. De timestamp is nodig om de KPI 'Percentage incidenten dat aan de SLA voldoet' te berekenen en dashboards over SLA-prestaties te maken. Zo kun je incidenten volgen die hun deadline naderen.
Waarom dit belangrijk is
Dit is het referentiepunt voor het meten van SLA-compliance. Hiermee kun je bepalen of een incident op tijd is opgelost of dat de SLA is overschreden.
Waar vind je dit?
Deze data staat meestal in het formulier 'SLM:Measurement' en is gekoppeld aan het incident. Het is geen rechtstreeks veld in 'HPD:Help Desk'.
Voorbeelden
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
Activiteiten voor incidentbeheer
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Groep toegewezen
|
Deze activiteit markeert de eerste toewijzing van het incident aan een specifieke supportgroep voor onderzoek. Dit wordt afgeleid uit het eerste moment waarop het veld 'Assigned Group' na het aanmaken van het incident wordt ingevuld. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal: het actieve werk begint. De tijd tot de eerste toewijzing bijhouden is belangrijk om reactietijden en de efficiëntie van de eerste routering te beoordelen.
Waar vind je dit?
Afgeleid uit het auditlog ('HPD:HelpDesk_AuditLogSystem') van het formulier 'HPD:Help Desk'. Hierin wordt bijgehouden wanneer het veld 'Assigned Group' voor het eerst wordt ingevuld.
Vastleggen
Op basis van de timestamp waarop het veld 'Assigned Group' voor het eerst wordt ingevuld.
Gebeurtenistype
inferred
|
|||
|
Incident afgesloten
|
Dit is de laatste activiteit: de incidentregistratie wordt formeel afgesloten nadat de oplossing is bevestigd of de bevestigingsperiode is verstreken. De activiteit wordt vastgelegd wanneer de status op 'Closed' wordt gezet. | ||
|
Waarom dit belangrijk is
Dit is de definitieve eindgebeurtenis in de levenscyclus van een incident. De tijd tussen 'Resolved' en 'Closed' is de periode voor bevestiging door de gebruiker en administratieve afronding.
Waar vind je dit?
Deze gebeurtenis komt overeen met het instellen van het veld 'Status' op 'Closed' in het formulier 'HPD:Help Desk'. De timestamp wordt vastgelegd in het veld 'Closed Date' en in het auditlog.
Vastleggen
Op basis van de timestamp in 'Closed Date' of de statuswijziging naar 'Closed'.
Gebeurtenistype
inferred
|
|||
|
Incident gemeld
|
Deze activiteit markeert het moment waarop de incidentregistratie in het systeem wordt aangemaakt. Dit wordt vastgesteld aan de hand van de aanmaaktimestamp van het incident in het hoofdformulier voor incidentbeheer. | ||
|
Waarom dit belangrijk is
Dit is de primaire startgebeurtenis van de levenscyclus van een incident. Deze is nodig om de totale oplostijd en het aantal binnenkomende incidenten te berekenen.
Waar vind je dit?
Deze gebeurtenis komt overeen met het aanmaken van een registratie in het formulier 'HPD:Help Desk'. De timestamp komt meestal uit het veld 'Submit Date' of 'Reported Date'.
Vastleggen
Op basis van de timestamp in 'Submit Date' van het formulier HPD:Help Desk.
Gebeurtenistype
explicit
|
|||
|
Incident opgelost
|
Deze activiteit markeert de officiële oplossing van het incident vanuit het perspectief van de servicedesk, vóór de definitieve afsluiting. De activiteit wordt vastgelegd wanneer de status van het incident op 'Resolved' wordt gezet. | ||
|
Waarom dit belangrijk is
Dit is de belangrijkste mijlpaal voor het meten van SLA-naleving en de oplostijd. Het geeft aan dat de dienstverlening voor de gebruiker is hersteld.
Waar vind je dit?
Deze gebeurtenis komt overeen met het instellen van het veld 'Status' op 'Resolved' in het formulier 'HPD:Help Desk'. De timestamp staat in het veld 'Last Resolved Date' en in het auditlog.
Vastleggen
Op basis van de timestamp van de statuswijziging naar 'Resolved' in het auditlog.
Gebeurtenistype
inferred
|
|||
|
Onderzoek gestart
|
Dit geeft aan dat een supportmedewerker actief aan het incident is gaan werken. Dit wordt meestal afgeleid uit een statuswijziging van 'Assigned' naar 'In Progress'. | ||
|
Waarom dit belangrijk is
Deze mijlpaal markeert de overgang van wachten in een wachtrij naar actieve diagnose. Door te analyseren hoe lang het duurt voordat het onderzoek begint, kun je capaciteitsbottlenecks opsporen. Dit ondersteunt het dashboard 'Bottlenecks bij diagnose en onderzoek'.
Waar vind je dit?
Afgeleid uit een statuswijziging in het formulier 'HPD:Help Desk'. De gebeurtenis vindt plaats wanneer het veld 'Status' verandert in 'In Progress'. De timestamp komt uit het auditlog.
Vastleggen
Afgeleid uit de statuswijziging naar 'In Progress' in HPD:HelpDesk_AuditLogSystem.
Gebeurtenistype
inferred
|
|||
|
Bevestiging van gebruiker ontvangen
|
Dit geeft aan dat de gebruiker actief bevestigt dat de oplossing het probleem heeft verholpen. Dit kan een expliciete gebeurtenis zijn of worden afgeleid uit notities of een gerelateerde systeemactie vóór de afsluiting. | ||
|
Waarom dit belangrijk is
Door dit bij te houden, krijg je een nauwkeuriger beeld van de controle door de gebruiker dan wanneer je alleen wacht op automatische afsluiting. Je kunt hiermee de KPI 'Gemiddelde tijd tot bevestiging door gebruiker' meten en communicatieproblemen opsporen.
Waar vind je dit?
Dit is lastig betrouwbaar vast te leggen. Je kunt het mogelijk afleiden uit een werklognotitie of een specifieke wijziging van de statusreden vlak voordat het incident de status 'Closed' krijgt. Mogelijk moet je hiervoor het formulier 'HPD:WorkLog' analyseren.
Vastleggen
Afgeleid uit specifieke werklognotities of wijzigingen van de statusreden vóór de afsluiting.
Gebeurtenistype
inferred
|
|||
|
Incident geannuleerd
|
Deze activiteit staat voor het beëindigen van een incident dat per ongeluk is aangemaakt of niet meer relevant is. De activiteit wordt vastgelegd wanneer de status van het incident op 'Cancelled' wordt gezet. | ||
|
Waarom dit belangrijk is
Dit is een eindstatus voor een incident en staat los van een succesvolle oplossing. Door geannuleerde incidenten te analyseren, kun je problemen met kanalen voor incidentregistratie of dubbele meldingen opsporen.
Waar vind je dit?
Afgeleid uit het formulier 'HPD:Help Desk' wanneer het veld 'Status' wordt bijgewerkt naar 'Cancelled'. De timestamp staat in het auditlog.
Vastleggen
Afgeleid uit de statuswijziging naar 'Cancelled' in het auditlog.
Gebeurtenistype
inferred
|
|||
|
Incident gecategoriseerd
|
Dit is het moment waarop het incident is ingedeeld op basis van operationele en productcategorieën en een prioriteit heeft gekregen. Dit wordt meestal afgeleid uit het invullen of de laatste wijziging van de categorisatievelden. | ||
|
Waarom dit belangrijk is
Een juiste en tijdige categorisatie is belangrijk voor een efficiënte routering en rapportage. Door deze activiteit te analyseren, kun je vertragingen of fouten in de eerste triage opsporen. Dit ondersteunt het dashboard 'Nauwkeurigheid incidentcategorisatie'.
Waar vind je dit?
Afgeleid uit het auditlog ('HPD:HelpDesk_AuditLogSystem'), waarin wijzigingen worden bijgehouden in velden zoals 'Operational Categorization Tier 1-3', 'Product Categorization Tier 1-3' en 'Priority' van het formulier 'HPD:Help Desk'.
Vastleggen
Op basis van de timestamp van de laatste wijziging van categorisatie- of prioriteitsvelden na het aanmaken.
Gebeurtenistype
inferred
|
|||
|
Incident heropend
|
Dit is een incident dat eerder als opgelost is gemarkeerd, maar opnieuw actief is omdat het probleem nog bestaat. Dit wordt afgeleid uit een statuswijziging van 'Resolved' naar een actieve status, zoals 'In Progress' of 'Assigned'. | ||
|
Waarom dit belangrijk is
Deze activiteit meet rechtstreeks hoeveel herstelwerk nodig is en hoe goed de eerste oplossingen werken. Een groot aantal heropende incidenten wijst vaak op oplossingen van lage kwaliteit en ondersteunt de KPI 'Percentage incidenten met herstelwerk'.
Waar vind je dit?
Afgeleid uit het auditlog ('HPD:HelpDesk_AuditLogSystem') door voor een Incident-ID een statuswijziging van 'Resolved' naar 'In Progress' of 'Assigned' op te sporen.
Vastleggen
Afgeleid uit een statuswijziging van 'Resolved' naar een actieve status.
Gebeurtenistype
inferred
|
|||
|
Oplossing doorgevoerd
|
Deze activiteit geeft aan dat het supportteam een oplossing of workaround heeft toegepast. Dit wordt vaak afgeleid uit een statuswijziging naar 'Resolved'. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal: er is een oplossing geleverd. Het is een belangrijk datapunt om te meten hoelang het duurt om een oplossing toe te passen nadat het onderzoek is afgerond.
Waar vind je dit?
Dit wordt meestal afgeleid uit een wijziging van 'Status' naar 'Resolved' in het formulier 'HPD:Help Desk'. De timestamp staat in het veld 'Last Resolved Date' en in het auditlog.
Vastleggen
Op basis van de timestamp in 'Last Resolved Date' of de statuswijziging naar 'Resolved'.
Gebeurtenistype
inferred
|
|||
|
Overgedragen aan een andere groep
|
Deze activiteit vindt plaats wanneer een incident van de ene supportgroep naar een andere wordt overgedragen. Dit wordt afgeleid uit een wijziging van het veld 'Assigned Group' na de eerste toewijzing. | ||
|
Waarom dit belangrijk is
Veel overdrachten wijzen op een verkeerde eerste routering of ontbrekende kennis. Deze activiteit bijhouden is belangrijk voor het dashboard 'Analyse van herverdelingen van incidenten' en de KPI 'Percentage herverdelingen van incidenten'.
Waar vind je dit?
Afgeleid uit het auditlog ('HPD:HelpDesk_AuditLogSystem') door latere wijzigingen in het veld 'Assigned Group' van het formulier 'HPD:Help Desk' op te sporen, nadat dit veld voor het eerst is ingevuld.
Vastleggen
Spoor wijzigingen in het veld 'Assigned Group' op die na de eerste toewijzing plaatsvinden.
Gebeurtenistype
inferred
|
|||
|
SLA overschreden
|
Dit is een berekende gebeurtenis die plaatsvindt wanneer de oplostijd van een incident langer is dan de afgesproken servicetermijn. De gebeurtenis wordt bepaald door de oplostimestamp te vergelijken met de SLA-deadline. | ||
|
Waarom dit belangrijk is
Deze activiteit vormt de basis voor het dashboard 'Overzicht van SLA-prestaties voor incidenten' en de KPI 'SLA-nalevingspercentage voor incidenten'. De activiteit markeert incidenten die niet binnen de afgesproken termijn zijn opgelost.
Waar vind je dit?
Berekend door 'Last Resolved Date' te vergelijken met 'Target Date' (SLA Due Date) in het formulier 'HPD:Help Desk'. Als het incident nog niet is opgelost, kan de huidige tijd als vergelijkingspunt dienen.
Vastleggen
Berekende gebeurtenis: vindt plaats als 'Last Resolved Date' > 'Target Date'.
Gebeurtenistype
calculated
|
|||
|
Wacht op bevestiging van gebruiker
|
Dit gebeurt nadat een oplossing is doorgevoerd en het supportteam wacht tot de gebruiker bevestigt dat het probleem is verholpen. Dit wordt vaak weergegeven met de status 'Resolved'. Vanaf dat moment begint de timer voor automatische afsluiting. | ||
|
Waarom dit belangrijk is
Deze activiteit is belangrijk voor het dashboard 'Vertragingen bij bevestiging en controle door gebruiker'. Je kunt hiermee meten hoeveel tijd er zit tussen het leveren van een oplossing en de bevestiging door de gebruiker. Die wachttijd kan de levenscyclus van een incident onnodig verlengen.
Waar vind je dit?
Deze status begint wanneer 'Status' in het formulier 'HPD:Help Desk' verandert in 'Resolved'. De duur wordt gemeten vanaf 'Last Resolved Date' tot het incident de status 'Closed' krijgt of opnieuw wordt geopend.
Vastleggen
Begint bij de statuswijziging naar 'Resolved' en eindigt bij de statuswijziging naar 'Closed' of 'In Progress'.
Gebeurtenistype
inferred
|
|||
|
Wacht op informatie van gebruiker
|
Dit is het moment waarop de voortgang van het incident wordt onderbroken in afwachting van informatie of actie van de gebruiker. Dit wordt afgeleid uit een statuswijziging naar 'Pending'. | ||
|
Waarom dit belangrijk is
Met deze activiteit kun je de werktijd van medewerkers onderscheiden van de wachttijd op de gebruiker. Door te analyseren hoelang een incident deze status heeft, zie je hoe vertragingen in reacties de totale oplostijd beïnvloeden.
Waar vind je dit?
Afgeleid uit het formulier 'HPD:Help Desk' wanneer het veld 'Status' wordt bijgewerkt naar 'Pending'. De specifieke reden staat vaak in het veld 'Status_Reason'.
Vastleggen
Afgeleid uit de statuswijziging naar 'Pending' in HPD:HelpDesk_AuditLogSystem.
Gebeurtenistype
inferred
|
|||
Extractiegidsen
Klaar om te beginnen?
Gebruik deze template als startpunt voor process mining en ontdek wat de data over incidentbeheer laat zien. Begin vandaag met het optimaliseren van je bedrijfsvoering.
Los terugkerende incidenten in BMC Helix ITSM vandaag nog op!
Verlaag de MTTR met 35% en voorkom SLA-overschrijdingen, zodat gebruikers tevredener zijn.
Geen creditcard nodig. Gratis proefperiode van 14 dagen.