Data template: Incident Management

Jira Service Management
Data template: Incident Management

Uw Incidentmanagement Data template

Deze template biedt een gestructureerde aanpak voor het verzamelen van de essentiële data voor het analyseren van uw incident management process. Het schetst de cruciale attributes om te verzamelen, de belangrijkste activities om te volgen en biedt praktische richtlijnen voor het extraheren van deze informatie uit uw bronsysteem. Dit zorgt ervoor dat u over alle noodzakelijke componenten beschikt om uw incident resolution workflows te optimaliseren.
  • Aanbevolen attributen om vast te leggen
  • Belangrijkste activiteiten om te volgen
  • Extractiehandleiding voor Jira Service Management
Nieuw met event logs? Leer hoe u een process mining event log creëert.

Incident Management attributen

Dit zijn de aanbevolen datavelden om op te nemen in uw event log voor een uitgebreide analyse van uw incident management process.
5 Verplicht 7 Aanbevolen 12 Optioneel
Naam Beschrijving
Activiteit
ActivityName
De naam van de specifieke event of statuswijziging die zich voordeed voor het incident.
Beschrijving

De Activiteit vertegenwoordigt een afzonderlijke stap of event in de levenscyclus van incidentbeheer, zoals 'Incident Created', 'Incident Assigned' of 'Resolution Proposed'. Deze zijn doorgaans afgeleid van statusovergangen of specifieke update-events die zijn vastgelegd in de historie of changelog van het Jira-issue. Het analyseren van de volgorde en duur van deze activiteiten is het primaire doel van process mining, waarbij de werkelijke processtroom, knelpunten en afwijkingen worden onthuld.

Waarom het belangrijk is

Activiteiten vormen de ruggengraat van de proceskaart, waardoor visualisatie en analyse van de incidentlevenscyclus mogelijk zijn.

Waar te verkrijgen

Afgeleid van de Jira issue history en changelog data, waarbij status transitions en belangrijke veldupdates worden vastgelegd.

Voorbeelden
Incident toegewezenOnderzoek gestartIncident opgelost
Incident ID
IncidentId
De unieke identifier voor elk incident ticket in Jira Service Management.
Beschrijving

De Incident ID, vaak aangeduid als de Issue Key in Jira, dient als de primaire unieke identificatie voor elk gerapporteerd incident. Het koppelt alle bijbehorende activiteiten, opmerkingen en statuswijzigingen vanaf het moment van aanmaak tot de uiteindelijke afsluiting. In process mining is deze ID essentieel voor het reconstrueren van de end-to-end levenscyclus van elk individueel incident, wat een uitgebreide analyse van het hele proces mogelijk maakt.

Waarom het belangrijk is

Dit is de kernidentificatie die wordt gebruikt om alle gerelateerde events te correleren tot één case, waardoor het de basis vormt voor elke process mining analyse.

Waar te verkrijgen

Dit is het standaard 'Key' field voor een issue in Jira Service Management (bijv. 'ITSM-123').

Voorbeelden
INC-10234HELPDESK-5678OPS-9901
Starttijd
EventTimestamp
De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving

Dit kenmerk registreert de timestamp voor elke activity in de incident lifecycle. Het is cruciaal voor het berekenen van duur, cycle times en wachttijden tussen verschillende stappen in het proces. Nauwkeurige timestamps maken gedetailleerde performance analysis, SLA monitoring en bottleneckidentificatie mogelijk. Alle performance metrics, zoals resolutietijd en diagnoseduur, zijn afgeleid van deze timestamps.

Waarom het belangrijk is

Timestamps zijn essentieel voor het berekenen van alle tijdgebaseerde metrics, het begrijpen van de procesduur en het opsporen van performance bottlenecks.

Waar te verkrijgen

Dit is de 'created' datum die is gekoppeld aan elke invoer in de changelog of historie van de Jira issue.

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 kenmerk identificeert de herkomst van de data, in dit geval Jira Service Management. Het is bijzonder nuttig in omgevingen waar data uit meerdere systemen wordt gecombineerd voor een holistisch procesoverzicht. Het specificeren van het bronsysteem zorgt voor duidelijke data lineage en helpt bij het diagnosticeren van datakwaliteit of extractieproblemen. Voor dit model zou de waarde statisch zijn.

Waarom het belangrijk is

Biedt essentiële context over de dataherkomst, wat zorgt voor duidelijkheid en traceerbaarheid, met name bij multi-systeemanalyses.

Waar te verkrijgen

Dit is een statische waarde die moet worden toegevoegd tijdens het data-extractieproces.

