Datatemplate voor incidentbeheer
Datatemplate voor incidentbeheer
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Instructies voor data-extractie uit Jira Service Management
Attributen voor incidentbeheer
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteit
ActivityName
|
De naam van de specifieke gebeurtenis of statuswijziging voor het incident. | ||
|
Beschrijving
De activiteit is een afzonderlijke stap of gebeurtenis in de levenscyclus van incidentbeheer, zoals ‘Incident aangemaakt’, ‘Incident toegewezen’ of ‘Oplossing voorgesteld’. Activiteiten worden meestal afgeleid van statusovergangen of specifieke updates in de geschiedenis of het wijzigingslogboek van het Jira-issue. Door de volgorde en duur van activiteiten te analyseren, zie je hoe het proces daadwerkelijk verloopt, waar bottlenecks zitten en waar het afwijkt.
Waarom dit belangrijk is
Activiteiten vormen de basis van de proceskaart en maken het mogelijk de levenscyclus van incidenten te visualiseren en analyseren.
Waar vind je dit?
Afgeleid uit de geschiedenis en het wijzigingslogboek van Jira-issues. Deze gegevens bevatten statusovergangen en belangrijke wijzigingen in velden.
Voorbeelden
Incident toegewezenOnderzoek gestartIncident opgelost
|
|||
|
Incident-ID
IncidentId
|
De unieke identificatiecode van elk incidentticket in Jira Service Management. | ||
|
Beschrijving
De incident-ID, in Jira vaak de issue key genoemd, is de unieke identificatiecode van elk gemeld incident. Deze ID koppelt alle bijbehorende activiteiten, reacties en statuswijzigingen vanaf het aanmaken tot en met de definitieve afsluiting. Bij process mining is deze ID nodig om de volledige levenscyclus van elk incident te reconstrueren en het hele proces te analyseren.
Waarom dit belangrijk is
Deze ID koppelt alle bijbehorende gebeurtenissen aan één case en vormt daarmee de basis voor elke process mining-analyse.
Waar vind je dit?
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 bevat de timestamp van elke activiteit in de levenscyclus van een incident. Je gebruikt deze om de duur, doorlooptijden en wachttijden tussen processtappen te berekenen. Met nauwkeurige timestamps kun je prestaties analyseren, SLA’s bewaken en bottlenecks opsporen. Alle prestatiemetrieken, zoals de oplostijd en de diagnoseduur, worden op basis van deze timestamps berekend.
Waarom dit belangrijk is
Timestamps zijn nodig om tijdsgebonden metrieken te berekenen, de procesduur te bepalen en bottlenecks in de prestaties te vinden.
Waar vind je dit?
Dit is de datum waarop elke vermelding in het wijzigingslogboek of de geschiedenis van een 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 gehaald. | ||
|
Beschrijving
Dit attribuut geeft aan waar de data vandaan komt, in dit geval Jira Service Management. Dat is vooral handig wanneer data uit meerdere systemen wordt gecombineerd om het proces in samenhang te bekijken. Met het bronsysteem blijft de herkomst van de data duidelijk en kun je problemen met de datakwaliteit of data-extractie opsporen. In dit model heeft de waarde een vaste waarde.
Waarom dit belangrijk is
Geeft context over de herkomst van de data en maakt die duidelijk en traceerbaar, vooral bij analyses van meerdere systemen.
Waar vind je dit?
Dit is een vaste waarde die je tijdens de data-extractie toevoegt.
Voorbeelden
Jira Service ManagementJira Cloud
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor het laatst uit het bronsysteem is vernieuwd. | ||
|
Beschrijving
Dit attribuut registreert wanneer de dataset voor het laatst is bijgewerkt. Zo weet iedereen die het proces analyseert hoe actueel de data is. Dat is vooral belangrijk voor dashboards die processen doorlopend bewaken en actuele informatie nodig hebben om op tijd beslissingen te nemen. Binnen één data-extractie heeft deze waarde doorgaans voor alle gebeurtenissen dezelfde waarde.
Waarom dit belangrijk is
Laat zien hoe actueel de data is. Dat is belangrijk voor de relevantie en nauwkeurigheid van de analyse.
Waar vind je dit?
Dit is de timestamp van de data-extractie. Je voegt deze toe tijdens de datatransformatie.
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 starttimestamp voor de berekening van totale metrieken, zoals de totale oplostijd. De aanmaakdatum is voor elk incident een vaste waarde en vormt het beginpunt van de volledige case in de process mining-analyse.
Waarom dit belangrijk is
Vormt het startpunt voor alle berekeningen van de end-to-end-doorlooptijd en voor SLA-metingen.
Waar vind je dit?
Het standaardveld ‘Created’ van een Jira-issue.
Voorbeelden
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Behandelaar
Assignee
|
De gebruiker die op dit moment aan het incident werkt. | ||
|
Beschrijving
De behandelaar is de medewerker of gebruiker die op een bepaald moment verantwoordelijk is voor het incident. Door wijzigingen in de behandelaar bij te houden, kun je overdrachten analyseren, de verdeling van het werk bekijken en zien wie bij specifieke processtappen betrokken is. Dit attribuut helpt bij vragen over individuele prestaties en de verdeling van capaciteit binnen supportteams.
Waarom dit belangrijk is
Helpt de werkbelasting per medewerker te volgen, bottlenecks bij specifieke medewerkers te vinden en te analyseren hoe overdrachten de oplostijd beïnvloeden.
Waar vind je dit?
Het standaardveld ‘Assignee’ van een Jira-issue.
Voorbeelden
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Oplossingsdatum
ResolutionDate
|
De datum en tijd waarop het incident als opgelost is gemarkeerd. | ||
|
Beschrijving
Dit attribuut bevat de timestamp waarop het incident voor het eerst de status ‘Opgelost’ kreeg. Daarmee eindigt de actieve werkfase en wordt het eindpunt bepaald voor de berekening van de oplostijd. Door de oplossingsdatum met de aanmaakdatum te vergelijken, krijg je de belangrijkste maatstaf voor procesefficiëntie. De datum speelt ook een belangrijke rol bij het bepalen van de naleving van SLA’s.
Waarom dit belangrijk is
Markeert het einde van het oplossingsproces en maakt het mogelijk de totale doorlooptijd en SLA-prestaties te berekenen.
Waar vind je dit?
Het standaardveld ‘Resolved’ van een Jira-issue.
Voorbeelden
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Prioriteit
Priority
|
De prioriteit van het incident, die aangeeft hoe snel het moet worden opgelost. | ||
|
Beschrijving
De prioriteit bepaalt hoe snel een incident moet worden opgepakt. Vaak wordt deze bepaald op basis van de impact en urgentie en heeft ze rechtstreeks invloed op de SLA-doelen. Door incidenten op prioriteit te vergelijken, zie je of incidenten met hoge prioriteit sneller worden afgehandeld dan incidenten met 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
Belangrijk voor het analyseren van SLA-prestaties en om te controleren of capaciteit naar de incidenten met de grootste impact gaat.
Waar vind je dit?
Het standaardveld ‘Priority’ van een Jira-issue.
Voorbeelden
HoogsteHoogGemiddeldLaag
|
|||
|
Status
Status
|
De huidige fase van het incident in de levenscyclus. | ||
|
Beschrijving
Het veld Status geeft de huidige status van een incident in de vastgelegde workflow aan, bijvoorbeeld ‘Open’, ‘In behandeling’, ‘Wacht op klant’ of ‘Opgelost’. Statuswijzigingen vormen de belangrijkste bron voor het activiteitenlogboek dat bij process mining wordt gebruikt. Door te analyseren hoelang incidenten in elke status blijven, kun je bottlenecks vinden en zien waar de meeste tijd naartoe gaat.
Waarom dit belangrijk is
Geeft rechtstreeks de voortgang van het incident weer en is de belangrijkste bron voor het bepalen van processtappen en wachttijden.
Waar vind je dit?
Het standaardveld ‘Status’ van een Jira-issue.
Voorbeelden
In behandelingWacht op klantOpgelostGesloten
|
|||
|
Toewijzingsgroep
AssignmentGroup
|
Het team of de groep die verantwoordelijk is voor de afhandeling van het incident. | ||
|
Beschrijving
De toewijzingsgroep is het team dat aan het incident is toegewezen. Dit kan een supportniveau zijn, zoals ‘L1 Helpdesk’, een gespecialiseerd team zoals ‘Netwerkbeheer’ of een ontwikkelteam. Door overgangen tussen toewijzingsgroepen te analyseren, krijg je zicht op escalaties en overdrachten. Je kunt er ook de teamprestaties mee meten, bottlenecks binnen teams opsporen en afhankelijkheden tussen teams analyseren.
Waarom dit belangrijk is
Belangrijk voor het analyseren van teamprestaties, doorvoer en de werkverdeling tussen supportniveaus en gespecialiseerde groepen.
Waar vind je dit?
Dit wordt in Jira vaak ingericht als een aangepast veld, bijvoorbeeld ‘Team’ of ‘Assignment Group’. Soms kun je de waarde afleiden uit Jira Components of Project Roles.
Voorbeelden
Supportniveau 1InfrastructuurteamDatabasebeheerders
|
|||
|
Aantal overdrachten
HandoffCount
|
Het aantal keer dat het incident aan een andere groep of gebruiker is toegewezen. | ||
|
Beschrijving
Deze berekende metriek telt hoe vaak het veld ‘Assignee’ of ‘AssignmentGroup’ tijdens de levenscyclus van het incident is gewijzigd. Veel overdrachten wijzen vaak op een inefficiënt proces, een lage first-call resolution of kennishiaten. Daardoor kan de oplostijd oplopen. Met deze KPI kun je het toewijzingsproces verbeteren en de samenwerking tussen teams versterken.
Waarom dit belangrijk is
Maakt de vertraging en inefficiëntie door herhaalde toewijzingen meetbaar, zodat je kansen voor procesverbetering kunt vinden.
Waar vind je dit?
Berekend door het aantal wijzigingen aan het veld 'Assignee' of 'AssignmentGroup' in de wijzigingsgeschiedenis van het issue te tellen.
Voorbeelden
015
|
|||
|
Categorie van de grondoorzaak
RootCauseCategory
|
De classificatie van de onderliggende oorzaak van het incident. | ||
|
Beschrijving
Dit attribuut legt de belangrijkste reden voor het incident vast, zoals ‘Softwarefout’, ‘Hardwarestoring’ of ‘Gebruikersfout’. Meestal wordt het ingevuld na onderzoek. Het is belangrijk voor probleembeheer en het voorkomen van nieuwe incidenten. Door categorieën van grondoorzaken te analyseren, kun je structurele zwakke plekken vinden en verbeteringen prioriteren. Veel grondoorzaken met de waarde ‘Onbekend’ kunnen erop wijzen dat het onderzoek beter moet.
Waarom dit belangrijk is
Maakt oorzaakanalyse mogelijk. Zo kun je van een reactieve naar een proactieve aanpak gaan door de oorzaken van incidenten te vinden en aan te pakken.
Waar vind je dit?
Dit is vrijwel altijd een aangepast veld in Jira. De naam en opties hangen sterk af van de configuratie van de organisatie.
Voorbeelden
ConfiguratiefoutNetwerkstoringSoftwarefout
|
|||
|
Component
Component
|
Het systeem, de applicatie of het infrastructuuronderdeel waarop het incident betrekking heeft. | ||
|
Beschrijving
Components zijn onderdelen van een Jira-project waarmee je issues in kleinere groepen indeelt, zoals ‘Gebruikersinterface’, ‘Database’ of ‘API’. Door incidenten per component te analyseren, zie je welke onderdelen van een systeem het vaakst problemen geven. Deze informatie helpt bij oorzaakanalyses en kan richting geven aan verbeteringen van de dienstverlening of het terugdringen van technische schuld.
Waarom dit belangrijk is
Maakt het mogelijk te filteren en analyseren op het product of systeemonderdeel waarop het incident betrekking heeft, zodat je probleemgebieden in de technologie kunt vinden.
Waar vind je dit?
Het standaardveld ‘Components’ van een Jira-issue.
Voorbeelden
AuthenticatiedienstRapportagedashboardMobiele app
|
|||
|
Doel voor oplostijd
TimeToResolutionTarget
|
De SLA-doelduur voor het oplossen van het incident. | ||
|
Beschrijving
Dit attribuut bepaalt binnen welke maximale tijd een incident van een bepaalde prioriteit of een bepaald type naar verwachting wordt opgelost. De werkelijke oplostijd wordt hiermee vergeleken om te bepalen of aan de SLA is voldaan. De waarde wordt meestal dynamisch bepaald aan de hand van regels voor bijvoorbeeld prioriteit, ernst of issuetype. Dit attribuut vormt de basis voor een dashboard dat SLA-prestaties bewaakt.
Waarom dit belangrijk is
Vormt de norm voor het meten van SLA-naleving en de basis voor de KPI voor het percentage incidenten waarbij de SLA is overschreden.
Waar vind je dit?
Afgeleid uit de SLA-configuratie in Jira Service Management. Je moet het specifieke doel bepalen, bijvoorbeeld ‘Time to resolution’.
Voorbeelden
4 uur8 uur3 dagen
|
|||
|
Ernst
Severity
|
De mate waarin het incident gevolgen heeft voor de bedrijfsvoering. | ||
|
Beschrijving
De ernst geeft aan hoeveel impact een incident heeft op de bedrijfsvoering, van gevolgen voor één gebruiker tot een storing in een kritiek systeem. De prioriteit bepaalt de volgorde van het werk; de ernst geeft de totale impact op de organisatie aan. Met een analyse op ernst zie je hoe het proces verloopt voor incidenten die voor de organisatie het zwaarst wegen. Vaak combineer je ernst en prioriteit voor een genuanceerder beeld.
Waarom dit belangrijk is
Geeft zicht op de impact op de bedrijfsvoering, zodat je de incidenten met de grootste gevolgen kunt analyseren.
Waar vind je dit?
Meestal is dit een aangepast veld in Jira, omdat het geen standaard systeemveld is. Raadpleeg de projectinstellingen van Jira Service Management.
Voorbeelden
KritiekErnstigLichtVerwaarloosbaar
|
|||
|
Gekoppelde probleem-ID
LinkedProblemId
|
De identificatiecode van een probleemticket dat aan dit incident is gekoppeld. | ||
|
Beschrijving
Incidenten die voortkomen uit een groter onderliggend probleem, worden vaak gekoppeld aan een probleemticket. Dit veld bevat de ID van dat probleem. Door deze koppelingen te analyseren, zie je hoe incidenten en problemen met elkaar samenhangen. Je kunt ook de effectiviteit van probleembeheer meten en terugkerende incidenten vinden waarvoor een permanente oplossing nodig is.
Waarom dit belangrijk is
Koppelt incidenten aan onderliggende problemen. Zo kun je analyseren hoe goed de organisatie grondoorzaken aanpakt om nieuwe incidenten te voorkomen.
Waar vind je dit?
Deze informatie staat in het gedeelte ‘Issue Links’ van een Jira-issue.
Voorbeelden
PROB-123PROB-456Geen
|
|||
|
Is herhaalwerk
IsRework
|
Een kenmerk dat aangeeft of het incident opnieuw werk vereiste, bijvoorbeeld doordat het is heropend. | ||
|
Beschrijving
Dit berekende booleaanse attribuut geeft aan welke incidenten zijn teruggezet naar een eerdere processtap. Meestal gebeurt dat doordat een incident na de oplossing opnieuw wordt geopend. Herhaalwerk is een belangrijke bron van inefficiëntie en ontevreden klanten. Met dit kenmerk kun je het percentage herhaalwerk eenvoudig berekenen en onderzoeken waarom incidenten niet in één keer goed worden opgelost.
Waarom dit belangrijk is
Maakt problemen met de proceskwaliteit en inefficiëntie zichtbaar door incidenten te markeren waarvoor herhaald werk nodig is. Zo ondersteunt het de analyse van herhaalwerk.
Waar vind je dit?
Berekend door specifieke reeksen statuswijzigingen in het event log te herkennen, zoals 'Resolved' -> 'Reopened'.
Voorbeelden
truefalse
|
|||
|
Issuetype
IssueType
|
Het soort issue, zoals incident, serviceaanvraag of probleem. | ||
|
Beschrijving
Jira gebruikt issuetypes om verschillende soorten werk van elkaar te onderscheiden. Bij incidentbeheer is ‘Incident’ het belangrijkste type, maar ook andere types, zoals ‘Sub-task’, kunnen relevant zijn. Met dit attribuut kun je de dataset filteren op incidenten, zodat de process mining-analyse zich op het juiste proces richt.
Waarom dit belangrijk is
Zorgt ervoor dat de analyse alleen over incidenten gaat en niet over andere soorten werk, zoals serviceaanvragen of wijzigingen.
Waar vind je dit?
Het standaardveld ‘Issue Type’ van een Jira-issue.
Voorbeelden
IncidentIT-hulpBug
|
|||
|
Melder
Reporter
|
De gebruiker die het incident heeft aangemaakt of als eerste heeft 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 vinden die vaak problemen ervaren. Je kunt ook communicatiepatronen onderzoeken, bijvoorbeeld bij activiteiten als ‘Wacht op klant’ en ‘Klant heeft gereageerd’.
Waarom dit belangrijk is
Helpt de herkomst van incidenten te analyseren, patronen bij specifieke gebruikers of afdelingen te vinden en vertragingen in klantcontact te begrijpen.
Waar vind je dit?
Het standaardveld ‘Reporter’ van een Jira-issue.
Voorbeelden
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Oplossing
Resolution
|
De uiteindelijke uitkomst of reden waarom het incident is opgelost. | ||
|
Beschrijving
Het veld Resolution geeft aan waarom een incident de status ‘Opgelost’ heeft gekregen. Veelvoorkomende waarden zijn ‘Opgelost’, ‘Duplicaat’, ‘Wordt niet opgepakt’ en ‘Niet te reproduceren’. Door de verdeling van oplossingssoorten te analyseren, krijg je zicht op de kwaliteit van meldingen en de effectiviteit van het oplossingsproces. Een groot aantal meldingen met de oplossing ‘Duplicaat’ kan bijvoorbeeld wijzen op een probleem bij het aanmaken of beoordelen van incidenten.
Waarom dit belangrijk is
Geeft context bij de uitkomst van een incident. Zo kun je oplossingen categoriseren en trends ontdekken in de manier waarop incidenten worden afgesloten.
Waar vind je dit?
Het standaardveld ‘Resolution’ van een Jira-issue. Dit veld wordt doorgaans ingevuld wanneer een issue overgaat naar de statuscategorie ‘Done’.
Voorbeelden
AfgerondOpgelostDuplicaatWordt niet opgelost
|
|||
|
SLA overschreden
SlaBreach
|
Een aanduiding die aangeeft of de oplostijd van het incident langer was dan de SLA-doelduur. | ||
|
Beschrijving
Dit berekende booleaanse attribuut geeft aan of de SLA voor ‘Time to Resolution’ van een incident is overschreden. De waarde is waar als ‘IncidentResolutionCycleTime’ groter is dan ‘TimeToResolutionTarget’. Met deze aanduiding kun je eenvoudig filteren en totalen berekenen, bijvoorbeeld voor de KPI voor het percentage overschreden SLA’s. Het is de belangrijkste uitkomstmaat voor het dashboard dat SLA-prestaties bewaakt.
Waarom dit belangrijk is
Geeft een duidelijke uitkomst voor de SLA-prestaties, zodat je eenvoudig overschrijdingspercentages berekent en probleemgebieden vindt.
Waar vind je dit?
Berekend als (‘IncidentResolutionCycleTime’ > ‘TimeToResolutionTarget’).
Voorbeelden
truefalse
|
|||
|
Type klantaanvraag
CustomerRequestType
|
Het specifieke type aanvraag dat de klant via het serviceportaal heeft ingediend. | ||
|
Beschrijving
Dit veld deelt aanvragen in vanuit het perspectief van de klant, zoals weergegeven in het Jira Service Management-portaal (bijvoorbeeld ‘Een systeemprobleem melden’). Het biedt een gebruiksvriendelijke indeling van het incident, die kan afwijken van het interne ‘Issue Type’. Door dit attribuut te analyseren, zie je hoe klanten problemen ervaren en melden. Die informatie kan helpen het portaal en de dienstverlening te verbeteren.
Waarom dit belangrijk is
Geeft een beeld van incidentcategorieën vanuit het perspectief van de klant. Dat is nuttig om de vraag te analyseren en de klantervaring te verbeteren.
Waar vind je dit?
Het veld ‘Customer Request Type’, dat specifiek is voor Jira Service Management-projecten.
Voorbeelden
IT-hulp krijgen > Een systeemprobleem meldenE-mail > Toegangsaanvraag
|
|||
Activiteiten voor incidentbeheer
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Incident aangemaakt
|
Dit markeert het officiële begin van de levenscyclus van een incident: een incidentmelding wordt ingediend en in Jira wordt een nieuw probleem aangemaakt. Dit event wordt expliciet vastgelegd wanneer in het systeem een nieuw probleem van het type 'Incident' wordt geregistreerd. | ||
|
Waarom dit belangrijk is
Dit is het belangrijkste startevent van het proces. De tijd tussen deze activiteit en de oplossing laat zien wat de totale doorlooptijd is en in hoeverre SLA-afspraken worden nagekomen.
Waar vind je dit?
Dit is een expliciet event, vastgelegd met de timestamp 'created' van het incident in Jira. De aanmaak van het probleem wordt geregistreerd in de geschiedenis ervan.
Vastleggen
Gebruik de timestamp waarop het probleem is aangemaakt.
Gebeurtenistype
explicit
|
|||
|
Incident gesloten
|
Dit staat voor de definitieve administratieve afsluiting van het incident nadat het is opgelost en gecontroleerd. Dit wordt afgeleid van de statuswijziging naar 'Closed'. | ||
|
Waarom dit belangrijk is
Dit is het laatste event in het proces. De tijd tussen 'Resolved' en 'Closed' kan vertragingen in de administratieve afhandeling of het wachten op bevestiging van de gebruiker zichtbaar maken.
Waar vind je dit?
Afgeleid uit de geschiedenis van statuswijzigingen van het issue. De gebeurtenis hoort bij de timestamp waarop de status overgaat naar de definitieve status ‘Gesloten’.
Vastleggen
Bepaal de timestamp van de statusovergang naar ‘Gesloten’.
Gebeurtenistype
inferred
|
|||
|
Incident opgelost
|
Deze activiteit bevestigt dat het incident is opgelost en de dienstverlening is hersteld. Vaak valt dit samen met de statuswijziging naar 'Resolved'. | ||
|
Waarom dit belangrijk is
Dit is de belangrijkste mijlpaal voor een geslaagde afhandeling. De tijd tot dit moment is de meest gebruikte KPI: de oplostijd (TTR).
Waar vind je dit?
Dit wordt afgeleid van de statuswijziging naar 'Resolved'. In veel workflows is dit hetzelfde event als 'Resolution Proposed' en vormt het de belangrijkste mijlpaal voor de oplossing.
Vastleggen
Bepaal de timestamp van de statuswijziging naar 'Resolved'.
Gebeurtenistype
inferred
|
|||
|
Incident opnieuw toegewezen
|
Dit gebeurt wanneer een incident na de eerste toewijzing wordt overgedragen aan een andere medewerker of groep. Dit event wordt afgeleid van elke wijziging in het veld 'Assignee' of 'Assigned Group'. | ||
|
Waarom dit belangrijk is
Het bijhouden van nieuwe toewijzingen is belangrijk om overdrachten te analyseren. Veel nieuwe toewijzingen wijzen vaak op inefficiënte processen, ontbrekende kennis of een verkeerde eerste routering. Daardoor kan de oplostijd oplopen.
Waar vind je dit?
Dit wordt afgeleid uit de probleemgeschiedenis door wijzigingen in het veld 'Assignee' te vinden nadat het voor het eerst is ingevuld. Elke wijziging geldt als een event voor een nieuwe toewijzing.
Vastleggen
Zoek naar wijzigingen in het veld 'Assignee' na de eerste toewijzing.
Gebeurtenistype
inferred
|
|||
|
Onderzoek gestart
|
Dit geeft aan dat een toegewezen medewerker actief is begonnen met het onderzoeken van het incident. Meestal wordt dit afgeleid wanneer de status van het incident verandert van 'Open' of 'New' naar 'In Progress'. | ||
|
Waarom dit belangrijk is
Deze belangrijke mijlpaal markeert het begin van het actieve werk aan de oplossing. Door de tijd tot deze activiteit te meten, zie je vertragingen in de wachtrij en problemen met de beschikbaarheid van medewerkers.
Waar vind je dit?
Dit wordt afgeleid uit de statusgeschiedenis van het probleem. De timestamp van het event is het moment waarop de status verandert naar een status die actief werk aangeeft, zoals 'In Progress'.
Vastleggen
Bepaal de timestamp van de statuswijziging naar 'In Progress'.
Gebeurtenistype
inferred
|
|||
|
Oplossing voorgesteld
|
Deze activiteit geeft aan dat een oplossing is gevonden en toegepast en dat het incident wacht op bevestiging of de laatste controle. Dit wordt afgeleid van de statuswijziging naar 'Resolved'. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal: het actieve werk van het supportteam is afgerond. Vaak stopt op dit moment ook de SLA-klok.
Waar vind je dit?
Dit wordt afgeleid uit de statusgeschiedenis van het probleem. De timestamp van het event is het moment waarop de status verandert naar 'Resolved' of een gelijkwaardige status.
Vastleggen
Bepaal de timestamp van de statuswijziging naar 'Resolved'.
Gebeurtenistype
inferred
|
|||
|
Wacht op klant
|
Dit markeert het moment waarop het supportteam wacht op informatie of actie van de klant. Dit wordt afgeleid van een statuswijziging naar een aparte wachtstatus, zoals 'Waiting for customer'. | ||
|
Waarom dit belangrijk is
Door deze wachttijd apart te meten, kun je de SLA nauwkeurig berekenen. Deze tijd telt vaak niet mee in de oplostijd. Ook wordt zo duidelijk hoe lang het duurt voordat klanten reageren.
Waar vind je dit?
Dit wordt afgeleid uit de statusgeschiedenis van het probleem. Het event hoort bij de timestamp waarop de status verandert naar 'Waiting for customer' of een vergelijkbare status.
Vastleggen
Bepaal de timestamp van de statuswijziging naar 'Waiting for customer'.
Gebeurtenistype
inferred
|
|||
|
Geëscaleerd naar specialistisch team
|
Dit geeft aan dat het incident voor specialistische ondersteuning is geëscaleerd naar een gespecialiseerd team, bijvoorbeeld niveau 2 of ontwikkeling. Dit wordt afgeleid van een wijziging in een aangepast veld 'Support Team' of van een specifieke nieuwe toewijzing. | ||
|
Waarom dit belangrijk is
Hiermee zie je welke incidenten specialistische kennis vereisen en hoe ze tussen verschillende ondersteuningsniveaus worden overgedragen. Dat helpt bottlenecks binnen specialistische teams en patronen in escalaties te herkennen.
Waar vind je dit?
Dit wordt afgeleid uit de probleemgeschiedenis door wijzigingen bij te houden in een aangepast veld voor het toegewezen team, of door een wijziging van 'Assignee' naar een lid van een bekende specialistische groep te herkennen.
Vastleggen
Zoek naar een wijziging in een aangepast veld voor 'Assigned Team' of naar specifieke wijzigingen van de toegewezen medewerker.
Gebeurtenistype
inferred
|
|||
|
Gekoppeld aan probleemmelding
|
Dit gebeurt wanneer een incident wordt gekoppeld aan een probleemmelding voor oorzaakanalyse. Dit expliciete event wordt vastgelegd wanneer een link 'relates to' of 'caused by' wordt aangemaakt naar een probleem van het type 'Problem'. | ||
|
Waarom dit belangrijk is
Door deze koppeling te volgen, zie je hoe goed de organisatie van het beperken van de impact van een incident overgaat naar oorzaakanalyse en preventie.
Waar vind je dit?
Dit is een expliciet event in de koppelingsgeschiedenis van het probleem. Elke aangemaakte koppeling heeft een timestamp en kan worden gefilterd op koppelingen naar problemen van het type 'Problem'.
Vastleggen
Gebruik de timestamp waarop een koppeling naar een probleem van het type 'Problem' is aangemaakt.
Gebeurtenistype
explicit
|
|||
|
Incident geprioriteerd
|
Dit geeft aan dat de prioriteit en/of ernst van het incident is ingesteld. Die bepaalt de urgentie en 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 de prioritering te volgen, kun je nagaan of incidenten snel en consequent worden beoordeeld. Vertraging bij deze stap kan de SLA-berekening en de verdeling van middelen direct beïnvloeden.
Waar vind je dit?
Dit wordt afgeleid uit de geschiedenis van het probleem, waarin wijzigingen in alle velden worden bijgehouden. Zoek na het aanmaken van het probleem naar de eerste wijziging van 'Priority' of een aangepast veld voor 'Severity'.
Vastleggen
Zoek in de probleemgeschiedenis naar de eerste wijziging van het veld 'Priority'.
Gebeurtenistype
inferred
|
|||
|
Incident heropend
|
Dit betekent dat een eerder opgelost incident opnieuw actief wordt omdat het probleem terugkeert of de oplossing niet werkt. Dit wordt afgeleid van een statuswijziging van 'Resolved' of 'Closed' terug naar een open status. | ||
|
Waarom dit belangrijk is
Heropende incidenten geven rechtstreeks aan hoe goed oplossingen werken en zijn een belangrijke aanwijzing voor herstelwerk. Door deze events te analyseren, kun je voortijdige sluitingen en ineffectieve oplossingen herkennen.
Waar vind je dit?
Dit wordt afgeleid uit de statusgeschiedenis van het probleem. Het event wordt vastgelegd wanneer de status verandert van een eindstatus, zoals 'Resolved' of 'Closed', terug naar 'Open' of 'In Progress'.
Vastleggen
Zoek naar een statuswijziging van 'Resolved' of 'Closed' naar een open status.
Gebeurtenistype
inferred
|
|||
|
Incident toegewezen
|
Deze activiteit geeft aan dat het incident voor het eerst aan een supportmedewerker of groep is toegewezen. Dit wordt vastgelegd door bij te houden wanneer het veld 'Assignee' of 'Assigned Group' voor het eerst wordt ingevuld. | ||
|
Waarom dit belangrijk is
Dit meet de tijd tot de eerste reactie en toewijzing, een belangrijk onderdeel van SLA-cijfers. Zo worden vertragingen zichtbaar voordat het actieve onderzoek begint.
Waar vind je dit?
Dit wordt afgeleid uit de probleemgeschiedenis door de eerste wijziging van het veld 'Assignee' te vinden waarbij de vorige waarde 'Unassigned' was.
Vastleggen
Zoek in de probleemgeschiedenis naar de eerste wijziging van het veld 'Assignee'.
Gebeurtenistype
inferred
|
|||
|
Klant heeft gereageerd
|
Dit geeft aan dat de klant de gevraagde informatie heeft verstrekt en dat het incident verder kan worden afgehandeld. Dit wordt afgeleid wanneer de status verandert van 'Waiting for customer' naar een actieve status. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert het einde van een vertraging die door de klant is veroorzaakt. De tijd tussen 'Waiting For Customer' en dit event laat de gemiddelde reactietijd van klanten zien.
Waar vind je dit?
Dit wordt afgeleid uit de statusgeschiedenis van het probleem. Het event vindt plaats wanneer de status verandert van 'Waiting for customer' naar bijvoorbeeld 'In Progress'. Vaak gebeurt dit nadat de klant een opmerking heeft toegevoegd.
Vastleggen
Zoek naar een statuswijziging van 'Waiting for customer' naar 'In Progress'.
Gebeurtenistype
inferred
|
|||
|
Opmerking toegevoegd
|
Dit staat voor een communicatie- of notitieactiviteit waarbij een gebruiker een opmerking aan het incident toevoegt. Dit expliciete event wordt vastgelegd telkens wanneer iemand een opmerking plaatst. | ||
|
Waarom dit belangrijk is
De frequentie van opmerkingen kan inzicht geven in communicatiepatronen, de efficiëntie van de samenwerking en de complexiteit van een incident. Zo kun je incidenten herkennen waarbij veel communicatie nodig is.
Waar vind je dit?
Dit is een expliciet event. Jira slaat elke opmerking op met een timestamp en de naam van de auteur. Je vindt deze gegevens in de opmerkingengeschiedenis van het probleem of via de API.
Vastleggen
Gebruik de timestamp van elke opmerking die aan het probleem is toegevoegd.
Gebeurtenistype
explicit
|
|||
|
Workaround geboden
|
Dit staat voor het invoeren van een tijdelijke oplossing om de dienstverlening te herstellen terwijl aan een permanente oplossing wordt gewerkt. Dit kan worden afgeleid van een statuswijziging of een specifieke opmerking. | ||
|
Waarom dit belangrijk is
De tijd tot een workaround beschikbaar is, geeft aan hoe snel de dienstverlening wordt hersteld. Zo kun je tijdelijke maatregelen onderscheiden van een permanente oplossing.
Waar vind je dit?
Dit wordt vaak afgeleid. Het kan gaan om een statuswijziging naar 'Workaround Provided' of om een openbare opmerking met specifieke trefwoorden, zoals 'workaround'.
Vastleggen
Zoek naar een specifieke statuswijziging of een trefwoord in een opmerking.
Gebeurtenistype
inferred
|
|||
Extractiegidsen
Klaar om te beginnen?
Gebruik deze datatemplate om incidentbeheer te verbeteren, inefficiëntie op te sporen en incidenten sneller op te lossen. Begin vandaag met het verbeteren van het proces.
Verbeter incidentbeheer en los incidenten sneller op
Verlaag de MTTR met 35% en verhoog de tevredenheid van gebruikers met efficiëntere processen.
Geen creditcard nodig • In 5 minuten ingesteld