Data template: Incident Management
Uw Incident Management-datatemplate
- Aanbevolen attributen om vast te leggen
- Belangrijke activiteiten om te volgen voor uw proces
- Extractiebegeleiding voor uw datasysteem
Incident Management Attributes
| Naam | Beschrijving | ||
|---|---|---|---|
|
Incident-ID
IncidentId
|
De unieke identifier voor elke incidentrecord. | ||
|
Beschrijving
De Incident ID dient als de primaire sleutel voor elk incident en identificeert het uniek van aanmaak tot afsluiting. Het koppelt alle gerelateerde activiteiten, logs en wijzigingen, wat een compleet, end-to-end overzicht van de lifecycle van het incident mogelijk maakt. Binnen Process Mining is dit attribute fundamenteel, omdat het de case definieert. Elke event met dezelfde Incident ID wordt beschouwd als onderdeel van dezelfde process instance, wat de reconstructie en analyse van de afhandeling van individuele incidenten mogelijk maakt.
Waarom het belangrijk is
Dit is de essentiële case-identifier die alle events in de lifecycle van een incident verbindt, waardoor end-to-end procesanalyse mogelijk wordt.
Waar te verkrijgen
Dit is het 'Incident Number' veld (Field ID: 1000000161) in het 'HPD:Help Desk' formulier.
Voorbeelden
INC000001234567INC000002345678INC000003456789
|
|||
|
Activiteitsnaam
ActivityName
|
De naam van de specifieke event of task die heeft plaatsgevonden binnen de incident lifecycle. | ||
|
Beschrijving
Dit attribute beschrijft de activiteit die op een specifiek tijdstip voor een incident werd uitgevoerd, zoals 'Incident Gemeld', 'Groep Toegewezen' of 'Incident Opgelost'. Deze activiteiten zijn de bouwstenen van de proceskaart. Het analyseren van de volgorde en frequentie van deze activiteiten onthult de daadwerkelijke processtroom, identificeert veelvoorkomende paden en benadrukt afwijkingen van de standaardprocedure. Het is cruciaal voor het begrijpen welke acties worden ondernomen om een incident op te lossen.
Waarom het belangrijk is
Activiteiten definiëren de stappen in de proceskaart, waardoor visualisatie en analyse van de incidentbeheer workflow mogelijk worden.
Waar te verkrijgen
Doorgaans afgeleid van wijzigingen in de velden 'Status' (Field ID: 7) en 'Status_Reason' in het 'HPD:Help Desk'-formulier, of uit het 'HPD:Help Desk Audit Log'-formulier.
Voorbeelden
Incident gemeldGroep toegewezenOplossing geïmplementeerdIncident afgesloten
|
|||
|
Gebeurtenistijdstempel
EventTimestamp
|
De exacte datum en tijd waarop de activiteit plaatsvond. | ||
|
Beschrijving
Deze timestamp registreert wanneer een specifieke event in de incidentlevenscyclus plaatsvond. Het biedt de chronologische volgorde die nodig is om de procesflow te reconstrueren vanuit ruwe data. De Event Timestamp is essentieel voor alle tijdgebaseerde analyse, inclusief het berekenen van cycle times tussen activiteiten, het identificeren van knelpunten waar incidenten lang wachten, en het meten van de totale resolutietijden. Het vormt de temporele ruggengraat van de procesanalyse.
Waarom het belangrijk is
Deze timestamp biedt de chronologische volgorde van events, wat cruciaal is voor het berekenen van doorlooptijden, het identificeren van knelpunten en het begrijpen van de procestijdlijn.
Waar te verkrijgen
De 'Last Modified Date' (Veld ID: 6) of specifieke datumvelden uit het 'HPD:Help Desk' formulier. Voor historische events wordt dit gehaald uit het timestamp-veld van de audit log.
Voorbeelden
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
Assigned Group
AssignedGroup
|
De supportgroep die verantwoordelijk is voor de afhandeling van het incident. | ||
|
Beschrijving
Dit attribute identificeert het team of de afdeling die aan het incident is toegewezen, zoals 'Service Desk', 'Network Team' of 'Database Administrators'. Het volgen van toewijzingen is essentieel voor het begrijpen van de processtroom tussen teams. Dit attribute wordt gebruikt om inter-team handoffs te analyseren, knelpunten veroorzaakt door specifieke groepen te identificeren en de 'Incident Reassignment Rate' te meten. Het helpt de weg te visualiseren die een incident door de organisatie aflegt en benadrukt gebieden met inefficiënte routing of kennislacunes.
Waarom het belangrijk is
Het bijhouden welke groep is toegewezen, helpt bij het analyseren van handovers, het identificeren van hertoewijzingslussen en het lokaliseren van knelpunten binnen specifieke teams.
Waar te verkrijgen
Dit is het 'Assigned Group' veld (Field ID: 1000000217) in het 'HPD:Help Desk' formulier.
Voorbeelden
Service DeskNetwerkbeheerApplicatieondersteuning Tier 2Infrastructuurdiensten
|
|||
|
Incidentafhandelingstijd
IncidentResolutionTime
|
De totale verstreken tijd vanaf het moment dat een incident voor het eerst werd gemeld totdat het werd opgelost. | ||
|
Beschrijving
Dit is een berekende metric die de duur weergeeft tussen de 'Incident Reported' en 'Incident Resolved' activiteiten. Het is een van de meest voorkomende en belangrijke KPI's in incident management. Deze metric meet direct de efficiëntie van het resolutieproces. In process mining wordt het gebruikt als een primaire performance indicator, geanalyseerd per incidentcategorie, prioriteit en team om verbeterpunten te identificeren en de impact van procesveranderingen over tijd te volgen.
Waarom het belangrijk is
Dit is een kritieke KPI die de end-to-end efficiëntie van het incident management proces meet en direct impact heeft op de gebruikerstevredenheid.
Waar te verkrijgen
Berekend door de timestamp van de eerste event af te trekken van de timestamp van de 'Incident Opgelost' event voor elke Incident ID.
Voorbeelden
2592003600864000
|
|||
|
Incidentcategorie
IncidentCategory
|
De classificatie van het incident, vaak in een gelaagde structuur. | ||
|
Beschrijving
Incidentcategorisatie biedt een gestructureerde manier om incidenten te classificeren, meestal met behulp van een hiërarchie op meerdere niveaus (bijv. Niveau 1: Hardware, Niveau 2: Laptop, Niveau 3: Batterij). Deze data is essentieel voor routering, rapportage en trendanalyse. Binnen process mining wordt categorisatie gebruikt om verschillende typen incidenten afzonderlijk te analyseren. Het ondersteunt het Incident Categorization Accuracy dashboard door initiële en uiteindelijke categorieën te vergelijken en helpt bij het identificeren van trends voor het Root Cause Trends dashboard.
Waarom het belangrijk is
Categorisatie maakt nauwkeurige routering, trendanalyse en prestatievergelijking over verschillende typen incidenten mogelijk.
Waar te verkrijgen
Dit zijn de 'Operational Categorization Tier 1/2/3' velden in het 'HPD:Help Desk' formulier.
Voorbeelden
Hardware > Laptop > BatterySoftware > Enterprise App > LoginfoutNetwork > Connectivity > Wi-Fi
|
|||
|
Incidentstatus
IncidentStatus
|
De huidige of historische status van het incident op het moment van de event. | ||
|
Beschrijving
Dit attribute geeft de status van het incident aan, zoals 'New', 'In Progress', 'Pending', 'Resolved' of 'Closed'. Het biedt een momentopname van waar het incident zich bevindt in zijn lifecycle. Het analyseren van statuswijzigingen is fundamenteel voor het begrijpen van het incident management proces. Het wordt gebruikt om activiteiten te definiëren, de tijd te meten die in verschillende statussen wordt doorgebracht (bijv. hoe lang incidenten 'Pending' zijn), en om incidenten te identificeren die mogelijk vastzitten of inactief zijn.
Waarom het belangrijk is
Het volgen van statuswijzigingen is essentieel om de voortgang van het incident te begrijpen en te meten hoe lang het in specifieke staten zoals 'Pending' of 'In Progress' verblijft.
Waar te verkrijgen
Dit is het 'Status' veld (Field ID: 7) in het 'HPD:Help Desk' formulier.
Voorbeelden
NieuwToegewezenIn uitvoeringPendingOpgelostGesloten
|
|||
|
Is Reopened
IsReopened
|
Een indicator of een incident opnieuw is geopend nadat het de status 'Opgelost' had gekregen. | ||
|
Beschrijving
Dit boolean attribute is true als de status van een incident terugkeerde naar een actieve staat (zoals 'In Progress') nadat het al als 'Resolved' was gemarkeerd. Dit duidt erop dat de initiële oplossing niet effectief of compleet was. Dit is een directe maatstaf voor rework en wordt gebruikt om de 'Incident Rework Rate' KPI te berekenen. Het analyseren van heropende incidents helpt bij het identificeren van oplossingen van slechte kwaliteit, onvoldoende testen, of terugkerende problemen die niet correct werden aangepakt, ter ondersteuning van het 'Rework and Escalation Paths' dashboard.
Waarom het belangrijk is
Meet direct rework en de kwaliteit van oplossingen. Een hoge heropeningsfrequentie wijst op ineffectieve fixes en proceszwaktes.
Waar te verkrijgen
Berekend door de reeks activiteiten te analyseren voor een incident. Als een 'Incident Heropend' of vergelijkbare activiteit verschijnt na een 'Oplossing Geïmplementeerd' activiteit, wordt deze flag op true gezet.
Voorbeelden
truefalse
|
|||
|
Is SLA Breached
IsSlaBreached
|
Een indicator of het incident is opgelost na de afgesproken SLA-streefdatum. | ||
|
Beschrijving
Dit boolean attribute is true als de resolutietijd van het incident de gedefinieerde SLA overschreed. Het biedt een duidelijke, binaire uitkomst voor SLA-prestaties per incident. Deze flag is essentieel voor het creëren van het 'Incident SLA Performance Overview' dashboard en het berekenen van de 'Incident SLA Compliance Rate' KPI. Het vereenvoudigt analyse door directe filtering en aggregatie van alle incidents toe te staan die niet voldeden aan hun serviceniveau-doelen, waardoor het gemakkelijk wordt om de redenen voor overschrijdingen te onderzoeken.
Waarom het belangrijk is
Deze flag vereenvoudigt de SLA-compliance analyse, waardoor het eenvoudig wordt om te filteren op alle incidents die de SLA hebben geschonden en de root causes te onderzoeken.
Waar te verkrijgen
Berekend door de 'Incident Opgelost' event timestamp te vergelijken met de 'SlaTargetDate'. Als de resolutie timestamp na de doeldatum is, is deze flag true.
Voorbeelden
truefalse
|
|||
|
Prioriteit
Priority
|
Het prioriteitsniveau dat aan het incident is toegewezen, bepalend voor de urgentie van de afhandeling. | ||
|
Beschrijving
Prioriteit wordt doorgaans afgeleid uit de combinatie van impact en urgentie en bepaalt de volgorde en snelheid van het oplossen van incidenten. Gangbare waarden variëren van 'Kritiek' tot 'Laag'. Binnen process mining is het analyseren van incidenten op basis van prioriteit cruciaal voor prestatieanalyse. Het helpt vragen te beantwoorden zoals: 'Voldoen we aan de SLA's voor incidenten met hoge prioriteit?' en 'Ervaren incidenten met lage prioriteit langere vertragingen?'. Filteren op prioriteit maakt gerichte analyse mogelijk van de meest kritieke bedrijfsproblemen.
Waarom het belangrijk is
Dit attribute is essentieel voor het segmenteren van analyses om te waarborgen dat incidents met hoge prioriteit sneller worden afgehandeld en hun specifieke Service Level-doelstellingen behalen.
Waar te verkrijgen
Dit is het 'Priority' veld (Field ID: 1000000164) in het 'HPD:Help Desk' formulier.
Voorbeelden
KritiekHoogGemiddeldLaag
|
|||
|
Service
Service
|
De zakelijke of technische service die door het incident wordt beïnvloed. | ||
|
Beschrijving
Dit attribute koppelt een incident aan een specifieke service, zoals gedefinieerd in de Configuration Management Database (CMDB), bijvoorbeeld 'E-mail Service', 'VPN-toegang' of 'SAP Financials'. Deze koppeling is cruciaal voor het begrijpen van de bedrijfsimpact van incidents. Het analyseren van incidents per service helpt bij het identificeren van problematische services die een groot aantal incidents genereren, legt de nadruk op terugkerende problemen die gekoppeld zijn aan specifieke technologieën, en ondersteunt trendanalyse voor problem management.
Waarom het belangrijk is
Het koppelen van incidenten aan business services is cruciaal voor impactanalyse en het identificeren van welke services het meest probleemgevoelig zijn.
Waar te verkrijgen
Dit is het 'ServiceCI' of een vergelijkbaar veld dat het getroffen Configuration Item (CI) vertegenwoordigt in het 'HPD:Help Desk' formulier.
Voorbeelden
Zakelijk e-mailadresSAP ERPRemote Access VPNHuman Resources Portaal
|
|||
|
Toegewezen gebruiker
Assignee
|
De individuele gebruiker die is toegewezen om aan het incident te werken. | ||
|
Beschrijving
De Toegewezen Persoon is de specifieke supportmedewerker of technicus die op een bepaald moment verantwoordelijk is voor het incident. Dit biedt een gedetailleerder inzicht dan de Toegewezen Groep. Het analyseren van de prestaties per toegewezen persoon kan helpen bij het identificeren van toppresteerders, medewerkers die extra training nodig hebben en onevenwichtigheden in de werkdruk. Het wordt ook gebruikt om de exacte volgorde van acties te traceren die door personen die aan een complex incident werken, zijn uitgevoerd.
Waarom het belangrijk is
Biedt een gedetailleerd overzicht van de werkdrukverdeling en individuele prestaties, en helpt bij het identificeren van best presterende medewerkers of agents die ondersteuning nodig hebben.
Waar te verkrijgen
Dit is het 'Assignee' veld (Field ID: 1000000218) in het 'HPD:Help Desk' formulier.
Voorbeelden
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Aantal hertoewijzingen
ReassignmentCount
|
Het totale aantal keren dat een incident opnieuw werd toegewezen aan een andere groep. | ||
|
Beschrijving
Deze metriek telt hoe vaak het veld 'AssignedGroup' is gewijzigd gedurende de levenscyclus van het incident. Een hoog aantal duidt op problemen met de initiële routering, het ontbreken van 'first-contact resolution' of complexe problemen die input van meerdere teams vereisen. Dit attribute ondersteunt direct de 'Incident Reassignment Rate' KPI en het 'Incident Reassignment Cycle Analysis' dashboard. Het helpt het 'pingpong'-effect te kwantificeren, waarbij tickets heen en weer worden geschoven tussen teams, wat leidt tot aanzienlijke vertragingen en procesinefficiëntie.
Waarom het belangrijk is
Kwantificeert inefficiënte routering en overdrachten, en helpt bij het identificeren van incidenten die vastzitten in hertoewijzingslussen tussen teams.
Waar te verkrijgen
Berekend door het aantal keren te tellen dat de AssignedGroup waarde verandert voor een gegeven Incident ID in het event log.
Voorbeelden
0135
|
|||
|
Afsluitcode
CloseCode
|
De code die wordt geselecteerd bij het afsluiten van een incident, ter aanduiding van het oplossingsresultaat. | ||
|
Beschrijving
De Afsluitcode biedt een gestructureerde samenvatting van hoe een incident is opgelost. Voorbeelden zijn 'Opgelost door Gebruiker', 'Geen Fout Gevonden', 'Dubbel Incident' of 'Permanente Oplossing Toegepast'. Dit attribute is waardevol voor het analyseren van de effectiviteit en resultaten van de oplossing. Het kan helpen incidenten te identificeren die werden afgesloten zonder een echte oplossing of categorieën te benadrukken waarin gebruikers frequent hun problemen zelf oplossen, wat kan duiden op kansen voor betere kennisbankartikelen of self-service tools.
Waarom het belangrijk is
Biedt gestructureerde data over oplossingsresultaten, en helpt bij het analyseren van de effectiviteit van fixes en het identificeren van trends in hoe incidenten worden afgesloten.
Waar te verkrijgen
Dit maakt doorgaans deel uit van de oplossing of afsluitingsinformatie op het 'HPD:Help Desk' formulier.
Voorbeelden
Op afstand opgelostDubbele meldingGebruikersfoutGeen actie vereist
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de incident data is geëxtraheerd. | ||
|
Beschrijving
Dit attribute identificeert de herkomst van de data, wat vooral nuttig is in omgevingen met meerdere ITSM tools of geïntegreerde systemen. Het bevestigt dat de data afkomstig is van de verwachte bron, zoals een specifieke BMC Helix ITSM instance. In analyse helpt het processen of data-kenmerken te onderscheiden die kunnen variëren tussen productie-, ontwikkel- of legacy systemen, waardoor de data lineage duidelijk en betrouwbaar is.
Waarom het belangrijk is
Identificeert de herkomst van de data, wat cruciaal is voor datavalidatie en voor het beheren van analyses over meerdere geïntegreerde systemen.
Waar te verkrijgen
Dit is doorgaans een statische waarde die wordt toegevoegd tijdens het proces van data-extractie, -transformatie en -lading (ETL).
Voorbeelden
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
|
|||
|
Hoofdoorzaak
RootCause
|
De onderliggende reden of uiteindelijke oorzaak van het incident. | ||
|
Beschrijving
De Root Cause (grondoorzaak) is het fundamentele probleem dat, indien aangepakt, het incident zou voorkomen. Dit wordt vaak geïdentificeerd als onderdeel van een gerelateerd probleemoplossingsproces. Hoewel niet alle incidenten een gedocumenteerde root cause zullen hebben, is het analyseren van dit attribute cruciaal voor proactief problem management. Het ondersteunt de KPI 'Root Cause Identification Rate' en helpt bij het creëren van dashboards die trends in terugkerende problemen volgen, ter ondersteuning van inspanningen om permanente oplossingen te implementeren.
Waarom het belangrijk is
Het identificeren van de hoofdoorzaak is essentieel voor probleemmanagement en voor analyses die gericht zijn op het verminderen van het volume aan terugkerende incidenten.
Waar te verkrijgen
Deze informatie kan zich bevinden in een specifiek 'Root Cause' veld op het incident of, vaker, op een gekoppeld 'PBI:Problem Investigation' formulier.
Voorbeelden
Onvoldoende schijfruimte op serverNetwerkconfiguratiefoutSoftwarebug in versie 2.1Verlopen beveiligingscertificaat
|
|||
|
Impact
Impact
|
De maatstaf voor de impact van het incident op bedrijfsprocessen. | ||
|
Beschrijving
Impact beoordeelt de mate van het nadelige effect van een incident op de bedrijfsvoering. Het wordt vaak gedefinieerd op een schaal, zoals 'Uitgebreid/Wijdverspreid', 'Belangrijk/Groot', 'Matig/Beperkt' of 'Minimaal/Lokaal'. In combinatie met urgentie bepaalt Impact de prioriteit van het incident. Analyse op basis van impact helpt te begrijpen welke incidenten de meeste bedrijfsonderbrekingen veroorzaken, ongeacht hun technische complexiteit. Dit is essentieel voor het prioriteren van procesverbeteringsinspanningen.
Waarom het belangrijk is
Helpt de bedrijfsernst van een incident te kwantificeren, wat een sleutelcomponent is bij het bepalen van prioriteit en het richten van analyse op high-impact issues.
Waar te verkrijgen
Dit is het 'Impact' veld (Field ID: 1000000163) in het 'HPD:Help Desk' formulier.
Voorbeelden
1-Uitgebreid/Wijdverspreid2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
Indiener
Submitter
|
De persoon die het incident aanvankelijk heeft gemeld. | ||
|
Beschrijving
De Melder is de eindgebruiker of klant die het probleem heeft ervaren en gerapporteerd. Dit verschilt van de toegewezen persoon die aan het incident werkt. Het analyseren van data per melder of diens afdeling kan helpen bij het identificeren van specifieke gebruikersgroepen die meer training nodig hebben of groepen die worden beïnvloed door een bepaald type probleem. Het biedt een klantgerichte kijk op het incident management proces.
Waarom het belangrijk is
Identificeert de gebruiker die het probleem heeft gemeld, wat analyse mogelijk maakt op basis van gebruikersafdeling, locatie of rol om gebruikersspecifieke trends te vinden.
Waar te verkrijgen
Deze informatie wordt vastgelegd in het 'Submitter' veld of velden gerelateerd aan de klantinformatie op het 'HPD:Help Desk' formulier.
Voorbeelden
John DoeJane SmithPeter Jones
|
|||
|
Kanaal
Channel
|
De methode die wordt gebruikt om het incident te rapporteren. | ||
|
Beschrijving
Dit attribute specificeert hoe het incident is ingediend, bijvoorbeeld via een telefoongesprek, e-mail, selfserviceportal, of directe melding. Het geeft het ingangspunt van het incident in het supportproces aan. Het analyseren van incidents per kanaal kan laten zien welke kanalen het meest effectief zijn of welke incidents genereren die gemakkelijker of moeilijker op te lossen zijn. Het kan ook beslissingen onderbouwen over waar te investeren in automatisering of gebruikerstraining, bijvoorbeeld door het gebruik van een selfserviceportal te promoten dat betere initiële data vastlegt.
Waarom het belangrijk is
Inzicht in het indieningskanaal helpt bij het analyseren van de efficiëntie van verschillende invoermethoden en kan investeringen in self-service of automatisering sturen.
Waar te verkrijgen
Dit is het 'Reported Source' veld (Field ID: 1000000215) in het 'HPD:Help Desk' formulier.
Voorbeelden
E-mailTelefoonSelf ServiceDirecte invoer
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor dit event voor het laatst is ververst vanuit het bronsysteem. | ||
|
Beschrijving
Dit attribute registreert de datum en tijd van de meest recente data-extractie. Het biedt context over de actualiteit van de geanalyseerde data, wat belangrijk is voor het begrijpen hoe actueel de procesinzichten zijn. Het kennen van het tijdstip van de laatste update is essentieel voor rapportages en dashboards, omdat het gebruikers informeert over de tijdigheid van de data en helpt bij het beheren van verwachtingen over de opname van de meest recente incidentactiviteiten.
Waarom het belangrijk is
Geeft de actualiteit van de data aan, zodat gebruikers begrijpen hoe recent de procesanalyse en eventuele daaruit voortvloeiende inzichten zijn.
Waar te verkrijgen
Deze waarde wordt doorgaans gegenereerd en toegevoegd aan de dataset tijdens het data-extractieproces (ETL).
Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
Oplossingsbeschrijving
Resolution
|
Een vrije-tekstbeschrijving van de genomen stappen om het incident op te lossen. | ||
|
Beschrijving
Dit veld bevat de gedetailleerde, door mensen geschreven samenvatting van de uiteindelijke oplossing. Het verklaart wat er is gedaan om het probleem op te lossen en de service voor de gebruiker te herstellen. Hoewel ongestructureerd, kan deze tekstdata worden geanalyseerd met behulp van text mining technieken om veelvoorkomende resolutiepatronen te identificeren, keywords te extraheren die verband houden met specifieke problemen, of root cause analysis aan te vullen. Het biedt kwalitatieve context die gestructureerde datavelden vaak missen.
Waarom het belangrijk is
Biedt kwalitatieve details over de oplossing, die kunnen worden gebruikt in text mining om patronen te vinden die niet zichtbaar zijn in gestructureerde data.
Waar te verkrijgen
Dit is het 'Resolution' veld (Field ID: 1000000156) in het 'HPD:Help Desk' formulier.
Voorbeelden
Het wachtwoord van de gebruiker is opnieuw ingesteld via Active Directory.Cache en cookies gewist in de browser, wat het loginprobleem heeft opgelost.Netwerkswitch opnieuw opgestart in IDF-kast 3B.
|
|||
|
SLA-streefdatum
SlaTargetDate
|
De datum en tijd waarop het incident naar verwachting moet zijn opgelost volgens de SLA. | ||
|
Beschrijving
Dit attribute slaat de deadline op voor de resolutie van een incident, zoals gedefinieerd door de van toepassing zijnde Service Level Agreement (SLA). Deze wordt berekend op basis van de prioriteit van het incident en de gedefinieerde service-uren. Deze timestamp is de benchmark waartegen de werkelijke resolutietijd wordt gemeten. Het is essentieel voor het berekenen van de 'Incident SLA Compliance Rate' KPI en voor het bouwen van dashboards die de SLA-prestaties visualiseren. Het maakt proactieve monitoring mogelijk van incidents die hun deadline naderen.
Waarom het belangrijk is
Dit is de benchmark voor het meten van SLA-compliance. Het maakt het mogelijk om te berekenen of een incident op tijd is opgelost of de overeenkomst heeft geschonden.
Waar te verkrijgen
Deze data wordt doorgaans opgeslagen in het 'SLM:Measurement' formulier en gekoppeld aan het incident. Het is geen direct veld op 'HPD:Help Desk'.
Voorbeelden
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
Incident Management Activiteiten
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Groep toegewezen
|
Deze activiteit markeert de initiële toewijzing van het incident aan een specifieke supportgroep voor onderzoek. Dit wordt afgeleid van de eerste keer dat het veld 'Assigned Group' wordt gevuld na de aanmaak van het incident. | ||
|
Waarom het belangrijk is
Dit is een belangrijke mijlpaal die het begin van actieve werkzaamheden markeert. Het volgen van de tijd tot de eerste toewijzing is cruciaal voor het evalueren van responstijden en de initiële routing efficiëntie.
Waar te verkrijgen
Afgeleid van het audit log ('HPD:HelpDesk_AuditLogSystem') voor het formulier 'HPD:Help Desk', waarbij de eerste invulling van het veld 'Assigned Group' wordt vastgelegd.
Vastleggen
Vanaf de timestamp wanneer het veld 'Assigned Group' voor het eerst wordt gevuld.
Gebeurtenistype
inferred
|
|||
|
Incident afgesloten
|
Dit is de laatste activiteit, die de formele afsluiting van het incident record markeert nadat de oplossing is bevestigd of een bevestigingsperiode is verstreken. Het wordt vastgelegd wanneer de status op 'Closed' wordt gezet. | ||
|
Waarom het belangrijk is
Dit is het definitieve eind-event voor de incident lifecycle. De tijd tussen 'Resolved' en 'Closed' vertegenwoordigt de gebruikersbevestiging en administratieve afhandelingsperiode.
Waar te verkrijgen
Dit event komt overeen met het 'Status' veld op het 'HPD:Help Desk' formulier dat op 'Closed' wordt gezet. De timestamp wordt geregistreerd in het 'Closed Date' veld en de audit log.
Vastleggen
Van de 'Closed Date' timestamp of de statusverandering naar 'Closed'.
Gebeurtenistype
inferred
|
|||
|
Incident gemeld
|
Deze activiteit markeert de initiële aanmaak van de incidentrecord in het systeem. Het wordt expliciet vastgelegd vanuit de aanmaak-timestamp van het incident in het centrale incident management formulier. | ||
|
Waarom het belangrijk is
Dit is het primaire start-event voor de incident lifecycle. Het is essentieel voor het berekenen van algemene resolutietijden en het begrijpen van de aantallen binnenkomende incidents.
Waar te verkrijgen
Dit event komt overeen met de aanmaak van het record in het 'HPD:Help Desk' formulier. De timestamp wordt doorgaans overgenomen uit het 'Submit Date' of 'Reported Date' veld.
Vastleggen
Van de 'Submit Date' timestamp op het HPD:Help Desk formulier.
Gebeurtenistype
explicit
|
|||
|
Incident opgelost
|
Deze activiteit markeert de officiële resolutie van het incident vanuit het perspectief van de service desk, vóór de uiteindelijke afsluiting. Het wordt vastgelegd wanneer de status van het incident wordt ingesteld op 'Resolved'. | ||
|
Waarom het belangrijk is
Dit is de belangrijkste mijlpaal voor het meten van SLA-compliance en resolutietijd. Het betekent dat de service voor de gebruiker is hersteld.
Waar te verkrijgen
Dit event komt overeen met het 'Status' veld op het 'HPD:Help Desk' formulier dat op 'Resolved' wordt gezet. De timestamp wordt vastgelegd in het 'Last Resolved Date' veld en de audit log.
Vastleggen
Van de timestamp van de statusverandering naar 'Resolved' in de audit log.
Gebeurtenistype
inferred
|
|||
|
Onderzoek geïnitieerd
|
Geeft aan dat een supportmedewerker actief aan het incident is begonnen te werken. Dit wordt doorgaans afgeleid van een statuswijziging van 'Assigned' naar 'In Progress'. | ||
|
Waarom het belangrijk is
Deze mijlpaal markeert de overgang van wachten in een wachtrij naar actieve diagnose. Het analyseren van de wachttijd voordat een onderzoek start, helpt bij het identificeren van resourceknelpunten en ondersteunt het 'Diagnosis & Investigation Bottlenecks' dashboard.
Waar te verkrijgen
Afgeleid van een statuswijziging op het formulier 'HPD:Help Desk'. De gebeurtenis wordt geactiveerd wanneer het veld 'Status' verandert naar 'In Progress', waarbij de timestamp wordt vastgelegd vanuit het audit log.
Vastleggen
Afgeleid van een statuswijziging naar 'In Progress' in het HPD:HelpDesk_AuditLogSystem.
Gebeurtenistype
inferred
|
|||
|
Gebruikersbevestiging ontvangen
|
Vertegenwoordigt de actieve bevestiging door de gebruiker dat de geboden oplossing hun probleem heeft opgelost. Dit kan een expliciet event zijn of worden afgeleid uit notities of een gerelateerde systeemactie vóór afsluiting. | ||
|
Waarom het belangrijk is
Het bijhouden hiervan geeft een accurater beeld van het gebruikersvalidatieproces dan alleen wachten op automatische afsluiting. Het helpt bij het meten van de 'Average User Confirmation Time' KPI en het identificeren van communicatiekloven.
Waar te verkrijgen
Dit kan moeilijk zijn om betrouwbaar vast te leggen. Het kan worden afgeleid uit een work log entry of een specifieke statusreden-update vlak voordat het incident naar 'Closed' wordt verplaatst. Het kan een analyse van het 'HPD:WorkLog' formulier vereisen.
Vastleggen
Afgeleid van specifieke werklogboekvermeldingen of statusreden-updates voorafgaand aan de afsluiting.
Gebeurtenistype
inferred
|
|||
|
Incident geannuleerd
|
Deze activiteit vertegenwoordigt de beëindiging van een incident dat per vergissing is aangemaakt of niet langer relevant is. Het wordt vastgelegd wanneer de status van het incident wordt ingesteld op 'Cancelled'. | ||
|
Waarom het belangrijk is
Dit is een terminale eindstatus voor een incident, onderscheiden van een succesvolle oplossing. Het analyseren van geannuleerde incidents kan problemen met incidentcreatiekanalen of dubbele rapportage aan het licht brengen.
Waar te verkrijgen
Afgeleid van het formulier 'HPD:Help Desk' wanneer het veld 'Status' wordt bijgewerkt naar 'Cancelled'. De timestamp wordt vastgelegd in het audit log.
Vastleggen
Afgeleid van een statuswijziging naar 'Cancelled' in het audit log.
Gebeurtenistype
inferred
|
|||
|
Incident gecategoriseerd
|
Vertegenwoordigt het punt waarop het incident is geclassificeerd met operationele en productcategorisaties en een prioriteit is ingesteld. Dit wordt doorgaans afgeleid uit het vullen of de laatste wijziging van categorisatievelden. | ||
|
Waarom het belangrijk is
Nauwkeurige en tijdige categorisatie is cruciaal voor efficiënte routering en rapportage. Het analyseren van deze activiteit helpt vertragingen of onnauwkeurigheden in het initiële triage-proces te identificeren, ter ondersteuning van het dashboard 'Nauwkeurigheid Incidentcategorisatie'.
Waar te verkrijgen
Afgeleid van het audit log ('HPD:HelpDesk_AuditLogSystem') dat wijzigingen bijhoudt in velden zoals 'Operational Categorization Tier 1-3', 'Product Categorization Tier 1-3' en 'Priority' op het formulier 'HPD:Help Desk'.
Vastleggen
Van de timestamp van de laatste update naar categorisatie- of prioriteitsvelden na aanmaak.
Gebeurtenistype
inferred
|
|||
|
Incident heropend
|
Vertegenwoordigt een incident dat eerder als opgelost was gemarkeerd, maar opnieuw is geactiveerd omdat het probleem aanhoudt. Dit wordt afgeleid uit een statuswijziging van 'Opgelost' terug naar een actieve status, zoals 'In behandeling' of 'Toegewezen'. | ||
|
Waarom het belangrijk is
Deze activiteit meet direct rework en de effectiviteit van initiële oplossingen. Een hoog volume aan heropende incidenten is een belangrijke indicator van slechte oplossingskwaliteit en ondersteunt de KPI 'Incident Rework Rate'.
Waar te verkrijgen
Afgeleid van het audit log ('HPD:HelpDesk_AuditLogSystem') door een 'Status'-wijziging te detecteren van 'Resolved' naar 'In Progress' of 'Assigned' voor een gegeven Incident ID.
Vastleggen
Afgeleid van een statusovergang van 'Resolved' naar een actieve status.
Gebeurtenistype
inferred
|
|||
|
Oplossing geïmplementeerd
|
Deze activiteit duidt aan dat een oplossing of workaround is toegepast door het supportteam. Dit wordt vaak afgeleid wanneer de incidentstatus verandert naar 'Resolved'. | ||
|
Waarom het belangrijk is
Dit is een kritieke mijlpaal die aangeeft dat een oplossing is geleverd. Het is een belangrijk datapunt voor het meten van de tijd om een fix toe te passen nadat het onderzoek is afgerond.
Waar te verkrijgen
Dit wordt doorgaans afgeleid wanneer de 'Status' op het 'HPD:Help Desk' formulier wordt gewijzigd naar 'Resolved'. De timestamp wordt vastgelegd in het 'Last Resolved Date' veld en de audit log.
Vastleggen
Van de 'Last Resolved Date' timestamp of de statusverandering naar 'Resolved'.
Gebeurtenistype
inferred
|
|||
|
Overgedragen aan een andere groep
|
Deze activiteit vindt plaats wanneer een incident wordt toegewezen van de ene supportgroep naar de andere. Dit wordt afgeleid door een wijziging te detecteren in het veld 'Assigned Group' na de initiële toewijzing. | ||
|
Waarom het belangrijk is
Frequente overdrachten duiden op een onjuiste initiële routering of kennisleemtes. Het bijhouden van deze activiteit is essentieel voor het 'Incident Reassignment Cycle Analysis' dashboard en de 'Incident Reassignment Rate' KPI.
Waar te verkrijgen
Afgeleid van het audit log ('HPD:HelpDesk_AuditLogSystem') door het identificeren van daaropvolgende wijzigingen in het veld 'Assigned Group' op het formulier 'HPD:Help Desk' nadat het voor het eerst was ingevuld.
Vastleggen
Identificeer wijzigingen in het veld 'Toegewezen Groep' na de initiële toewijzing.
Gebeurtenistype
inferred
|
|||
|
SLA-schending
|
Dit is een berekend event dat optreedt wanneer de tijd om een incident op te lossen de gedefinieerde Service Level Agreement-doel overschrijdt. Het wordt afgeleid door de resolutie timestamp te vergelijken met de SLA vervaldatum. | ||
|
Waarom het belangrijk is
Deze activiteit is fundamenteel voor het dashboard 'Incident SLA Performance Overview' en de KPI 'Incident SLA Compliance Rate'. Het signaleert direct incidenten die niet aan de serviceverplichtingen voldeden.
Waar te verkrijgen
Berekend door de 'Laatste Oplosdatum' te vergelijken met de 'Doeldatum' (SLA Vervaldatum) op het 'HPD:Help Desk' formulier. Als het incident nog niet is opgelost, kan het worden berekend met de huidige tijd.
Vastleggen
Berekende event: treedt op als 'Laatste Oplosdatum' > 'Doeldatum'.
Gebeurtenistype
calculated
|
|||
|
Wacht op Gebruikersbevestiging
|
Treedt op nadat een oplossing is geïmplementeerd en het supportteam wacht op bevestiging van de gebruiker dat de oplossing succesvol is. Dit wordt vaak vertegenwoordigd door de 'Resolved' status zelf, waar de klok voor automatische afsluiting begint. | ||
|
Waarom het belangrijk is
Deze activiteit is cruciaal voor het dashboard 'User Confirmation & Verification Delays'. Het helpt vertragingen te kwantificeren tussen het leveren van een oplossing en het verkrijgen van gebruikersvalidatie, wat de incident lifecycle kunstmatig kan verlengen.
Waar te verkrijgen
Deze status begint wanneer de 'Status' op het 'HPD:Help Desk'-formulier verandert naar 'Resolved'. De duur wordt gemeten vanaf de 'Last Resolved Date' totdat het incident óf 'Closed' óf 'Reopened' is.
Vastleggen
Begint bij statuswijziging naar 'Opgelost', eindigt bij statuswijziging naar 'Gesloten' of 'In Behandeling'.
Gebeurtenistype
inferred
|
|||
|
Wachtend op input van de klant
|
Vertegenwoordigt een punt waarop de incidentvoortgang is gepauzeerd in afwachting van informatie of actie van de gebruiker. Dit wordt afgeleid uit een statuswijziging naar de status 'In afwachting'. | ||
|
Waarom het belangrijk is
Deze activiteit helpt de werktijd van de agent te scheiden van de wachttijd van de klant. Het analyseren van de tijd die in deze status wordt doorgebracht, is cruciaal voor het begrijpen hoe vertragingen in gebruikersrespons de algehele resolutietijden beïnvloeden.
Waar te verkrijgen
Afgeleid van het formulier 'HPD:Help Desk' wanneer het veld 'Status' wordt bijgewerkt naar 'Pending'. De specifieke reden is vaak te vinden in het veld 'Status_Reason'.
Vastleggen
Afgeleid van een statuswijziging naar 'Pending' in het HPD:HelpDesk_AuditLogSystem.
Gebeurtenistype
inferred
|
|||