Voorbeelden
Jira Service ManagementJira Cloud
Laatste data-update
LastDataUpdate
De timestamp die de laatste keer aangeeft dat de data is ververst vanuit het bronsysteem.
Beschrijving

Dit kenmerk registreert wanneer de dataset voor het laatst is bijgewerkt. Het biedt cruciale context aan iedereen die het proces analyseert, en zorgt ervoor dat u op de hoogte bent van de actualiteit van de data. Dit is vooral belangrijk voor monitoring dashboards waar actuele informatie cruciaal is voor het nemen van tijdige beslissingen. De waarde is doorgaans hetzelfde voor alle events binnen één data-extractiebatch.

Waarom het belangrijk is

Informeert gebruikers over de actualiteit van de data, wat cruciaal is voor de relevantie en nauwkeurigheid van de analyse.

Waar te verkrijgen

Dit is de timestamp van de data-extractierun, toegevoegd tijdens het data transformation process.

Voorbeelden
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Aanmaakdatum
CreatedDate
De datum en tijd waarop het incident voor het eerst werd aangemaakt in het systeem.
Beschrijving

Dit kenmerk markeert de officiële start van de incident lifecycle. Het is de basis timestamp van waaruit algemene metrics zoals de totale resolutietijd worden berekend. De aanmaakdatum is een statische waarde voor elk incident en dient als startpunt voor de gehele case in de process mining analyse.

Waarom het belangrijk is

Dient als startpunt voor alle end-to-end doorlooptijdberekeningen en SLA-metingen.

Waar te verkrijgen

Het standaard 'Created'-veld op een Jira issue.

Voorbeelden
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Oplossingsdatum
ResolutionDate
De datum en tijd waarop het incident werd gemarkeerd als opgelost.
Beschrijving

Dit attribuut legt de timestamp vast wanneer het incident voor het eerst naar een opgeloste status werd verplaatst. Het markeert het einde van de actieve werkfase en is het eindpunt voor het berekenen van de Time to Resolution. Het vergelijken van de oplossingsdatum met de aanmaakdatum biedt de primaire maatstaf voor procesefficiëntie. Het is ook een belangrijke component bij het bepalen van SLA compliance.

Waarom het belangrijk is

Markeert het einde van het resolution process, waardoor de berekening van de totale cycle time en SLA performance mogelijk is.

Waar te verkrijgen

Het standaard 'Resolved'-veld op een Jira issue.

Voorbeelden
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Prioriteit
Priority
Het prioriteitsniveau dat aan het incident is toegewezen, dat de urgentie van de oplossing aangeeft.
Beschrijving

Prioriteit bepaalt de vereiste snelheid voor het aanpakken van een incident. Het is vaak een combinatie van impact en urgentie en beïnvloedt direct SLA targets. Het analyseren van incidenten op prioriteit helpt om te begrijpen of high-priority incidenten sneller worden afgehandeld dan low-priority incidenten en of prioritization consistent wordt toegepast. Het is een kritische dimensie voor het filteren en vergelijken van process performance.

Waarom het belangrijk is

Essentieel voor SLA-prestatieanalyse en voor het verifiëren dat resources correct zijn toegewezen aan de meest kritieke incidenten.

Waar te verkrijgen

Het standaard 'Priority'-veld op een Jira issue.

Voorbeelden
HoogsteHoogGemiddeldLaag
Resolution Cycle Time
IncidentResolutionCycleTime
De totale verstreken tijd van incidentaanmaak tot oplossing.
Beschrijving

Dit is een berekende metric die de duur weergeeft vanaf de 'CreatedDate' tot de 'ResolutionDate'. Het is een van de belangrijkste KPI's in incident management, en meet direct de efficiëntie van het gehele proces. Het analyseren van deze metric over verschillende dimensies zoals prioriteit, assignment group of component helpt te identificeren welke factoren de grootste impact hebben op de performance.

Waarom het belangrijk is

Meet direct de end-to-end efficiëntie van het incident management proces en is een primaire KPI voor performance tracking.

Waar te verkrijgen

Berekend als ('ResolutionDate' - 'CreatedDate').

Voorbeelden
2h 30m1d 4h5d 1h 15m
Status
Status
De huidige fase van het incident in zijn levenscyclus.
Beschrijving

Het Status-veld geeft de huidige status van een incident aan binnen de gedefinieerde workflow, zoals 'Open', 'In Progress', 'Pending Customer' of 'Resolved'. Statuswijzigingen zijn de primaire bron voor het genereren van het activity log voor process mining. Het analyseren van de tijd die incidenten in elke status doorbrengen is essentieel voor het identificeren van knelpunten en het begrijpen waar incidenten de meeste tijd doorbrengen.

