Jouw datatemplate voor incidentbeheer
Jouw datatemplate voor incidentbeheer
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Extractie-instructies voor Jira Service Management
Attributen voor incidentbeheer
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteit
ActivityName
|
De naam van de specifieke gebeurtenis of statuswijziging die voor het incident heeft plaatsgevonden. | ||
|
Beschrijving
De activiteit staat voor een afzonderlijke stap of gebeurtenis in de levenscyclus van incidentbeheer, zoals 'Incident Created', 'Incident Assigned' of 'Resolution Proposed'. Deze worden meestal afgeleid uit statuswijzigingen of specifieke updates in de geschiedenis of changelog van de Jira-issue. Door de volgorde en duur van deze activiteiten te analyseren, zie je het werkelijke procesverloop, bottlenecks en afwijkingen.
Waarom dit belangrijk is
Activiteiten vormen de basis van de procesmap. Zo kun je de levenscyclus van incidenten visualiseren en analyseren.
Waar je het vindt
Afgeleid uit de geschiedenis en changelogdata van de Jira-issue, met statuswijzigingen en updates van belangrijke velden.
Voorbeelden
Incident toegewezenOnderzoek gestartIncident opgelost
|
|||
|
Incident-ID
IncidentId
|
De unieke identificatie voor elk incidentticket in Jira Service Management. | ||
|
Beschrijving
De Incident-ID, in Jira vaak de Issue Key genoemd, is de primaire unieke identificatie voor elk gemeld incident. De ID koppelt alle bijbehorende activiteiten, opmerkingen en statuswijzigingen vanaf het aanmaken tot en met het definitief sluiten. In process mining is deze ID essentieel om de volledige levenscyclus van elk afzonderlijk incident te reconstrueren en het hele proces te analyseren.
Waarom dit belangrijk is
Dit is de belangrijkste identificatie om alle gerelateerde gebeurtenissen aan één case te koppelen. Daarmee vormt de ID de basis voor elke process mining-analyse.
Waar je het vindt
Dit is het standaardveld 'Key' voor een issue in Jira Service Management, bijvoorbeeld 'ITSM-123'.
Voorbeelden
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Starttijd
EventTimestamp
|
De exacte datum en tijd waarop de activiteit plaatsvond. | ||
|
Beschrijving
Dit attribuut registreert de timestamp van elke activiteit in de levenscyclus van het incident. Je gebruikt deze gegevens om doorlooptijden, cyclustijden en wachttijden tussen processtappen te berekenen. Nauwkeurige timestamps maken gedetailleerde prestatieanalyses, SLA-monitoring en bottleneckidentificatie mogelijk. Alle prestatiemetrics, zoals oplostijd en diagnoseduur, worden uit deze timestamps afgeleid.
Waarom dit belangrijk is
Timestamps zijn essentieel om alle tijdgebonden metrics te berekenen, de procesduur te begrijpen en prestatiebottlenecks te vinden.
Waar je het vindt
Dit is de datum waarop elke vermelding in de changelog of geschiedenis van het Jira-issue is aangemaakt.
Voorbeelden
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de data is geëxtraheerd. | ||
|
Beschrijving
Dit attribuut geeft aan waar de data vandaan komt. In dit geval is dat Jira Service Management. Het is vooral nuttig in omgevingen waarin data uit meerdere systemen wordt gecombineerd voor een volledig procesoverzicht. Door het bronsysteem vast te leggen, blijft de herkomst van de data duidelijk en kun je problemen met datakwaliteit of data-extractie beter onderzoeken. Voor dit model is de waarde statisch.
Waarom dit belangrijk is
Geeft belangrijke context over de herkomst van de data en zorgt voor duidelijkheid en traceerbaarheid, vooral bij analyses met meerdere systemen.
Waar je het vindt
Dit is een statische waarde die tijdens de data-extractie moet worden toegevoegd.
Voorbeelden
Jira Service ManagementJira Cloud
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor het laatst vanuit het bronsysteem is vernieuwd. | ||
|
Beschrijving
Dit attribuut legt vast wanneer de dataset voor het laatst is bijgewerkt. Het geeft iedereen die het proces analyseert belangrijke context en maakt duidelijk hoe actueel de data is. Dat is vooral belangrijk voor procesdashboards die je doorlopend gebruikt om te monitoren. Actuele informatie is nodig om op tijd beslissingen te nemen. De waarde is meestal hetzelfde voor alle events binnen één data-extractiebatch.
Waarom dit belangrijk is
Laat zien hoe actueel de data is. Dat is belangrijk voor de relevantie en nauwkeurigheid van de analyse.
Waar je het vindt
Dit is de timestamp van de data-extractie, die tijdens de datatransformatie wordt toegevoegd.
Voorbeelden
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Aanmaakdatum
CreatedDate
|
De datum en tijd waarop het incident voor het eerst in het systeem is aangemaakt. | ||
|
Beschrijving
Dit attribuut markeert het officiële begin van de levenscyclus van het incident. Het is de basis-timestamp voor het berekenen van algemene metingen, zoals de totale oplostijd. De aanmaakdatum is statisch voor elk incident en vormt het startpunt van de volledige case in de process mining-analyse.
Waarom dit belangrijk is
Vormt het startpunt voor alle end-to-end-berekeningen van de doorlooptijd en voor SLA-metingen.
Waar je het vindt
Het standaardveld 'Created' op een Jira-issue.
Voorbeelden
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Oplosdatum
ResolutionDate
|
De datum en tijd waarop het incident als opgelost is gemarkeerd. | ||
|
Beschrijving
Dit attribuut legt de timestamp vast waarop het incident voor het eerst de status opgelost kreeg. Het markeert het einde van de actieve werkfase en is het eindpunt voor het berekenen van de Time to Resolution. Door de oplosdatum met de aanmaakdatum te vergelijken, krijg je de belangrijkste maatstaf voor procesefficiëntie. De datum speelt ook een belangrijke rol bij het bepalen van SLA-naleving.
Waarom dit belangrijk is
Markeert het einde van het oplossingsproces en maakt het mogelijk om de totale doorlooptijd en SLA-prestaties te berekenen.
Waar je het vindt
Het standaardveld 'Resolved' op een Jira-issue.
Voorbeelden
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Prioriteit
Priority
|
Het prioriteitsniveau dat aan het incident is toegewezen en de urgentie van de oplossing aangeeft. | ||
|
Beschrijving
Prioriteit bepaalt hoe snel een incident moet worden behandeld. Vaak is de prioriteit gebaseerd op een combinatie van impact en urgentie en heeft deze direct invloed op SLA-doelen. Door incidenten per prioriteit te analyseren, zie je of incidenten met een hoge prioriteit sneller worden behandeld dan incidenten met een lage prioriteit en of de prioritering consequent wordt toegepast. Dit is een belangrijke dimensie om procesprestaties te filteren en te vergelijken.
Waarom dit belangrijk is
Essentieel voor SLA-analyses en om te controleren of capaciteit goed wordt ingezet voor de meest kritieke incidenten.
Waar je het vindt
Het standaardveld 'Priority' op een Jira-issue.
Voorbeelden
HoogsteHoogGemiddeldLaag
|
|||
|
Status
Status
|
De huidige fase van het incident in de levenscyclus. | ||
|
Beschrijving
Het veld Status geeft de huidige toestand van een incident binnen de vastgelegde workflow aan, zoals 'Open', 'In Progress', 'Pending Customer' of 'Resolved'. Statuswijzigingen zijn de belangrijkste bron voor het genereren van het activiteitenlog voor process mining. Door de tijd per status te analyseren, herken je knelpunten en zie je waar incidenten de meeste tijd doorbrengen.
Waarom dit belangrijk is
Geeft de voortgang van het incident rechtstreeks weer en is de belangrijkste bron voor het herkennen van processtappen en wachttijden.
Waar je het vindt
Het standaardveld 'Status' op een Jira-issue.
Voorbeelden
In behandelingWachten op klantOpgelostGesloten
|
|||
|
Toegewezen medewerker
Assignee
|
De gebruiker die op dat moment aan het incident werkt. | ||
|
Beschrijving
De toegewezen medewerker is de agent of gebruiker die op een bepaald moment verantwoordelijk is voor het incident. Door wijzigingen in de toegewezen medewerker te volgen, kun je overdrachten analyseren, de verdeling van de werklast begrijpen en zien welke personen bij specifieke processtappen betrokken zijn. Met dit attribuut kun je vragen beantwoorden over individuele prestaties en de inzet van capaciteit binnen supportteams.
Waarom dit belangrijk is
Helpt de werklast per persoon te volgen, knelpunten rond specifieke agents te herkennen en de invloed van overdrachten op de oplostijd te analyseren.
Waar je het vindt
Het standaardveld 'Assignee' op een Jira-issue.
Voorbeelden
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Toewijzingsgroep
AssignmentGroup
|
Het team of de groep die verantwoordelijk is voor de afhandeling van het incident. | ||
|
Beschrijving
De toewijzingsgroep is het team waaraan het incident is toegewezen. Dat kan een supportniveau zijn, zoals 'L1 Helpdesk', een gespecialiseerd team zoals 'Network Operations' of een developmentteam. Door overgangen tussen toewijzingsgroepen te analyseren, krijg je inzicht in escalaties en overdrachten. Je kunt de prestaties van teams meten, knelpunten op teamniveau herkennen en afhankelijkheden tussen teams analyseren.
Waarom dit belangrijk is
Belangrijk voor het analyseren van teamprestaties, doorvoer en de werkflow tussen verschillende supportniveaus of gespecialiseerde groepen.
Waar je het vindt
Dit wordt vaak geïmplementeerd als een aangepast veld in Jira, zoals 'Team' of 'Assignment Group'. Soms kan het worden afgeleid uit Jira Components of Project Roles.
Voorbeelden
Ondersteuning niveau 1InfrastructuurteamDatabasebeheerders
|
|||
|
Aantal overdrachten
HandoffCount
|
Het aantal keer dat het incident opnieuw is toegewezen aan een andere groep of gebruiker. | ||
|
Beschrijving
Deze berekende metriek telt hoe vaak het veld 'Assignee' of 'AssignmentGroup' tijdens de levenscyclus van het incident is gewijzigd. Een hoog aantal overdrachten wijst vaak op inefficiëntie in het proces, een lage first-call resolution of kennishiaten. Dat leidt tot langere oplostijden. Met deze KPI kun je het toewijzingsproces verbeteren en de samenwerking tussen teams versterken.
Waarom dit belangrijk is
Maakt de procesfrictie en inefficiëntie door her toewijzen meetbaar. Zo zie je waar ruimte is voor procesverbetering.
Waar je het vindt
Berekend door het aantal wijzigingen in het veld 'Assignee' of 'AssignmentGroup' in de changelog van het issue te tellen.
Voorbeelden
015
|
|||
|
Categorie van de hoofdoorzaak
RootCauseCategory
|
De classificatie van de onderliggende hoofdoorzaak van het incident. | ||
|
Beschrijving
Dit attribuut legt de belangrijkste reden voor het incident vast, zoals 'Software Defect', 'Hardware Failure' of 'User Error'. Meestal wordt het na onderzoek ingevuld. Het is belangrijk voor effectief probleembeheer en het voorkomen van nieuwe incidenten. Door hoofdoorzaakcategorieën te analyseren, zie je structurele zwakke plekken en kun je verbeterinitiatieven prioriteren. Een hoog aandeel 'Unknown'-hoofdoorzaken kan erop wijzen dat het onderzoek beter moet.
Waarom dit belangrijk is
Maakt hoofdoorzaakanalyse mogelijk. Zo kun je van een reactieve naar een proactieve aanpak gaan door de oorzaken van incidenten te identificeren en aan te pakken.
Waar je het vindt
Dit is in Jira vrijwel altijd een aangepast veld. De naam en opties hangen sterk af van de specifieke configuratie van de organisatie.
Voorbeelden
ConfiguratiefoutNetwerkstoringSoftwarebug
|
|||
|
Component
Component
|
Het systeem, de applicatie of het infrastructuuronderdeel dat door het incident is getroffen. | ||
|
Beschrijving
Components zijn onderdelen van een Jira-project waarmee je issues in kleinere groepen kunt indelen, zoals 'User Interface', 'Database' of 'API'. Door incidenten per component te analyseren, zie je welke onderdelen van een systeem het vaakst problemen veroorzaken. Deze informatie helpt bij de analyse van de hoofdoorzaak en kan richting geven aan verbeteringen van de dienstverlening of het verminderen van technische schuld.
Waarom dit belangrijk is
Maakt filtering en analyse mogelijk op basis van het specifieke product- of systeemgebied dat is getroffen, zodat technologiehotspots kunnen worden geïdentificeerd.
Waar je het vindt
Het standaardveld 'Components' op een Jira-issue.
Voorbeelden
AuthenticatieserviceRapportagedashboardMobiele app
|
|||
|
Doel voor oplostijd
TimeToResolutionTarget
|
De SLA-doelduur voor het oplossen van het incident. | ||
|
Beschrijving
Dit attribuut bepaalt binnen welke maximale tijd een incident met een bepaalde prioriteit of een bepaald type naar verwachting moet zijn opgelost. Het is de norm waarmee je de werkelijke oplostijd vergelijkt om de SLA-compliance te bepalen. De waarde wordt meestal dynamisch ingesteld op basis van regels voor onder andere prioriteit, ernst of issuetype. Dit is een belangrijke basis voor elk dashboard voor SLA-prestatiemonitoring.
Waarom dit belangrijk is
Biedt de norm voor het meten van SLA-compliance en vormt de basis voor de KPI Incident SLA Breach Rate.
Waar je het vindt
Dit wordt afgeleid uit de SLA-configuratie in Jira Service Management. Het specifieke doel, bijvoorbeeld 'Time to resolution', moet worden vastgesteld.
Voorbeelden
4 uur8 uur3 dagen
|
|||
|
Ernst
Severity
|
De mate waarin het incident impact heeft op de bedrijfsvoering. | ||
|
Beschrijving
Ernst geeft aan hoeveel impact een incident op de bedrijfsvoering heeft, van één getroffen gebruiker tot een kritieke systeemstoring. Prioriteit bepaalt de volgorde van het werk, terwijl ernst de totale impact op de organisatie beschrijft. Door op ernst te analyseren, krijg je inzicht in de procesprestaties van incidenten die voor de organisatie het belangrijkst zijn. Vaak combineer je ernst met prioriteit voor een genuanceerdere analyse.
Waarom dit belangrijk is
Geeft inzicht in de impact op de bedrijfsvoering, zodat je de analyse kunt richten op incidenten die de organisatie het zwaarst raken.
Waar je het vindt
Meestal een aangepast veld in Jira, omdat dit geen standaard systeemveld is. Raadpleeg de projectconfiguratie van Jira Service Management.
Voorbeelden
KritiekGrootKleinTriviaal
|
|||
|
ID van gekoppeld Problem
LinkedProblemId
|
De identificatie van een Problem-ticket dat aan dit incident is gekoppeld. | ||
|
Beschrijving
Incidenten die symptomen zijn van een groter onderliggend probleem, worden vaak gekoppeld aan een Problem-ticket. In dit veld staat het ID van dat gekoppelde Problem. Door deze koppelingen te analyseren, krijg je zicht op de relatie tussen incidenten en problemen, meet je hoe effectief het probleembeheer werkt en vind je terugkerende incidenten waarvoor een permanente oplossing nodig is.
Waarom dit belangrijk is
Verbindt incidenten met onderliggende problemen. Zo kun je analyseren hoe effectief de organisatie hoofdoorzaken aanpakt om nieuwe incidenten te voorkomen.
Waar je het vindt
Deze informatie staat in het gedeelte 'Issue Links' van een Jira-issue.
Voorbeelden
PROB-123PROB-456Geen
|
|||
|
Is herwerk
IsRework
|
Een vlag die aangeeft of het incident herwerk heeft ondergaan, bijvoorbeeld doordat het opnieuw is geopend. | ||
|
Beschrijving
Dit berekende booleaanse attribuut identificeert incidenten die naar een eerdere processtap zijn teruggestuurd. Meestal gebeurt dat doordat ze na het oplossen opnieuw zijn geopend. Herwerklussen zijn een belangrijke bron van inefficiëntie en ontevredenheid bij klanten. Met deze vlag kun je het herwerkpercentage eenvoudig berekenen en analyseren waarom incidenten niet in één keer goed worden opgelost.
Waarom dit belangrijk is
Maakt kwaliteitsproblemen en inefficiëntie in het proces zichtbaar door incidenten met herhaald werk te markeren. Daarmee ondersteunt het rechtstreeks de analyse van herwerk.
Waar je het vindt
Berekend door specifieke reeksen van statusovergangen in het event log te detecteren, zoals 'Resolved' -> 'Reopened'.
Voorbeelden
truefalse
|
|||
|
Issuetype
IssueType
|
Het type issue, zoals Incident, Service Request of Problem. | ||
|
Beschrijving
Jira gebruikt Issuetypes om verschillende soorten taken van elkaar te onderscheiden. Binnen Incidentbeheer is het primaire type 'Incident', maar ook andere types, zoals 'Sub-task', kunnen relevant zijn. Dit attribuut is belangrijk om de dataset te filteren op alleen incidenten, zodat de process mining-analyse zich op het juiste proces richt.
Waarom dit belangrijk is
Zorgt ervoor dat de analyse alleen betrekking heeft op incidenten en deze onderscheidt van andere werktypes, zoals service requests of changes.
Waar je het vindt
Het standaardveld 'Issue Type' op een Jira-issue.
Voorbeelden
IncidentIT-hulpBug
|
|||
|
Melder
Reporter
|
De gebruiker die het incident oorspronkelijk heeft aangemaakt of gemeld. | ||
|
Beschrijving
De melder is de persoon, vaak een eindgebruiker of een ander systeem, die het incident als eerste heeft geregistreerd. Door incidenten per melder te analyseren, kun je gebruikers of afdelingen herkennen die vaak problemen ervaren. Je kunt ook communicatiepatronen onderzoeken, vooral bij activiteiten zoals 'Waiting for Customer' en 'Customer Responded'.
Waarom dit belangrijk is
Helpt bij het analyseren van incidentbronnen, het herkennen van patronen rond specifieke gebruikers of afdelingen en het begrijpen van vertragingen in de interactie met gebruikers.
Waar je het vindt
Het standaardveld 'Reporter' op een Jira-issue.
Voorbeelden
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Oplossing
Resolution
|
Het uiteindelijke resultaat of de reden waarom het incident is opgelost. | ||
|
Beschrijving
Het veld Resolution legt uit waarom een incident de status opgelost heeft gekregen. Veelvoorkomende oplossingen zijn 'Fixed', 'Duplicate', 'Won't Do' of 'Cannot Reproduce'. Door de verdeling van oplossingstypen te analyseren, krijg je inzicht in de kwaliteit van binnenkomende meldingen en de effectiviteit van het oplossingsproces. Een groot aantal oplossingen met 'Duplicate' kan bijvoorbeeld wijzen op een probleem bij het aanmaken of triageren van incidenten.
Waarom dit belangrijk is
Geeft context bij het resultaat van een incident. Zo kun je oplossingen categoriseren en patronen herkennen in de manier waarop incidenten worden afgesloten.
Waar je het vindt
Het standaardveld 'Resolution' op een Jira-issue. Dit veld wordt meestal ingevuld wanneer een issue overgaat naar een statuscategorie 'Done'.
Voorbeelden
GereedOpgelostDubbelWordt niet opgelost
|
|||
|
SLA-overschrijding
SlaBreach
|
Een vlag die aangeeft of de oplostijd van het incident langer was dan het SLA-doel. | ||
|
Beschrijving
Dit berekende booleaanse attribuut geeft aan of een incident de SLA voor 'Time to Resolution' heeft overschreden. De waarde is true als 'IncidentResolutionCycleTime' groter is dan 'TimeToResolutionTarget'. Deze vlag vereenvoudigt analyse en visualisatie. Je kunt eenvoudig filteren en aggregeren om de KPI SLA Breach Rate te berekenen. Het is de belangrijkste uitkomstmaat voor het dashboard voor SLA-prestatiemonitoring.
Waarom dit belangrijk is
Geeft een duidelijke binaire uitkomst voor SLA-prestaties. Zo kun je overschrijdingspercentages eenvoudig berekenen en probleemgebieden vinden.
Waar je het vindt
Berekend als ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Voorbeelden
truefalse
|
|||
|
Type klantverzoek
CustomerRequestType
|
Het specifieke type verzoek dat de klant via het serviceportal heeft ingediend. | ||
|
Beschrijving
Dit veld deelt verzoeken in vanuit het perspectief van de klant, zoals weergegeven in het Jira Service Management-portal, bijvoorbeeld 'Een systeemprobleem melden'. Het biedt een gebruiksvriendelijke indeling van het incident, die kan verschillen van het interne 'Issue Type'. Analyse van dit attribuut laat zien hoe klanten problemen ervaren en melden. Daarmee kun je het portalontwerp en het serviceaanbod verbeteren.
Waarom dit belangrijk is
Geeft een klantgerichte kijk op incidentcategorieën. Dat is nuttig om de vraag te analyseren en de klantervaring te verbeteren.
Waar je het vindt
Het veld 'Customer Request Type', specifiek voor Jira Service Management-projecten.
Voorbeelden
IT-hulp krijgen > Systeemprobleem meldenE-mail > Toegangsaanvraag
|
|||
Incidentbeheeractiviteiten
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Incident aangemaakt
|
Dit markeert het officiële begin van de incidentlevenscyclus, zodra een incidentmelding is ingediend en in Jira een nieuwe issue is aangemaakt. De gebeurtenis wordt expliciet vastgelegd wanneer in het systeem een nieuwe issue van het type 'Incident' wordt geregistreerd. | ||
|
Waarom dit belangrijk is
Dit is de primaire startgebeurtenis van het proces. Door de tijd tussen deze activiteit en de oplossing te analyseren, meet je de totale doorlooptijd en SLA-naleving.
Waar je het vindt
Dit is een expliciete gebeurtenis die wordt vastgelegd op basis van de timestamp 'created' van de incidentissue in Jira. De aanmaakgebeurtenis staat in de geschiedenis van de issue.
Vastleggen
Gebruik de timestamp waarop de issue is aangemaakt.
Eventtype
explicit
|
|||
|
Incident gesloten
|
Dit staat voor het definitief administratief sluiten van het incidentticket nadat het is opgelost en gecontroleerd. Je leidt dit af uit de statuswijziging naar 'Closed'. | ||
|
Waarom dit belangrijk is
Dit is de laatste gebeurtenis van het proces. Door de tijd tussen 'Resolved' en 'Closed' te analyseren, zie je vertraging bij administratieve afronding of bevestiging door de gebruiker.
Waar je het vindt
Dit wordt afgeleid uit de statuswijzigingsgeschiedenis van de issue. De gebeurtenis valt op de timestamp waarop de status verandert naar de definitieve toestand 'Closed'.
Vastleggen
Identificeer de timestamp van de statuswijziging naar 'Closed'.
Eventtype
inferred
|
|||
|
Incident opgelost
|
Deze activiteit bevestigt dat het incident succesvol is opgelost en de dienstverlening is hersteld. Vaak valt dit samen met de overgang naar de status 'Resolved'. | ||
|
Waarom dit belangrijk is
Dit is de belangrijkste succesmijlpaal in het proces. De tijd tot dit moment is de meest gebruikte KPI en staat voor de Time to Resolution (TTR).
Waar je het vindt
Dit wordt afgeleid uit de statuswijziging naar 'Resolved'. In veel workflows is dit dezelfde gebeurtenis als 'Resolution Proposed' en vormt dit het belangrijkste oplossingsmoment.
Vastleggen
Identificeer de timestamp van de statuswijziging naar 'Resolved'.
Eventtype
inferred
|
|||
|
Incident opnieuw toegewezen
|
Dit gebeurt wanneer een incident na de eerste toewijzing van de ene medewerker of groep naar een andere wordt overgedragen. Je leidt deze gebeurtenis af uit elke wijziging in het veld 'Assignee' of 'Assigned Group'. | ||
|
Waarom dit belangrijk is
Door herverdelingen te volgen, analyseer je overdrachten. Een groot aantal herverdelingen wijst vaak op inefficiënte processen, kennishiaten of een verkeerde eerste routering. Dat leidt tot vertraging bij de oplossing.
Waar je het vindt
Dit wordt afgeleid uit de issuegeschiedenis door elke update van het veld 'Assignee' te detecteren nadat het veld voor het eerst is ingevuld. Elke wijziging telt als een gebeurtenis waarbij het incident opnieuw wordt toegewezen.
Vastleggen
Identificeer latere wijzigingen van het veld 'Assignee' na de eerste toewijzing.
Eventtype
inferred
|
|||
|
Onderzoek gestart
|
Dit geeft aan dat een toegewezen medewerker actief is begonnen met het onderzoeken van de oorzaak van het incident. Meestal wordt dit afgeleid wanneer de status van de incidentissue verandert van 'Open' of 'New' naar 'In Progress'. | ||
|
Waarom dit belangrijk is
Deze belangrijke mijlpaal markeert het begin van de actieve oplossing. Door de tijd tot deze activiteit te meten, zie je waar wachtrijen ontstaan en of er voldoende capaciteit beschikbaar is.
Waar je het vindt
Dit wordt afgeleid uit de statuswijzigingsgeschiedenis van de issue. De timestamp van de gebeurtenis is het moment waarop de status verandert naar een toestand die actief werk aangeeft, zoals 'In Progress'.
Vastleggen
Identificeer de timestamp van de statuswijziging naar 'In Progress'.
Eventtype
inferred
|
|||
|
Oplossing voorgesteld
|
Deze activiteit geeft aan dat een oplossing is gevonden en uitgevoerd, maar dat het incident nog wacht op bevestiging of een laatste controle. Je leidt dit af uit de statuswijziging naar 'Resolved'. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal die het einde van het actieve werk door het supportteam markeert. Vaak stopt op dit moment de SLA-klok.
Waar je het vindt
Dit wordt afgeleid uit de statuswijzigingsgeschiedenis van de issue. De timestamp van de gebeurtenis is het moment waarop de status verandert naar 'Resolved' of een vergelijkbare toestand.
Vastleggen
Identificeer de timestamp van de statuswijziging naar 'Resolved'.
Eventtype
inferred
|
|||
|
Wachten op klant
|
Dit markeert het moment waarop het supportteam wacht op informatie of actie van de klant. Je leidt dit af uit een statuswijziging naar een speciale wachtstatus, zoals 'Waiting for customer'. | ||
|
Waarom dit belangrijk is
Door deze tijd als 'on hold' apart te houden, meet je SLA's nauwkeuriger. Deze tijd wordt vaak niet meegerekend in de oplostijd. Ook zie je zo hoe lang klanten over hun reactie doen.
Waar je het vindt
Dit wordt afgeleid uit de statuswijzigingsgeschiedenis van de issue. De gebeurtenis valt op het moment waarop de status verandert naar 'Waiting for customer' of een vergelijkbare toestand.
Vastleggen
Identificeer de timestamp van de statuswijziging naar 'Waiting for customer'.
Eventtype
inferred
|
|||
|
Geëscaleerd naar specialistisch team
|
Dit betekent dat het incident is geëscaleerd naar een gespecialiseerd team, bijvoorbeeld Tier 2 of Development, voor geavanceerde ondersteuning. Je leidt dit af uit een wijziging in een aangepast veld 'Support Team' of uit een specifieke herverdeling. | ||
|
Waarom dit belangrijk is
Hiermee zie je welke incidenten specialistische kennis nodig hebben en hoe ze tussen supportniveaus bewegen. Zo kun je bottlenecks binnen specialistische teams vinden en escalatiepatronen analyseren.
Waar je het vindt
Dit wordt afgeleid uit de issuegeschiedenis door wijzigingen in een aangepast veld voor het toegewezen team te volgen. Je kunt ook een wijziging van 'Assignee' naar een lid van een bekende specialistengroep identificeren.
Vastleggen
Detecteer een wijziging in een aangepast veld voor 'Assigned Team' of specifieke wijzigingen van de toegewezen medewerker.
Eventtype
inferred
|
|||
|
Gekoppeld aan probleemticket
|
Dit gebeurt wanneer een incident wordt gekoppeld aan een 'Problem'-issue voor hoofdoorzaakanalyse. Het is een expliciete gebeurtenis die wordt vastgelegd wanneer een link 'relates to' of 'caused by' naar een issuetype 'Problem' wordt aangemaakt. | ||
|
Waarom dit belangrijk is
Door deze koppeling te volgen, zie je hoe goed de organisatie de overgang maakt van incidentbeperking naar hoofdoorzaakanalyse en preventie.
Waar je het vindt
Dit is een expliciete gebeurtenis in de linkgeschiedenis van de issue. Elke aangemaakte link heeft een timestamp en kan worden gefilterd op links naar het issuetype 'Problem'.
Vastleggen
Gebruik de timestamp waarop de issuelink naar een issuetype 'Problem' is aangemaakt.
Eventtype
explicit
|
|||
|
Incident geprioriteerd
|
Dit staat voor het instellen van de prioriteit en/of ernst van het incident. Die bepaalt de urgentie en de impact op de bedrijfsvoering. Meestal wordt dit afgeleid van het eerste moment waarop de velden 'Priority' of 'Severity' na het aanmaken worden ingevuld of bijgewerkt. | ||
|
Waarom dit belangrijk is
Door prioritering te volgen, zie je of incidenten snel en consistent worden beoordeeld. Vertraging in deze stap kan SLA-berekeningen en de inzet van capaciteit direct beïnvloeden.
Waar je het vindt
Dit wordt afgeleid uit het logboek van de issuegeschiedenis, waarin wijzigingen in alle velden worden bijgehouden. Zoek naar de eerste wijziging van 'Priority' of een aangepast veld 'Severity' na het aanmaken van de issue.
Vastleggen
Detecteer de eerste wijziging van het veld 'Priority' in de issuegeschiedenis.
Eventtype
inferred
|
|||
|
Incident heropend
|
Dit staat voor een eerder opgelost incident dat opnieuw actief wordt omdat het probleem terugkeert of de oplossing niet werkt. Je leidt dit af uit een statuswijziging van 'Resolved' of 'Closed' terug naar een open status. | ||
|
Waarom dit belangrijk is
Heropende incidenten meten rechtstreeks de oplossingskwaliteit en zijn een belangrijke indicator voor herstelwerk. Door deze gebeurtenissen te analyseren, vind je voortijdig gesloten tickets en ineffectieve oplossingen.
Waar je het vindt
Dit wordt afgeleid uit de statuswijzigingsgeschiedenis van de issue. De gebeurtenis wordt vastgelegd wanneer de status van een eindtoestand, zoals 'Resolved' of 'Closed', teruggaat naar 'Open' of 'In Progress'.
Vastleggen
Detecteer de statuswijziging van 'Resolved' of 'Closed' naar een open status.
Eventtype
inferred
|
|||
|
Incident toegewezen
|
Deze activiteit staat voor de eerste toewijzing van het incident aan een supportmedewerker of groep. Je legt dit vast door te kijken wanneer het veld 'Assignee' of 'Assigned Group' voor het eerst wordt ingevuld. | ||
|
Waarom dit belangrijk is
Hiermee meet je de eerste respons- en toewijzingstijd, een belangrijk onderdeel van SLA-metrics. Zo zie je welke vertraging ontstaat voordat het actieve onderzoek begint.
Waar je het vindt
Dit wordt afgeleid uit de issuegeschiedenis door de eerste wijziging van het veld 'Assignee' te identificeren waarbij de vorige waarde 'Unassigned' was.
Vastleggen
Detecteer de eerste update van het veld 'Assignee' in de issuegeschiedenis.
Eventtype
inferred
|
|||
|
Klant heeft gereageerd
|
Dit geeft aan dat de klant de gevraagde informatie heeft aangeleverd en dat het incident verder kan. Je leidt dit af wanneer de status niet langer 'Waiting for customer' is en teruggaat naar een actieve status. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert het einde van een vertraging door de klant. Door de tijd tussen 'Waiting For Customer' en deze gebeurtenis te analyseren, bereken je de gemiddelde reactietijd van klanten.
Waar je het vindt
Dit wordt afgeleid uit de statuswijzigingsgeschiedenis van de issue. De gebeurtenis vindt plaats wanneer de status verandert van 'Waiting for customer' naar bijvoorbeeld 'In Progress', vaak nadat de klant een opmerking heeft toegevoegd.
Vastleggen
Detecteer de statuswijziging van 'Waiting for customer' naar 'In Progress'.
Eventtype
inferred
|
|||
|
Opmerking toegevoegd
|
Dit staat voor elke communicatie- of notitiegebeurtenis waarbij een gebruiker een opmerking aan het incidentticket toevoegt. Het is een expliciete gebeurtenis die telkens wordt vastgelegd wanneer een opmerking wordt geplaatst. | ||
|
Waarom dit belangrijk is
Door de frequentie van opmerkingen te analyseren, krijg je zicht op communicatiepatronen, samenwerking en de complexiteit van een incident. Zo zie je welke incidenten uitzonderlijk veel communicatie vragen.
Waar je het vindt
Dit is een expliciete gebeurtenis. Jira bewaart elke opmerking met een timestamp en auteur. Je vindt deze gegevens in de opmerkingengeschiedenis van de issue of via de API.
Vastleggen
Gebruik de timestamp van elke opmerking die aan de issue is toegevoegd.
Eventtype
explicit
|
|||
|
Workaround geboden
|
Dit staat voor de invoering van een tijdelijke oplossing om de dienstverlening te herstellen terwijl aan een permanente oplossing wordt gewerkt. Je kunt dit afleiden uit een statuswijziging of een specifieke opmerking. | ||
|
Waarom dit belangrijk is
De tijd tot het bieden van een workaround is een belangrijke indicator voor de snelheid waarmee de dienstverlening wordt hersteld. Zo maak je onderscheid tussen tijdelijke beperking van de impact en een permanente oplossing.
Waar je het vindt
Dit wordt vaak afgeleid. Het kan gaan om een overgang naar de status 'Workaround Provided' of om een openbare opmerking met specifieke zoekwoorden, zoals 'workaround'.
Vastleggen
Identificeer een specifieke statuswijziging of een zoekwoord in een opmerking.
Eventtype
inferred
|
|||
Extractiegidsen
Klaar om te beginnen?
Gebruik deze datatemplate om je incidentbeheer te verbeteren, inefficiënties te vinden en incidenten sneller op te lossen. Begin vandaag met het optimaliseren van je proces.
Optimaliseer je incidentbeheer en los incidenten sneller op
Verlaag je MTTR met 35% en verhoog de tevredenheid van gebruikers met efficiëntere processen.
Geen creditcard nodig • Instellen in 5 minuten