Data Template: Incident Management
Uw Incident Management Data Template
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Extractiehandleiding voor BMC Helix
Incident Management Attributes
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteit
ActivityName
|
De naam van de specifieke actie of gebeurtenis die op een punt in de levenscyclus van het incident plaatsvond. | ||
|
Beschrijving
De activiteitsnaam beschrijft een stap in het incidentmanagementproces, zoals 'Incident gecategoriseerd', 'Toegewezen aan SupportGroup' of 'Incident opgelost'. Deze activiteiten vormen de knooppunten in de ontdekte proceskaart. Het analyseren van de volgorde en frequentie van deze activiteiten staat centraal bij process mining. Het helpt de werkelijke processtroom bloot te leggen, knelpunten tussen stappen te identificeren, afwijkingen van de standaard operationele procedure te detecteren en de duur van specifieke fasen binnen de incidentlevenscyclus te meten.
Waarom het belangrijk is
Dit attribute definieert de stappen in het proces, waardoor de visualisatie van de procesmap en de analyse van flows, bottlenecks en afwijkingen mogelijk wordt.
Waar te verkrijgen
Doorgaans afgeleid van statuswijzigingen, audit logs of specifieke event records die geassocieerd zijn met het incident in de 'HPD:HelpDesk_AuditLogSystem' of vergelijkbare audittabellen.
Voorbeelden
Incident GemeldToegewezen aan supportgroepOnderzoek gestartIncident OpgelostIncident Afgesloten
|
|||
|
Incident ID
IncidentId
|
De unieke identifier voor elk gemeld incident, dienend als de primaire sleutel voor het traceren van de lifecycle van het incident. | ||
|
Beschrijving
De Incident ID is de hoeksteen van incidentmanagementanalyse. Het identificeert elke case uniek, waardoor alle gerelateerde events, statuswijzigingen en activiteiten kunnen worden samengevoegd tot één enkele, coherente procesinstantie. In process mining koppelt deze ID elke stap, van 'Incident Gemeld' tot 'Incident Afgesloten', waardoor een compleet end-to-end beeld van de incidentreis mogelijk is. Het is essentieel voor het berekenen van case-level metrics zoals totale oplossingstijd, aantal hertoewijzingen en het identificeren van procesvarianten.
Waarom het belangrijk is
Dit attribute is de fundamentele case identifier, waardoor het mogelijk wordt om de gehele lifecycle van een incident te traceren en de flow ervan door het management proces te analyseren.
Waar te verkrijgen
Dit is een kernveld in de primaire Incident Management module of formulier, vaak gelabeld als 'Incidentnummer' of 'Incident-ID'.
Voorbeelden
INC000012345678INC000009876543INC000011223344
|
|||
|
Starttijd
EventTimestamp
|
De exacte datum en tijd waarop een specifieke activiteit of gebeurtenis plaatsvond voor een incident. | ||
|
Beschrijving
De Event Timestamp registreert het moment waarop elke activiteit plaatsvond. Deze temporele data is cruciaal voor het chronologisch ordenen van events en het nauwkeurig construeren van de processtroom. In analyse worden timestamps gebruikt om duren tussen activiteiten te berekenen, de totale cycle time van incidenten te meten, en vertragingen of wachttijden in het proces te identificeren. Het vergelijken van timestamps met service level agreements (SLA's) is ook essentieel voor prestatiemonitoring en compliance checks.
Waarom het belangrijk is
Timestamps bieden de chronologische volgorde van events en zijn essentieel voor alle tijdsgebonden analyse, inclusief prestatiemeting, knelpuntidentificatie en SLA compliance.
Waar te verkrijgen
Deze informatie is te vinden in de audit log tables, zoals 'HPD:HelpDesk_AuditLogSystem', en correspondeert met elke geregistreerde actie of statuswijziging.
Voorbeelden
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de incident data is geëxtraheerd. | ||
|
Beschrijving
Dit attribute identificeert de herkomst van de data, wat cruciaal is in omgevingen waar data uit meerdere systemen wordt geconsolideerd voor analyse. Het helpt bij het waarborgen van data lineage en biedt context voor de structuur en inhoud van de data. Voor Bmc Helix zou dit doorgaans een statische waarde zijn die de specifieke instantie of omgeving identificeert, bijvoorbeeld 'BmcHelix_Production'. Het is nuttig voor het filteren en segmenteren van data als er ooit meerdere bronsystemen worden geïntegreerd.
Waarom het belangrijk is
Biedt traceerbaarheid en context voor de data-oorsprong, wat belangrijk is voor data governance en troubleshooting in multi-system environments.
Waar te verkrijgen
Dit is doorgaans een statische waarde die tijdens het data extraction, transformation, and loading (ETL) process wordt toegevoegd om de data source te identificeren.
Voorbeelden
BmcHelixBmcHelix_Prod_EUITSM_Platform_A
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor dit record voor het laatst is ververst vanuit het bronsysteem. | ||
|
Beschrijving
Dit attribute biedt de timestamp van de meest recente data-extractie. Het is een metadataveld dat essentieel is voor het begrijpen van de versheid van de data die wordt geanalyseerd. Weten wanneer de data voor het laatst is bijgewerkt, helpt analisten en zakelijke gebruikers de inzichten te vertrouwen die zijn afgeleid van de process mining tool. Het bevestigt of de analyse de meest actuele staat van operaties weerspiegelt of gebaseerd is op oudere data.
Waarom het belangrijk is
Zorgt voor transparantie over datafreshness, wat cruciaal is voor het nemen van tijdige en accurate business decisions op basis van de procesanalyse.
Waar te verkrijgen
Deze timestamp wordt gegenereerd en toegevoegd tijdens het ETL-proces (Extractie, Transformatie en Loading van data).
Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Ernst
Severity
|
De maatstaf voor de bedrijfsimpact van het incident. | ||
|
Beschrijving
Severiteit definieert de mate waarin een incident de bedrijfsactiviteiten beïnvloedt. Samen met urgentie is dit een kritieke input voor het bepalen van de prioriteit van het incident en de bijbehorende SLA's. Het analyseren van incidenten op basis van severiteit helpt bij het begrijpen van de procesprestaties bij de meest impactvolle problemen. Het wordt gebruikt in dashboards zoals het 'Overzicht van kritieke SLA-overschrijdingen' om incidenten die het grootste risico vormen voor de bedrijfsvoering te categoriseren en zich daarop te richten.
Waarom het belangrijk is
Severiteit helpt de bedrijfsimpact van incidenten te kwantificeren, waardoor analyses zich kunnen richten op het beperken van de grootste operationele risico's.
Waar te verkrijgen
Raadpleeg de BMC Helix documentatie. Dit is vaak een standaardveld op het incidentformulier, mogelijk genaamd 'Impact' of 'Severity'.
Voorbeelden
1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
Incidentcategorie
IncidentCategory
|
De classificatie van het incident, doorgaans georganiseerd in een hiërarchische structuur. | ||
|
Beschrijving
Incidentcategorieën classificeren incidenten (bijv. Hardware, Software). Essentieel voor de juiste routering, trendanalyse en het meten van triagekwaliteit.
Waarom het belangrijk is
Correcte categorization is essentieel voor efficiënte routing, trend analysis en het beoordelen van de nauwkeurigheid van de initiële diagnose.
Waar te verkrijgen
Dit zijn standaardvelden op het formulier 'HPD:Help Desk', vaak een reeks gecascadeerde velden zoals 'Categorisatie Laag 1', 'Categorisatie Laag 2', enz.
Voorbeelden
Software > Bedrijfstoepassingen > ERPHardware > Laptop > ToetsenbordNetwerk > Connectiviteit > Wi-Fi
|
|||
|
Incidentstatus
IncidentStatus
|
De huidige of historische status van het incident binnen de levenscyclus, zoals 'Nieuw', 'In behandeling' of 'Gesloten'. | ||
|
Beschrijving
De Incident Status geeft de fase van een incident op een bepaald moment aan. Het is vaak de bron voor het genereren van het 'Activiteiten'-log, waarbij een statuswijziging overeenkomt met een processtap. Het analyseren van de status maakt het mogelijk om incidenten te filteren op hun huidige staat, te begrijpen hoeveel tijd in verschillende statussen wordt doorgebracht, en incidenten te identificeren die 'vastzitten'. Een dashboard zou bijvoorbeeld incidenten kunnen markeren die ongewoon lang in een 'In afwachting' status hebben gezeten.
Waarom het belangrijk is
Het biedt een momentopname van de voortgang van een incident en is cruciaal voor het identificeren van vastgelopen incidenten en het analyseren van de tijd die in verschillende fasen is doorgebracht.
Waar te verkrijgen
Een kernveld op het hoofdincidentformulier, meestal HPD:Help Desk. Het veld wordt vaak Status genoemd.
Voorbeelden
NieuwToegewezenIn uitvoeringIn AfwachtingOpgelostGesloten
|
|||
|
Prioriteit
Priority
|
Het prioriteitsniveau van het incident, dat de vereiste snelheid van oplossing bepaalt. | ||
|
Beschrijving
Prioriteit is een belangrijk attribute dat de urgentie van een incident bepaalt. Het wordt vaak afgeleid van de impact en urgentie van het incident en wordt gebruikt om resources toe te wijzen en Service Level Agreement (SLA) targets te definiëren.\n\nIn process mining analyse wordt prioriteit gebruikt om incidenten te segmenteren en de process flows van hoge-prioriteits versus lage-prioriteits cases te vergelijken. Dit helpt te verifiëren of kritieke incidenten daadwerkelijk sneller worden afgehandeld en om eventuele afwijkingen in hun process paths te identificeren, wat essentieel is voor het 'High-Priority Incident Performance' dashboard en gerelateerde KPIs.
Waarom het belangrijk is
Dit attribute is cruciaal voor het segmenteren van de analyse om ervoor te zorgen dat incidenten met hoge urgentie worden afgehandeld volgens gedefinieerde procedures en SLA's.
Waar te verkrijgen
Een standaardveld op het HPD:Help Desk formulier, meestal Priority genoemd.
Voorbeelden
KritiekHoogGemiddeldLaag
|
|||
|
SLA-Status
SLAStatus
|
Geeft aan of het incident voldoet aan de service level agreement (SLA)-doelen of dat deze zijn overschreden. | ||
|
Beschrijving
De SLA-status biedt een duidelijke indicator van serviceprestaties voor elk incident. Het kent doorgaans statussen als 'Binnen Doel', 'Waarschuwing' of 'Overschreden'. Dit is vaak een dynamisch berekend veld binnen Bmc Helix zelf. Dit attribute is essentieel voor het dashboard 'Critical SLA Breach Overview' en de KPI 'Critical Incident SLA Breach Rate'. Het maakt het mogelijk om incidenten die niet aan de serviceafspraken voldoen direct te identificeren en te prioriteren, wat een gerichte analyse van de oorzaken van vertragingen vergemakkelijkt.
Waarom het belangrijk is
Meet direct de prestaties ten opzichte van gemaakte afspraken en is fundamenteel voor compliance monitoring en het identificeren van processen die SLA breaches veroorzaken.
Waar te verkrijgen
Dit is vaak een berekend veld binnen Bmc Helix, afgeleid van de prioriteit en leeftijd van het incident. De status kan worden opgeslagen in een gerelateerde SLA management module.
Voorbeelden
Binnen TargetWaarschuwingOverschreden
|
|||
|
Toegewezen agent
AssignedAgent
|
De individuele supportmedewerker die is toegewezen om het incident af te handelen. | ||
|
Beschrijving
De toegewezen agent is de specifieke persoon die op een bepaald moment verantwoordelijk is voor het incident. Dit biedt een gedetailleerder niveau dan de SupportGroup, waardoor analyse van individuele prestaties en werkbelasting mogelijk is. Dit attribute is essentieel voor het 'Team Workload Distribution'-dashboard en de KPI 'Activity Volume per Agent StdDev'. Door het volume en de typen incidenten die door elke agent worden afgehandeld te analyseren, kunnen managers overbelaste individuen identificeren, zorgen voor een eerlijke werkverdeling en coachingmogelijkheden signaleren.
Waarom het belangrijk is
Maakt granulaire analyse mogelijk van individuele workload en prestaties, wat helpt bij het optimaliseren van resource-allocatie en het identificeren van top performers of degenen die ondersteuning nodig hebben.
Waar te verkrijgen
Een standaardveld op het HPD:Help Desk formulier, gewoonlijk Assignee genoemd.
Voorbeelden
Alice SmithBob JohnsonCharlie Brown
|
|||
|
Toegewezen supportgroep
AssignedSupportGroup
|
Het supportteam of de groep die verantwoordelijk is voor het afhandelen van het incident. | ||
|
Beschrijving
Dit attribute identificeert het team dat aan een incident is toegewezen. Naarmate een incident vordert, kan het worden heringedeeld aan verschillende supportgroepen, zoals de Service Desk, Netwerkteam of Applicatieondersteuning. Het volgen van wijzigingen in dit attribute is fundamenteel voor het dashboard 'Incident Reassignment Analysis'. Het maakt het mogelijk om handoffs tussen teams te visualiseren, het aantal overdrachten per incident te meten en bottlenecks of kennisleemtes te identificeren die leiden tot buitensporige herindelingen. Het ondersteunt ook workload distributie-analyse over teams heen.
Waarom het belangrijk is
Dit attribute is essentieel voor het analyseren van teamprestaties, workloaddistributie en de efficiëntie van routering van incidenten en handoffs.
Waar te verkrijgen
Een standaardveld op het HPD:Help Desk formulier, meestal Assigned Group genoemd.
Voorbeelden
ServicedeskNetwerkoperatiesDatabasebeheerApplicatieondersteuning Tier 2
|
|||
|
Aantal Herverdelingen
ReassignmentCount
|
Het totale aantal keren dat een incident is overgedragen tussen verschillende supportgroepen. | ||
|
Beschrijving
Dit berekend attribute telt hoe vaak het veld 'AssignedSupportGroup' is gewijzigd gedurende de lifecycle van een incident. Een groot aantal herindelingen, vaak 'ticket ping-pong' genoemd, duidt op procesinefficiënties, zoals incorrecte initiële routering of kennisleemtes binnen supportteams. Deze metric vormt de kern van de KPI 'Average Reassignments per Incident' en het dashboard 'Incident Reassignment Analysis'. Het bijhouden van dit aantal helpt om kansen te identificeren voor het verbeteren van first-call resolution rates en het stroomlijnen van het routeringsproces, waardoor uiteindelijk de oplostijd wordt verkort.
Waarom het belangrijk is
Kwantificeert procesinefficiëntie en friction, en belicht incidenten die lijden onder het doorgeven tussen teams, wat de resolution vertraagt.
Waar te verkrijgen
Berekend tijdens data transformation door het aantal unieke waarden of wijzigingen in het veld 'AssignedSupportGroup' te tellen over de lifecycle van elk incident.
Voorbeelden
0135
|
|||
|
Bedrijfsservice
BusinessService
|
De bedrijfsservice of -applicatie die door het incident is getroffen. | ||
|
Beschrijving
Dit attribute koppelt een incident aan een specifieke business service gedefinieerd in de Configuration Management Database (CMDB), zoals 'Email Service' of 'ERP Systeem'. Het analyseren van incidenten per getroffen business service is cruciaal voor het begrijpen van de impact op de organisatie. Het helpt bij het prioriteren van problem management inspanningen op services die de meeste incidenten genereren of de meeste downtime ondervinden. Deze weergave is essentieel voor het rapporteren over de IT-prestaties vanuit een business-centric perspectief.
Waarom het belangrijk is
Verbindt technische incidenten met hun business impact, waardoor analyse mogelijk wordt die werk prioriteert op basis van wat het meest kritiek is voor de organisatie.
Waar te verkrijgen
Dit is een Configuration Item (CI) veld op het incidentformulier, dat linkt naar de CMDB. Het veld kan worden gelabeld als 'Service' of 'CI'.
Voorbeelden
Zakelijke e-mailserviceSAP ERP FinancialsKlantrelatiebeheer
|
|||
|
Is Heropend
IsReopened
|
Een vlag die aangeeft of een incident opnieuw is geopend na te zijn opgelost. | ||
|
Beschrijving
Dit berekend attribute is een boolean-vlag die waar is als een incident een activiteit 'Incident Reopened' in zijn geschiedenis heeft. Een hoge frequentie van heropende incidenten kan duiden op problemen met de kwaliteit van oplossingen of voortijdige sluiting van tickets. Deze vlag wordt direct gebruikt bij het berekenen van de KPI 'Incident Re-opening Rate' en voor het dashboard 'Incident Re-opening Rate Trend'. Het stelt analisten in staat om heropende incidenten eenvoudig te filteren en te onderzoeken om de grondoorzaken te begrijpen, zoals onvolledige fixes of miscommunicatie met de gebruiker.
Waarom het belangrijk is
Deze vlag meet direct de oplossingskwaliteit en klanttevredenheid, waarbij gevallen worden benadrukt waarin de initiële oplossing niet effectief was.
Waar te verkrijgen
Dit is een berekend veld, afgeleid tijdens data transformation door te controleren of de event log van een incident een 'Heropend' activiteit of statusovergang bevat.
Voorbeelden
truefalse
|
|||
|
Is SLA Overtreden
IsSlaBreached
|
Een booleaanse vlag die aangeeft of de oplostijd van het incident de SLA-doelstelling heeft overschreden. | ||
|
Beschrijving
Dit is een vereenvoudigde flag, afgeleid van de 'SLA-status' attribute, waarbij 'waar' aangeeft dat de SLA is overschreden. Dit biedt een duidelijke, binaire uitkomst voor eenvoudige filtering en aggregatie. Deze attribute wordt gebruikt om de KPI 'Overschrijdingspercentage SLA Kritieke Incidenten' te berekenen. Het maakt een eenvoudige segmentatie mogelijk van alle incidenten in twee groepen, overschreden en niet overschreden, om de processkenmerken te analyseren die het meest voorkomen bij incidenten die de service targets niet halen.
Waarom het belangrijk is
Biedt een eenvoudig, binair outcome voor SLA compliance, waardoor het gemakkelijk is om breach rates te berekenen en de veelvoorkomende paden van non-compliant cases te analyseren.
Waar te verkrijgen
Afgeleid van het attribute 'SLAStatus' tijdens data transformation. Als 'SLAStatus' 'Breached' is, wordt deze flag op true gezet.
Voorbeelden
truefalse
|
|||
|
Kanaal
Channel
|
De methode of het kanaal waardoor het incident werd gemeld. | ||
|
Beschrijving
Het Channel attribute specificeert hoe een incident is geïnitieerd, bijvoorbeeld via telefoon, e-mail, selfserviceportaal of geautomatiseerde monitoring. Het analyseren van het proces per kanaal kan belangrijke verschillen in oplossingstijden of procespaden aan het licht brengen. Incidenten die via het selfserviceportaal zijn gemeld, kunnen bijvoorbeeld sneller worden opgelost vanwege een betere initiële datakwaliteit. Deze analyse kan leiden tot beslissingen over welke kanalen moeten worden gepromoot of verbeterd.
Waarom het belangrijk is
Helpt te begrijpen hoe de rapportagemethode de incident lifecycle beïnvloedt, waardoor kansen worden onthuld om specifieke kanalen te optimaliseren voor efficiëntie.
Waar te verkrijgen
Een standaardveld op het HPD:Help Desk formulier, vaak Reported Source genoemd.
Voorbeelden
E-mailTelefoonSelfserviceportaalSysteemmonitoring
|
|||
|
Oplossingscode
ResolutionCode
|
Een code of categorie die aangeeft hoe het incident uiteindelijk is opgelost. | ||
|
Beschrijving
De Resolution Code legt het uiteindelijke resultaat of de aard van de oplossing vast die op een incident is toegepast. Deze gestructureerde data is waardevol voor root cause analysis en om de soorten oplossingen te begrijpen die het vaakst nodig zijn. In analyse kan dit attribute worden vergeleken met de initiële 'Incidentcategorie' om de categorisatienauwkeurigheid te beoordelen. Het biedt ook inzichten in veelvoorkomende oplossingen, wat helpt bij het opbouwen van een kennisbank of het identificeren van gebieden waar automatisering kan worden toegepast.
Waarom het belangrijk is
Biedt gestructureerde data over incident outcomes, ter ondersteuning van root cause analysis en de verbetering van knowledge management en automation.
Waar te verkrijgen
Raadpleeg de BMC Helix documentatie. Dit veld is doorgaans te vinden op het resolutietabblad of de sectie van het incidentformulier.
Voorbeelden
Gebruikersfout - Training GegevenSoftwarepatch toegepastHardware VervangenGeen Fout Gevonden
|
|||
|
Oplossingsduur
ResolutionDuration
|
De totale verstreken tijd vanaf het moment dat een incident voor het eerst werd gemeld tot het moment dat het werd opgelost. | ||
|
Beschrijving
Deze metric meet de duur van de activiteit 'Incident Gemeld' tot de activiteit 'Incident Opgelost'. Het is een key performance indicator (KPI) voor de efficiëntie van het gehele incident management process. Deze berekende attribute vormt de basis voor de KPI 'Gemiddelde Oplostijd Incident' en het dashboard 'Doorlooptijd Oplossing Incident'. Het analyseren van deze duur over verschillende incidentcategorieën, prioriteiten of teams helpt bij het identificeren van systemische bronnen van vertraging en het meten van de impact van process improvement initiatives.
Waarom het belangrijk is
Dit is een belangrijke maatstaf voor processefficiëntie en customer experience, die direct weergeeft hoe lang het duurt om de service voor gebruikers te herstellen.
Waar te verkrijgen
Berekend tijdens data transformation door het tijdsverschil te bepalen tussen de timestamp van de activiteit 'Incident Resolved' en de activiteit 'Incident Reported' voor elke case.
Voorbeelden
25920000086400000604800000
|
|||
Incident Management Activiteiten
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Incident Afgesloten
|
De laatste activiteit in de levenscyclus, waarbij het incidentdossier formeel wordt gesloten en een alleen-lezen historisch record wordt. Dit gebeurt vaak automatisch na een ingestelde periode in de status 'Opgelost'. | ||
|
Waarom het belangrijk is
Deze activiteit markeert het definitieve einde van het proces. De tijd tussen 'Opgelost' en 'Gesloten' kan vertragingen in administratieve processen of termijnen voor gebruikersbevestiging benadrukken.
Waar te verkrijgen
Dit is een afzonderlijke event, afgeleid van de timestamp toen het veld 'Status' werd bijgewerkt naar 'Gesloten'. Dit wordt bijgehouden in de audit history.
Vastleggen
Filter audit logs op de statuswijziging naar 'Closed'.
Gebeurtenistype
inferred
|
|||
|
Incident Gemeld
|
Markeert de aanmaak van een nieuwe incidentregistratie in het systeem. Dit is het startpunt van de incidentlevenscyclus, meestal getriggerd door een gebruikersinzending via een portal, e-mail, of een service desk agent die het ticket handmatig aanmaakt. | ||
|
Waarom het belangrijk is
Deze activiteit is de primaire start event voor het proces. Het analyseren van de tijd vanaf deze event tot de oplossing is fundamenteel voor het meten van de totale duur van de incident lifecycle en het identificeren van stroomopwaartse vertragingen.
Waar te verkrijgen
Dit is een expliciete creation event, vastgelegd vanuit de timestamp van de 'Indieningsdatum' of 'Rapportagedatum' op het HPD:Help Desk-formulier. Het is een van de meest betrouwbare en fundamentele events in het systeem.
Vastleggen
Geregistreerd vanuit de creation timestamp van de incidentrecord in de HPD:Help Desk tabel.
Gebeurtenistype
explicit
|
|||
|
Incident Opgelost
|
Geeft aan dat een oplossing is geïmplementeerd en de service is hersteld voor de gebruiker. Dit is een belangrijke mijlpaal, meestal vastgelegd door een statuswijziging naar 'Opgelost'. | ||
|
Waarom het belangrijk is
Dit is een belangrijke mijlpaal voor het meten van de core resolution time. Het markeert het einde van de actieve werkfase en start vaak de klok voor gebruikersbevestiging of automatische sluitingsprocedures.
Waar te verkrijgen
Dit is een afzonderlijke event, afgeleid van de timestamp toen het veld 'Status' werd bijgewerkt naar 'Opgelost'. Deze wijziging wordt vastgelegd in de audit history.
Vastleggen
Filter audit logs op de statuswijziging naar 'Resolved'.
Gebeurtenistype
inferred
|
|||
|
Oplossing Geïdentificeerd
|
Vertegenwoordigt het moment waarop een support agent een oplossing heeft gevonden en deze heeft gedocumenteerd in de incidentregistratie. Het incident is nu klaar om naar een 'Resolved' status te worden verplaatst. | ||
|
Waarom het belangrijk is
Deze mijlpaal markeert het einde van de technische onderzoeksfase. De duur van dit punt tot de afsluiting kan bottlenecks blootleggen in communicatie, verificatie en administratieve processes.
Waar te verkrijgen
Dit wordt vaak afgeleid van de timestamp waarop de oplossingsdetails worden ingevoerd en opgeslagen, net voordat de status wordt gewijzigd naar 'Opgelost'.
Vastleggen
Gebruik de timestamp van de laatste wijziging voordat de status verandert naar 'Resolved'.
Gebeurtenistype
inferred
|
|||
|
Tijdelijke Oplossing Geïmplementeerd
|
Geeft aan dat een tijdelijke oplossing aan de gebruiker is geboden, waardoor de servicefunctionaliteit is hersteld terwijl aan een permanente oplossing wordt gewerkt. Dit wordt vaak vastgelegd door een specifieke vlag of status in te stellen. | ||
|
Waarom het belangrijk is
Het volgen hiervan helpt de snelheid van serviceherstel te meten, wat cruciaal is voor gebruikerstevredenheid. Het onderscheidt tijdelijke oplossingen van permanente resoluties in procesanalyse.
Waar te verkrijgen
Dit kan worden afgeleid uit de timestamp wanneer het veld 'Workaround' (Tijdelijke Oplossing) in de incidentoplossingsdetails wordt ingevuld of wanneer een specifieke status 'Workaround Provided' (Tijdelijke Oplossing Geleverd) wordt gebruikt.
Vastleggen
Gebruik de timestamp van een statuswijziging naar een 'Workaround'-status of wanneer resolutienotities die een workaround vermelden, voor het eerst worden opgeslagen.
Gebeurtenistype
inferred
|
|||
|
Toegewezen aan supportgroep
|
Deze activiteit duidt de initiële toewijzing van het incident aan een specifieke supportgroep aan voor onderzoek en oplossing. Het vertegenwoordigt de eerste handoff van de service desk naar een technisch team. | ||
|
Waarom het belangrijk is
Dit is een kritieke mijlpaal voor het bijhouden van first-touch resolution rates en initiële responstijden. Het helpt vertragingen te identificeren bij het toewijzen van het incident aan het juiste team.
Waar te verkrijgen
Geregistreerd door de eerste invulling van het veld 'Assigned Group' te volgen in de audit history van het incident (HPD:HelpDesk_AuditLogSystem).
Vastleggen
Afgeleid van de eerst geregistreerde wijziging in het veld 'Assigned Group' in de auditlogs.
Gebeurtenistype
inferred
|
|||
|
Gebruikersbevestiging Ontvangen
|
Vertegenwoordigt de bevestiging van de gebruiker dat de geboden oplossing hun probleem heeft verholpen. Dit is vaak een optionele stap en kan worden vastgelegd via een portal action of door een agent. | ||
|
Waarom het belangrijk is
De analyse van gebruikersbevestigingen helpt de communicatie-effectiviteit en oplossingskwaliteit te evalueren. Een lage frequentie kan leiden tot een hogere re-open rate.
Waar te verkrijgen
Dit is moeilijk direct vast te leggen en moet mogelijk worden afgeleid. Het kan een specifieke status zijn zoals 'Opgelost - Bevestigd' of een notitie toegevoegd aan de incident work log.
Vastleggen
Vereist system analysis. Zoek naar work log entries of status changes die gebruikersfeedback aangeven.
Gebeurtenistype
inferred
|
|||
|
Hervat vanuit Wachtstand
|
Markeert het punt waarop een incident dat in de wacht stond, wordt gereactiveerd. Dit gebeurt wanneer de benodigde informatie is ontvangen, en wordt doorgaans weergegeven doordat de status die van 'Pending' terug naar 'In Progress' verschuift. | ||
|
Waarom het belangrijk is
Deze event, gepaard met 'Incident Put On Hold' (Incident In Afwachting Gezet), maakt de precieze meting van wachttijden mogelijk. Het analyseren van lange wachttijden kan communicatieproblemen met gebruikers of derde partijen benadrukken.
Waar te verkrijgen
Afgeleid van een statuswijziging van 'Wachtende' naar een actieve status zoals 'In Behandeling'. De timestamp is beschikbaar in het auditlog.
Vastleggen
Filter audit logs op een statuswijziging van 'Pending' naar 'In Progress' of 'Assigned'.
Gebeurtenistype
inferred
|
|||
|
Incident Gecategoriseerd
|
Vertegenwoordigt de initiële classificatie van het incident, inclusief het instellen van de category, type en item. Deze activiteit wordt doorgaans uitgevoerd door een Level 1 service desk agent kort nadat het incident is gemeld. | ||
|
Waarom het belangrijk is
Het volgen van deze activiteit helpt de nauwkeurigheid van initiële classificaties te analyseren, en de impact ervan op routing en resolutie. Wijzigingen in categorisatie later in het proces duiden op herbewerking en mogelijke kennislacunes.
Waar te verkrijgen
Afgeleid van de eerste keer dat de operationele en productcategorisatievelden ('OpCat', 'ProdCat') worden gevuld in het auditlog van het incident (HPD:HelpDesk_AuditLogSystem).
Vastleggen
Identificeer de eerste timestamp waarop categorisatievelden zijn ingesteld in het auditlog.
Gebeurtenistype
inferred
|
|||
|
Incident Heropend
|
Treedt op wanneer een eerder opgelost of gesloten incident terugkeert naar een actieve status. Dit gebeurt meestal wanneer de gebruiker meldt dat het probleem opnieuw is opgetreden. | ||
|
Waarom het belangrijk is
Een hoge re-open rate duidt op problemen met de oplossingskwaliteit. Het volgen van de rework loop is cruciaal om ineffectieve fixes te analyseren en first-call resolution te verbeteren.
Waar te verkrijgen
Afgeleid van een statuswijziging van 'Opgelost' of 'Afgesloten' terug naar een actieve status zoals 'In Behandeling' of 'Toegewezen'. Deze overgang wordt geregistreerd in de audithistorie.
Vastleggen
Filter audit logs op een statuswijziging van een opgeloste/gesloten status naar een open status.
Gebeurtenistype
inferred
|
|||
|
Incident In De Wacht Gezet
|
Deze activiteit vindt plaats wanneer de voortgang van een incident wordt gepauzeerd, doorgaans in afwachting van informatie van de gebruiker of een externe leverancier. Dit wordt gewoonlijk weerspiegeld door een statuswijziging naar 'In Afwachting' (Pending). | ||
|
Waarom het belangrijk is
Deze activiteit is cruciaal voor het nauwkeurig berekenen van oplostijden. De tijd die in een 'In Afwachting' (Pending) status wordt doorgebracht, moet vaak worden uitgesloten van SLA-berekeningen om de prestaties van het supportteam objectief te meten.
Waar te verkrijgen
Afgeleid van een wijziging in het 'Status'-veld naar een 'Wachtende' status. Het auditlog registreert de timestamp van deze wijziging.
Vastleggen
Filter audit logs op statuswijzigingen naar 'Pending' of een vergelijkbare on-hold status.
Gebeurtenistype
inferred
|
|||
|
Onderzoek gestart
|
Geeft aan dat een toegewezen agent actief is begonnen met het incident. Dit wordt vaak weergegeven door een statuswijziging van 'Toegewezen' naar 'In Behandeling' of een vergelijkbare status. | ||
|
Waarom het belangrijk is
Het meten van de tijd tussen toewijzing en de start van het onderzoek onthult wachttijden en helpt de responsiviteit van agents en de werklastcapaciteit te beoordelen.
Waar te verkrijgen
Dit wordt afgeleid uit een wijziging in het veld 'Status' van 'Toegewezen' naar 'In behandeling'. De timestamp van deze statuswijziging wordt vastgelegd in de audit log.
Vastleggen
Filter audit logs op de eerste statuswijziging naar 'In Progress' na een toewijzing.
Gebeurtenistype
inferred
|
|||
|
Overgedragen naar een Andere Groep
|
Vertegenwoordigt de reassignment van een incident van de ene support group naar de andere. Dit gebeurt doorgaans wanneer de initiële group het probleem niet kan oplossen en expertise van een ander team nodig heeft. | ||
|
Waarom het belangrijk is
Frequente transfers, of 'ping-ponging', zijn een belangrijke bron van vertraging en inefficiëntie. Het analyseren van deze activiteiten helpt bij het identificeren van routing issues, skill gaps en procesknelpunten.
Waar te verkrijgen
Afgeleid van een wijziging in de waarde van het veld 'Assigned Group' in de audithistorie van het incident, volgend op de initiële toewijzing.
Vastleggen
Elke wijziging aan het veld 'Assigned Group' in de audit log na de eerste toewijzing vertegenwoordigt een overdracht.
Gebeurtenistype
inferred
|
|||
|
SLA-overschrijding gedetecteerd
|
Een berekende event die optreedt wanneer de reactie- of oplostijd van een incident de SLA-doelstellingen overschrijdt. Dit is geen directe systeem event. | ||
|
Waarom het belangrijk is
Het identificeren van SLA-overschrijdingen is cruciaal voor compliancemonitoring en het prioriteren van kritieke incidenten. Dit helpt te bepalen welke fasen van het proces het meest bijdragen aan overtredingen.
Waar te verkrijgen
Deze event wordt berekend door de timestamp van de activiteit 'Incident Resolved' (of andere SLA-mijlpalen) te vergelijken met de 'Reported Date' (Meldingsdatum) en de gedefinieerde SLA-doelstelling voor de prioriteit van dat incident.
Vastleggen
Afleiden door de resolution timestamp te vergelijken met de start timestamp plus de SLA duur.
Gebeurtenistype
calculated
|
|||