Waarom het belangrijk is

Weerspiegelt direct de voortgang van het incident en is de primaire bron voor het identificeren van processtappen en wachttijden.

Waar te verkrijgen

Het standaard 'Status'-veld op een Jira issue.

Voorbeelden
In uitvoeringWachten op klantOpgelostGesloten
Toegewezen gebruiker
Assignee
De gebruiker die momenteel is toegewezen om aan het incident te werken.
Beschrijving

De Assignee is de individuele medewerker of gebruiker die op een bepaald moment verantwoordelijk is voor het incident. Het volgen van wijzigingen aan de assignee is cruciaal voor het analyseren van overdrachten, het begrijpen van de werkverdeling en het identificeren welke personen betrokken zijn bij specifieke processtappen. Dit attribuut helpt vragen te beantwoorden over individuele prestaties en de toewijzing van middelen binnen de supportteams.

Waarom het belangrijk is

Helpt bij het volgen van individuele werkbelasting, het identificeren van knelpunten gerelateerd aan specifieke agenten, en het analyseren van de impact van handoffs op de oplossingstijd.

Waar te verkrijgen

Het standaard 'Assignee'-veld 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 Assignment Group vertegenwoordigt het team dat aan het incident is toegewezen. Dit kan een ondersteuningsniveau zijn zoals 'L1 Helpdesk', een gespecialiseerd team zoals 'Network Operations' of een ontwikkelteam. Het analyseren van overgangen tussen toewijzingsgroepen is essentieel voor het begrijpen van procesescalaties en overdrachten. Het maakt het meten van teamprestaties, het identificeren van knelpunten op teamniveau en de analyse van interteam-afhankelijkheden mogelijk.

Waarom het belangrijk is

Cruciaal voor het analyseren van teamprestaties, doorvoer en de workflow tussen verschillende ondersteuningsniveaus of gespecialiseerde groepen.

Waar te verkrijgen

Dit wordt vaak geïmplementeerd als een custom field in Jira, zoals 'Team' of 'Assignment Group'. Het kan soms worden afgeleid van Jira Components of Project Roles.

Voorbeelden
Tier 1 SupportInfrastructuurteamDatabasebeheerders
Aantal handoffs
HandoffCount
Het aantal keren dat het incident opnieuw werd toegewezen aan een andere groep of gebruiker.
Beschrijving

Deze berekende metric telt hoe vaak het 'Assignee' of 'AssignmentGroup' field is gewijzigd gedurende de lifecycle van het incident. Een hoog aantal handoffs duidt vaak op procesinefficiëntie, gebrek aan first-call resolution of kennisleemtes, wat leidt tot langere resolutietijden. Het analyseren van deze KPI helpt het toewijzingsproces te stroomlijnen en de samenwerking binnen het team te verbeteren.

Waarom het belangrijk is

Kwantificeert procesfrictie en inefficiëntie veroorzaakt door herindelingen, wat helpt bij het identificeren van kansen voor procesverbetering.

Waar te verkrijgen

Berekend door het aantal wijzigingen in het veld 'Assignee' of 'AssignmentGroup' in de changelog van de issue te tellen.

Voorbeelden
015
Component
Component
Het systeem, de applicatie of een deel van de infrastructuur dat is getroffen door het incident.
Beschrijving

Components zijn subsecties van een Jira-project die worden gebruikt om issues in kleinere delen te groeperen, zoals 'User Interface', 'Database' of 'API'. Het analyseren van incidenten per component helpt om te bepalen welke delen van een systeem het meest gevoelig zijn voor problemen. Deze informatie is waardevol voor root cause analysis en kan inspanningen richten op serviceverbetering of technical debt reductie.

Waarom het belangrijk is

Maakt filteren en analyseren mogelijk op basis van het specifieke product- of getroffen systeemgebied, en helpt zo bij het identificeren van technologische 'hotspots'.

Waar te verkrijgen

Het standaard 'Components'-veld op een Jira issue.

Voorbeelden
AuthenticatieserviceReporting DashboardMobiele app
Ernst
Severity
De maatstaf voor de zakelijke impact van het incident.
Beschrijving

