Data Template: Incident Management

Bmc Helix
Data Template: Incident Management

Uw Incident Management Data Template

Deze template biedt een duidelijke roadmap voor het verzamelen van de essentiële data die nodig is om uw Incident Management proces in Bmc Helix te analyseren en te optimaliseren. Het beschrijft de cruciale attributes en activiteiten om bij te houden, samen met praktische richtlijnen voor data-extractie. Door deze template te volgen, legt u een uitgebreide en nauwkeurige basis voor process discovery en verbetering.
  • Aanbevolen attributen om vast te leggen
  • Belangrijkste activiteiten om te volgen
  • Extractiehandleiding voor BMC Helix
Nieuw met event logs? Leer hoe u een process mining event log creëert.

Incident Management Attributes

Dit zijn de aanbevolen datavelden om op te nemen in uw event log voor een uitgebreide analyse van uw Incident Management proces.
5 Verplicht 7 Aanbevolen 7 Optioneel
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
Verplicht Aanbevolen Optioneel

Incident Management Activiteiten

Dit zijn de belangrijkste processtappen en mijlpalen om vast te leggen in uw event log voor accurate process discovery en analyse.
6 Aanbevolen 8 Optioneel
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
Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit BMC Helix haalt