Data template: Incident Management
Uw Incidentmanagement Data template
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Extractiehandleiding voor Jira Service Management
Incident Management attributen
| 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
|
|||
Incident Management activiteiten
| 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
|
|||