Ernst definieert hoeveel impact een incident heeft op de bedrijfsvoering, van een enkele gebruiker die wordt getroffen tot een kritieke systeemuitval. Hoewel Prioriteit de werkvolgorde bepaalt, informeert Ernst over de algehele bedrijfsimpact. Analyseren op ernst helpt bij het begrijpen van de procesprestaties voor incidenten die het meest van belang zijn voor het bedrijf en wordt vaak gebruikt in combinatie met Prioriteit voor een meer genuanceerde analyse.

Waarom het belangrijk is

Biedt inzicht in de bedrijfsimpact, waardoor de analyse gericht kan worden op de incidenten die de meeste schade toebrengen aan de bedrijfsvoering.

Waar te verkrijgen

Doorgaans een custom field in Jira, aangezien het geen standaard systeemveld is. Raadpleeg de projectconfiguratie van Jira Service Management.

Voorbeelden
KritiekMajorMinorTriviaal
Gekoppeld Problem ID
LinkedProblemId
De identifier van een probleemticket dat is gekoppeld aan dit incident.
Beschrijving

Incidenten die symptomen zijn van een groter, onderliggend probleem zijn vaak gekoppeld aan een probleemticket. Dit veld bevat de ID van dat gekoppelde Probleem. Het analyseren van deze koppelingen helpt om de relatie tussen incidenten en problemen te begrijpen, de effectiviteit van het probleembeheerproces te meten en terugkerende incidenten te identificeren die een permanente oplossing vereisen.

Waarom het belangrijk is

Koppelt incidenten aan onderliggende problemen, waardoor analyse mogelijk wordt van hoe effectief de organisatie root causes aanpakt om toekomstige incidenten te voorkomen.

Waar te verkrijgen

Deze informatie is opgeslagen in de 'Issue Links' sectie van een Jira issue.

Voorbeelden
PROB-123PROB-456Geen
Is herstelwerk
IsRework
Een vlag die aangeeft of het incident is herbewerkt, zoals opnieuw geopend.
Beschrijving

Dit berekende boolean attribute identificeert incidenten die zijn teruggestuurd naar een vorige fase in het proces, meestal door opnieuw te worden geopend nadat ze waren opgelost. Herstelrondes (rework loops) zijn een belangrijke bron van inefficiëntie en klantontevredenheid. Deze flag maakt eenvoudige kwantificering van het herstelpercentage mogelijk en helpt de analyse te richten op waarom incidenten niet in één keer correct worden opgelost.

Waarom het belangrijk is

Belicht proceskwaliteitsproblemen en inefficiënties door incidenten te markeren die herhaald werk vereisen, wat direct herwerkanalyse ondersteunt.

Waar te verkrijgen

Berekend door specifieke reeksen van status transitions in de event log te detecteren, zoals 'Resolved' -> 'Reopened'.

Voorbeelden
truefalse
Issue Type
IssueType
Het type issue, zoals Incident, Service Request of Problem.
Beschrijving

Jira gebruikt Issue Types om verschillende soorten taken te onderscheiden. In een Incident Management-context is het primaire type 'Incident', maar andere, zoals 'Sub-task', kunnen ook relevant zijn. Dit attribute is cruciaal voor het filteren van de dataset om alleen incidenten op te nemen, zodat de process mining-analyse zich richt op het juiste process.

Waarom het belangrijk is

Zorgt ervoor dat de analyse correct is afgebakend voor incidenten, en deze scheidt van andere werktypen zoals serviceverzoeken of wijzigingen.

Waar te verkrijgen

Het standaard 'Issue Type'-veld op een Jira issue.

Voorbeelden
IncidentIT HulpBug
Klantaanvraagtype
CustomerRequestType
Het specifieke type aanvraag ingediend door de klant via de serviceportal.
Beschrijving

Dit field categoriseert verzoeken vanuit het perspectief van de klant, zoals gepresenteerd op het Jira Service Management portal (bijv. 'Meld een systeemprobleem'). Het biedt een gebruiksvriendelijke classificatie van het incident, die kan verschillen van het interne 'Issue Type'. Het analyseren van dit attribute kan inzicht geven in hoe klanten problemen waarnemen en melden, wat helpt bij het verbeteren van het portal design en dienstenaanbod.

Waarom het belangrijk is

Biedt een klantgericht overzicht van incidentcategorieën, nuttig voor het analyseren van de vraag en het verbeteren van de klantervaring.

Waar te verkrijgen

Het veld 'Customer Request Type', specifiek voor Jira Service Management projecten.

Voorbeelden
IT-hulp krijgen > Een systeemprobleem meldenE-mail > Toegangsverzoek
Melder
Reporter
De gebruiker die het incident initieel heeft aangemaakt of gemeld.
Beschrijving

De Reporter is de individuele persoon, vaak een eindgebruiker of een ander systeem, die het incident voor het eerst heeft geregistreerd. Het analyseren van incidenten per reporter kan helpen gebruikers of afdelingen te identificeren die frequent problemen ondervinden. Het kan ook worden gebruikt om communicatiepatronen te begrijpen, vooral bij het analyseren van activiteiten zoals 'Waiting for Customer' en 'Customer Responded'.

Waarom het belangrijk is

Helpt bij het analyseren van incidentbronnen, het identificeren van patronen gerelateerd aan specifieke gebruikers of afdelingen, en het begrijpen van vertragingen bij klantinteractie.

Waar te verkrijgen

Het standaard 'Reporter'-veld op een Jira issue.

Voorbeelden
Alice JohnsonBob Williamsmonitoring-tool@example.com
Oorzaakcategorie
RootCauseCategory
De classificatie van de onderliggende grondoorzaak van het incident.
Beschrijving

Dit attribuut legt de fundamentele reden vast waarom het incident zich voordeed, zoals 'Software Defect', 'Hardware Failure' of 'User Error'. Het wordt doorgaans na onderzoek gevuld en is essentieel voor effectief problem management en de preventie van toekomstige incidenten. Het analyseren van grondoorzaakcategorieën helpt systemische zwaktes te identificeren en verbeterinitiatieven te prioriteren. Een hoog percentage 'Onbekende' grondoorzaken kan duiden op de noodzaak van betere onderzoeksprocessen.

Waarom het belangrijk is

Maakt root cause analysis mogelijk, en helpt zo om van een reactieve naar een proactieve aanpak te gaan door de bronnen van incidenten te identificeren en aan te pakken.

Waar te verkrijgen

Dit is vrijwel altijd een custom field in Jira. De naam en opties zijn sterk afhankelijk van de specifieke configuratie van de organisatie.

Voorbeelden
ConfiguratiefoutNetwerkstoringSoftware Bug
Oplossing
Resolution
Het uiteindelijke resultaat of de reden voor het oplossen van het incident.
Beschrijving

Het Resolution-veld verklaart waarom een incident naar een opgeloste status is verplaatst. Veelvoorkomende oplossingen zijn 'Fixed', 'Duplicate', 'Won't Do' of 'Cannot Reproduce'. Het analyseren van de verdeling van oplossingstypen kan inzichten verschaffen in de kwaliteit van inkomende meldingen en de effectiviteit van het oplossingsproces. Een groot aantal 'Duplicate' oplossingen kan bijvoorbeeld duiden op een probleem in de incidentaanmaak- of triagestadium.

Waarom het belangrijk is

Biedt context aan de uitkomst van een incident, helpt bij het categoriseren van oplossingen en het identificeren van trends in hoe incidenten worden afgesloten.

Waar te verkrijgen

Het standaard 'Resolution'-veld op een Jira issue. Dit veld wordt doorgaans ingesteld wanneer een issue overgaat naar een 'Done' statuscategorie.

Voorbeelden
KlaarOpgelostDuplicaatWordt Niet Opgelost
SLA Breach
SlaBreach
Een vlag die aangeeft of de oplossingstijd van het incident de SLA-doelstelling heeft overschreden.
Beschrijving

Dit berekende boolean attribute geeft aan of een incident de 'Time to Resolution' SLA heeft overschreden. Het is true als de 'IncidentResolutionCycleTime' groter is dan de 'TimeToResolutionTarget'. Deze flag vereenvoudigt analyse en visualisatie, waardoor eenvoudig filteren en aggregeren mogelijk is om de algehele SLA Breach Rate KPI te berekenen. Het is de belangrijkste uitkomstmaat voor het dashboard voor SLA-prestatiemonitoring.

Waarom het belangrijk is

Biedt een helder, binair resultaat voor SLA performance, waardoor het eenvoudig is om breach rates te berekenen en probleemgebieden te identificeren.

Waar te verkrijgen

Berekend als ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').

Voorbeelden
truefalse
Time To Resolution Target
TimeToResolutionTarget
De SLA doelduur voor het oplossen van het incident.
Beschrijving

Dit kenmerk definieert de verwachte maximale tijd waarbinnen een incident van een bepaalde prioriteit of type moet worden opgelost. Het is de maatstaf waartegen de feitelijke resolutietijd wordt gemeten om de SLA-compliance te bepalen. Deze waarde wordt doorgaans dynamisch ingesteld op basis van regels die rekening houden met factoren zoals prioriteit, ernst of type probleem. Het is essentieel voor elk dashboard voor SLA-prestatiemonitoring.

Waarom het belangrijk is

Biedt de benchmark voor het meten van SLA compliance, wat de basis vormt voor de Incident SLA Breach Rate KPI.

Waar te verkrijgen

Dit is afgeleid van de SLA configuration binnen Jira Service Management. Het specifieke doel (bijv. 'Time to resolution') moet worden geïdentificeerd.

Voorbeelden
4h8h3d
Verplicht Aanbevolen Optioneel

Incident Management activiteiten

Dit zijn de belangrijke processtappen en mijlpalen die u moet vastleggen in uw event log voor nauwkeurige ontdekking en analyse van uw workflows voor incidentoplossing.
7 Aanbevolen 8 Optioneel
Activiteit Beschrijving
Incident aangemaakt
Markeert de officiële start van de incident lifecycle wanneer een incidentrapport wordt ingediend en een nieuw issue wordt aangemaakt in Jira. Deze event wordt expliciet vastgelegd wanneer een nieuw issue van het type 'Incident' in het systeem wordt gelogd.
Waarom het belangrijk is

Dit is de primaire start event voor het proces. Het analyseren van de tijd vanaf deze activity tot resolutie is fundamenteel voor het meten van de totale cycle time en SLA-adherence.

Waar te verkrijgen

Dit is een expliciete event die is vastgelegd via de 'created' timestamp van de incident issue in Jira. De issue creation event wordt gelogd in de historie van de issue.

Vastleggen

Gebruik de timestamp van de aanmaak van het issue.

Gebeurtenistype explicit
Incident gesloten
Vertegenwoordigt de definitieve, administratieve afsluiting van het incidentticket nadat het is opgelost en geverifieerd. Dit wordt afgeleid uit de statusovergang naar 'Gesloten'.
Waarom het belangrijk is

Dit is de terminal event van het proces. Het analyseren van de tijd tussen 'Resolved' en 'Closed' kan vertragingen in administratieve afhandeling of gebruikersbevestigingsprocessen onthullen.

Waar te verkrijgen

Afgeleid uit de statuswijzigingshistorie van de issue. Het event komt overeen met de timestamp waarop de status overgaat naar de uiteindelijke 'Gesloten' status.

Vastleggen

Identificeer de timestamp van de statusovergang naar 'Gesloten'.

Gebeurtenistype inferred
Incident heringedeeld
Treedt op wanneer een incident wordt overgedragen van de ene agent of group naar de andere na de initiële toewijzing. Deze event wordt afgeleid van elke wijziging in het veld 'Assignee' of 'Assigned Group'.
Waarom het belangrijk is

Het bijhouden van hertoezendingen is cruciaal voor overdrachtsanalyse. Een groot aantal hertoezendingen duidt vaak op procesinefficiënties, kennisleemtes of onjuiste initiële routering, wat leidt tot vertragingen in de oplossing.

Waar te verkrijgen

Afgeleid uit de issue history door elke update van het 'Assignee'-veld te detecteren nadat het voor het eerst was ingevuld. Elke wijziging vormt een reassignment event.

Vastleggen

Identificeer daaropvolgende wijzigingen in het veld 'Toegewezen aan' na de initiële toewijzing.

Gebeurtenistype inferred
Incident opgelost
Deze activiteit markeert de bevestiging dat het incident succesvol is opgelost en de dienst is hersteld. Het valt vaak samen met de overgang naar de 'Resolved' status.
Waarom het belangrijk is

Dit is de primaire succesmijlpaal in het proces. De duur tot dit punt is de meest voorkomende KPI, die de Time to Resolution (TTR) vertegenwoordigt.

Waar te verkrijgen

Afgeleid uit de statuswijziging naar 'Opgelost'. In veel workflows is dit hetzelfde event als 'Oplossing voorgesteld', wat het belangrijkste resolutiepunt vertegenwoordigt.

Vastleggen

Identificeer de timestamp van de statusovergang naar 'Opgelost'.

Gebeurtenistype inferred
Onderzoek gestart
Geeft aan dat een toegewezen medewerker actief is begonnen met het diagnosticeren van het incident. Dit wordt doorgaans afgeleid wanneer de status van het incident overgaat van 'Open' of 'Nieuw' naar 'In behandeling'.
Waarom het belangrijk is

Deze belangrijke mijlpaal markeert het begin van actieve resolutie-inspanningen. Het meten van de tijd tot deze activity helpt bij het identificeren van initiële wachtrijvertragingen en resource beschikbaarheidsproblemen.

Waar te verkrijgen

Afgeleid uit de statuswijzigingshistorie van de issue. De timestamp van het event is wanneer de status overgaat naar een status die actief werk vertegenwoordigt, zoals 'In behandeling'.

Vastleggen

Identificeer de timestamp van de statusovergang naar 'In uitvoering'.

Gebeurtenistype inferred
Oplossing Voorgesteld
Deze activiteit geeft aan dat een oplossing is geïdentificeerd en geïmplementeerd, en het incident in afwachting is van bevestiging of finale validatie. Het wordt afgeleid uit de statusovergang naar 'Resolved'.
Waarom het belangrijk is

Dit is een belangrijke mijlpaal die het einde van de actieve werkzaamheden door het supportteam markeert. Het is vaak de event die de SLA-klok stopt.

Waar te verkrijgen

Afgeleid uit de statuswijzigingshistorie van de issue. De timestamp van het event is wanneer de status overgaat naar 'Opgelost' of een gelijkwaardige status.

Vastleggen

Identificeer de timestamp van de statusovergang naar 'Opgelost'.

Gebeurtenistype inferred
Wachten Op Klant
Markeert een punt waarop het supportteam wacht op informatie of actie van de klant. Dit wordt afgeleid van een status transition naar een specifieke wachtstatus zoals 'Waiting for customer'.
Waarom het belangrijk is

Het isoleren van deze tijd in wachtstand is cruciaal voor nauwkeurige SLA-metingen, aangezien deze vaak wordt uitgesloten van resolutietijdberekeningen. Het helpt bij het analyseren van klantreactievertragingen.

Waar te verkrijgen

Afgeleid uit de statuswijzigingshistorie van de issue. Het event komt overeen met de timestamp waarop de status wijzigt naar 'Wachten op klant' of een vergelijkbare status.

Vastleggen

Identificeer de timestamp van de statusovergang naar 'Wachten op klant'.

Gebeurtenistype inferred
Geëscaleerd naar gespecialiseerd team
Betekent dat het incident is geëscaleerd naar een gespecialiseerd team (bijv. Tier 2, Development) voor geavanceerde ondersteuning. Dit wordt afgeleid uit een wijziging in een aangepast veld 'Support Team' of een specifieke herindeling.
Waarom het belangrijk is

Belicht incidenten die gespecialiseerde kennis vereisen en volgt de flow tussen verschillende supportniveaus. Dit helpt bij het identificeren van knelpunten binnen gespecialiseerde teams en het analyseren van escalatiepatronen.

Waar te verkrijgen

Afgeleid uit de issue history door wijzigingen te volgen in een custom field dat het toegewezen team vertegenwoordigt of door een 'Assignee'-wijziging naar een lid van een bekende specialistische groep te identificeren.

Vastleggen

Detecteer een wijziging in een custom field voor 'Assigned Team' of specifieke wijzigingen van de assignee.

Gebeurtenistype inferred
Gekoppeld aan Problem Ticket
Treedt op wanneer een incident wordt gekoppeld aan een 'Problem' issue voor root cause analysis. Dit is een expliciete event die wordt vastgelegd wanneer een 'relates to' of 'caused by' link wordt gemaakt naar een Problem issue type.
Waarom het belangrijk is

Het volgen van deze link is essentieel om te begrijpen hoe effectief de organisatie overgaat van incidentmitigatie naar root cause analysis en preventie.

Waar te verkrijgen

Dit is een expliciete event die is gelogd in de link history van de issue. Elke link creation heeft een timestamp en kan worden gefilterd op links naar het 'Problem' issue type.

Vastleggen

Gebruik de timestamp van de aanmaak van een issue-link naar een issue type 'Problem'.

Gebeurtenistype explicit
Incident geprioriteerd
Vertegenwoordigt het instellen van de prioriteit en/of ernst van het incident, wat de urgentie en bedrijfsimpact ervan bepaalt. Dit wordt doorgaans afgeleid uit de eerste keer dat de velden 'Prioriteit' of 'Ernst' worden ingevuld of bijgewerkt na aanmaak.
Waarom het belangrijk is

Het volgen van prioritering helpt analyseren of incidenten snel en consistent worden beoordeeld. Vertragingen in deze stap kunnen direct van invloed zijn op SLA-berekeningen en resource-allocatie.

Waar te verkrijgen

Afgeleid uit het issue history log, dat wijzigingen in alle velden bijhoudt. Zoek naar de eerste update van het 'Prioriteit'- of een custom 'Severity'-veld na het aanmaak-event van de issue.

Vastleggen

Detecteer de eerste wijziging in het 'Priority' field in de issue history.

Gebeurtenistype inferred
Incident heropend
Vertegenwoordigt een situatie waarin een eerder opgelost incident opnieuw wordt geactiveerd omdat het probleem zich herhaalde of de oplossing ineffectief was. Dit wordt afgeleid uit een statusverandering van 'Opgelost' of 'Gesloten' terug naar een open status.
Waarom het belangrijk is

Heropende incidenten zijn een directe maatstaf voor de kwaliteit van de oplossing en een belangrijke indicator voor herbewerking. Het analyseren van deze events helpt bij het identificeren van vroegtijdige afsluitingen en ineffectieve oplossingen.

Waar te verkrijgen

Afgeleid uit de statuswijzigingshistorie van de issue. Het event wordt geregistreerd wanneer de status vanuit een eindstatus zoals 'Opgelost' of 'Gesloten' terugkeert naar 'Open' of 'In behandeling'.

Vastleggen

Detecteer status change van 'Resolved' of 'Closed' naar een open status.

Gebeurtenistype inferred
Incident toegewezen
Deze activiteit duidt op de initiële toewijzing van het incident aan een supportmedewerker of -groep voor afhandeling. Het wordt vastgelegd door de eerste keer te volgen dat het 'Assignee'- of 'Assigned Group'-veld wordt gevuld.
Waarom het belangrijk is

Meet de initiële reactie- en toewijzingstijd, wat een belangrijke component is van SLA metrics. Het helpt vertragingen te identificeren voordat actief onderzoek begint.

Waar te verkrijgen

Afgeleid uit de issue history door de eerste wijziging in het 'Assignee'-veld te identificeren waarbij de vorige waarde 'Niet toegewezen' was.

Vastleggen

Detecteer de eerste update van het 'Assignee' field in de issue history.

Gebeurtenistype inferred
Klant Heeft Gereageerd
Geeft aan dat de klant de gevraagde informatie heeft verstrekt en dat het incident kan worden voortgezet. Dit wordt afgeleid wanneer de status vanuit 'Wachten op klant' terugkeert naar een actieve status.
Waarom het belangrijk is

Deze activiteit markeert het einde van een door de klant veroorzaakte vertraging. Het analyseren van de duur tussen 'Waiting For Customer' en dit event onthult de gemiddelde responstijd van de klant.

Waar te verkrijgen

Afgeleid uit de statuswijzigingshistorie van de issue. Het event vindt plaats wanneer de status overgaat van 'Wachten op klant' naar een status zoals 'In behandeling', vaak getriggerd doordat de klant een opmerking toevoegt.

Vastleggen

Detecteer status change van 'Waiting for customer' naar 'In Progress'.

Gebeurtenistype inferred
Opmerking Toegevoegd
Vertegenwoordigt elke communicatie of notitie waarbij een gebruiker een opmerking toevoegt aan het incidentticket. Dit is een expliciete event die wordt vastgelegd telkens wanneer een opmerking wordt geplaatst.
Waarom het belangrijk is

Het analyseren van de commentaarfrequentie kan inzicht bieden in communicatiepatronen, samenwerkingsefficiëntie en de complexiteit van een incident. Het kan incidenten aan het licht brengen die buitensporige communicatie vereisen.

Waar te verkrijgen

Dit is een expliciete event. Jira slaat elke comment op met een timestamp en auteur, beschikbaar via de comment history van de issue of de API.

Vastleggen

Gebruik de timestamp van elke comment die aan het issue is toegevoegd.

Gebeurtenistype explicit
Workaround Aangeboden
Vertegenwoordigt de implementatie van een tijdelijke oplossing om de dienstverlening te herstellen terwijl een permanente oplossing wordt ontwikkeld. Dit kan worden afgeleid uit een statuswijziging of een specifieke opmerking.
Waarom het belangrijk is

Het meten van de tijd die nodig is om een workaround te bieden, is een belangrijke indicator voor de snelheid van service restoration. Het helpt onderscheid te maken tussen een tijdelijke oplossing en een permanente resolution.

Waar te verkrijgen

Dit wordt vaak afgeleid. Het kan een transitie zijn naar een 'Workaround Provided' status of de toevoeging van een publieke comment die specifieke keywords zoals 'workaround' bevat.

Vastleggen

Identificeer een specifieke statusovergang of trefwoord in een opmerking.

Gebeurtenistype inferred
Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit Jira Service Management haalt