Datatemplate voor beheer van serviceaanvragen

Het attribuut Activiteit beschrijft een specifieke stap of actie voor een serviceaanvraag. Activiteiten vormen samen de opeenvolgende bouwstenen van het proces, zoals ‘Aanvraag aangemaakt’, ‘Aanvraag toegewezen’, ‘Werk in uitvoering’ en ‘Aanvraag gesloten’. Elke activiteit markeert een afzonderlijk moment in het verloop van een serviceaanvraag.

Activiteiten analyseren is de kern van process mining. Zo ontdek en visualiseer je de werkelijke processtroom. Door de volgorde en frequentie van activiteiten te bekijken, kunnen analisten veelvoorkomende routes en afwijkingen van het standaardproces opsporen. Ook wordt zichtbaar waar aanvragen vastlopen en waar stappen onnodig worden herhaald.

Dit attribuut legt de processtappen vast en maakt het mogelijk de werkelijke processtroom, bottlenecks en afwijkingen te ontdekken.

Vaak afgeleid uit statuswijzigingslogs, eventtabellen of auditsporen die bij het serviceaanvraagobject horen.

De ID van de serviceaanvraag is de primaire sleutel waarmee elke serviceaanvraag gedurende de hele levenscyclus uniek wordt geïdentificeerd. Deze ID fungeert als case-ID en koppelt alle bijbehorende activiteiten, statuswijzigingen en attributen aan één samenhangende procesinstantie.

Bij process mining is deze ID essentieel om het volledige verloop van elke aanvraag te reconstrueren. Door alle gebeurtenissen onder één CaseId te groeperen, kunnen analisten processtromen visualiseren, de doorlooptijd per case berekenen en verschillen in de afhandeling van aanvragen opsporen. De ID vormt de basis voor elke analyse van het beheer van serviceaanvragen.

Deze ID is nodig om alle gebeurtenissen van een serviceaanvraag aan elkaar te koppelen en het volledige proces van begin tot eind te bekijken.

Meestal te vinden in de koptekst of de hoofdtabel met transacties voor serviceaanvragen.

De starttijd legt de exacte datum en tijd vast waarop een activiteit begon. Deze timestamp is nodig om gebeurtenissen chronologisch te ordenen en de duur van activiteiten en de totale levenscyclus van een case te berekenen. Elke activiteit in het proces hoort een bijbehorende starttijd te hebben, zodat je een nauwkeurig event log kunt opbouwen.

Bij procesanalyse gebruik je de starttijd om belangrijke prestatie-indicatoren te berekenen, zoals doorlooptijd, wachttijd tussen activiteiten en verwerkingstijd per activiteit. Zo kun je het proces op basis van tijd bekijken, vertragingen herkennen en zien welke stappen de meeste tijd kosten. Nauwkeurige timestamps zijn nodig voor elke analyse van prestaties.

Deze timestamp is nodig om gebeurtenissen in de juiste volgorde te zetten en tijdsgebonden metrieken te berekenen, zoals doorlooptijden en bottlenecks.

Te vinden in het event log of in tabellen met auditsporen. Vaak vastgelegd als ‘aanmaakdatum’ of ‘eventtimestamp’ bij elke activiteitsregistratie.

Het attribuut Bronsysteem bevat de naam van het IT Service Management-platform (ITSM) of een andere applicatie waaruit de data zijn gehaald. In omgevingen met meerdere systemen maakt dit veld duidelijk uit welke bron de data komen en waar ze vandaan zijn gehaald.

Dit attribuut wordt meestal niet rechtstreeks gebruikt voor analyses van processtromen, maar is wel belangrijk voor datagovernance, validatie en probleemoplossing. Als je data uit meerdere bronnen combineert, kun je met dit attribuut de procesweergave per systeem uitsplitsen. Zo worden verschillen in procesuitvoering of datakwaliteit tussen platforms zichtbaar.

Belangrijk voor datagovernance en probleemoplossing: het maakt duidelijk waar de data vandaan komen, vooral in omgevingen met meerdere gekoppelde systemen.

Deze waarde wordt meestal toegevoegd tijdens de data-extractie (ETL) en is geen standaardveld in het bronsysteem zelf.

Laatste data-update geeft de timestamp van de meest recente data-extractie of -verversing. Zo zie je hoe actueel de data zijn en of de analyse de huidige situatie weergeeft of een momentopname uit het verleden.

Dit attribuut geeft context aan operationele monitoring en rapportages, omdat je ermee kunt beoordelen hoe actueel de inzichten zijn. Zo kun je de data beter op waarde schatten en beslissingen nemen op basis van de actualiteit ervan. Een dashboard met data van een week geleden lees je bijvoorbeeld anders dan een dashboard dat een uur geleden is bijgewerkt.

Geeft aan hoe actueel de data zijn. Dat is belangrijk om te beoordelen of analyses relevant zijn en op recente informatie zijn gebaseerd.

Dit metadataveld wordt meestal aangemaakt en opgeslagen tijdens de data-extractie (ETL).

De aanvraagstatus geeft aan wat de status van de serviceaanvraag op een bepaald moment in de levenscyclus is. Veelvoorkomende statussen zijn Nieuw, In behandeling, In afwachting, Opgelost en Gesloten. Dit attribuut laat zien waar de aanvraag zich in het proces bevindt.

Door de aanvraagstatus te analyseren, krijg je inzicht in de processtroom en statusovergangen. Je kunt cases filteren, aanvragen opsporen die in een bepaalde status vastzitten en meten hoelang ze in elke status blijven. Als je bijvoorbeeld bekijkt hoelang aanvragen de status ‘In afwachting’ hebben, kunnen vertragingen aan het licht komen die ontstaan doordat informatie van gebruikers of externe teams ontbreekt.

Hiermee kun je meten hoelang aanvragen in elke status blijven en bottlenecks of vertragingen in het proces opsporen.

Beschikbaar in de hoofdtabel met serviceaanvragen of in statusgeschiedenislogs.

De prioriteit van een aanvraag helpt supportteams bepalen in welke volgorde ze aanvragen behandelen. De prioriteit is meestal gebaseerd op de combinatie van de impact op de bedrijfsvoering en de urgentie. Veelvoorkomende prioriteiten zijn Laag, Gemiddeld, Hoog en Kritiek.

Dit attribuut is belangrijk voor prestatieanalyses en de verdeling van middelen. Analisten kunnen doorlooptijden en SLA-compliance per prioriteitsniveau vergelijken om te controleren of aanvragen met hoge prioriteit passend worden afgehandeld. Ook wordt zichtbaar of aanvragen met lage prioriteit blijven liggen en of supportteams de prioriteiten goed toepassen.

Nodig om te analyseren of aanvragen worden afgehandeld op basis van hun belang voor de bedrijfsvoering en om te zien hoe prioriteit de oplostijd beïnvloedt.

Meestal een standaardveld in de hoofdregistratie van de serviceaanvraag.

Servicetype geeft aan wat voor soort serviceaanvraag het is. Het kan gaan om een aanvraag voor nieuwe hardware of softwaretoegang, een algemene vraag of technische ondersteuning. Met deze indeling kan de aanvraag naar het juiste team worden doorgestuurd en zie je hoeveel vraag er is naar verschillende services.

Bij procesanalyse is servicetype een handige dimensie om de data uit te splitsen. Filter de proceskaart op servicetype en je ziet of bepaalde aanvragen een heel ander proces volgen, een langere doorlooptijd hebben of vaker tot herstelwerk leiden. Met die informatie kun je verbeteringen richten op specifieke servicecategorieën.

Hiermee kun je processen voor verschillende aanvraagcategorieën filteren en vergelijken, zodat je bottlenecks en inefficiënties per type kunt opsporen.

Een standaardveld in de registratie van de serviceaanvraag, vaak gekoppeld aan een servicecatalogus.

De SLA-deadline is een streeftijdstip dat wordt berekend op basis van de service level agreement voor de aanvraag. De deadline hangt onder meer af van de prioriteit en het type aanvraag en het moment waarop deze is aangemaakt. Zo wordt bepaald binnen welke termijn de aanvraag naar verwachting wordt opgelost.

Dit attribuut vormt de basis voor alle SLA-complianceanalyses. Door de werkelijke oplostijd te vergelijken met de SLA-deadline, kunnen organisaties bepalen of een aanvraag op tijd is opgelost of dat de SLA is overschreden. Dit is een belangrijke KPI voor het meten van de servicekwaliteit. De analyse helpt ook terugkerende problemen op te sporen die vertragingen en SLA-overschrijdingen veroorzaken.

Dit is de maatstaf voor prestatieanalyses. Je gebruikt deze om SLA-compliancepercentages te berekenen en aanvragen op te sporen waarbij de deadline is overschreden.

Vaak een berekend veld in de registratie van de serviceaanvraag, op basis van het toegepaste SLA-beleid.

De toegewezen medewerker is de persoon die op een bepaald moment verantwoordelijk is voor de afhandeling van de serviceaanvraag. Tijdens de levenscyclus kan een aanvraag aan verschillende medewerkers worden toegewezen.

Dit attribuut is belangrijk voor analyses van prestaties en werkbelasting. Organisaties kunnen de prestaties van individuele medewerkers meten en vergelijken, bijvoorbeeld op basis van hun gemiddelde oplostijd en het aantal aanvragen dat ze behandelen. Ook kun je opnieuw toewijzen tussen medewerkers analyseren. Dat kan wijzen op problemen met de eerste beoordeling, de specialisatie van medewerkers of de verdeling van de werkbelasting.

Maakt het mogelijk om de prestaties en werkbelasting per medewerker te analyseren en te zien hoe vaak aanvragen opnieuw aan iemand anders worden toegewezen.

Beschikbaar in de registratie van de serviceaanvraag. Wijzigingen in dit veld worden vaak bijgehouden in een auditlog of geschiedenistabel.

Het toegewezen team is de supportgroep die verantwoordelijk is voor de serviceaanvraag. Afhankelijk van de benodigde expertise worden aanvragen vaak tussen teams doorgestuurd, bijvoorbeeld tussen een servicedesk van niveau 1, een netwerkteam en een softwareontwikkelingsteam.

Overdrachten tussen teams analyseren is een belangrijk onderdeel van process mining voor servicemanagement. Met dit attribuut kun je overdrachten tussen teams zichtbaar maken en communicatieproblemen of vertragingen opsporen. Ook kun je de prestaties van teams vergelijken, bijvoorbeeld op efficiëntie, aantal aanvragen en het vermogen om aanvragen op te lossen zonder verdere escalatie.

Belangrijk om overdrachten tussen teams te analyseren, vertragingen bij overdrachten op te sporen en teamprestaties te vergelijken.

Een standaardveld in de registratie van de serviceaanvraag. Wijzigingen in dit veld worden bijgehouden in een auditlog.

Aantal nieuwe toewijzingen is een metriek die telt hoe vaak een serviceaanvraag van de ene medewerker of het ene team naar een andere medewerker of een ander team is overgedragen. Een hoog aantal kan wijzen op problemen, zoals een onjuiste eerste routering, onvoldoende kennis bij medewerkers of onduidelijk eigenaarschap van het proces.

Dit is een belangrijke aanwijzing voor inefficiëntie in het proces. Met process mining kun je meten hoe vaak een aanvraag heen en weer wordt gestuurd. Door cases met veel nieuwe toewijzingen te analyseren, kun je verbeteringen in de eerste beoordeling opsporen, trainingen voor medewerkers aanpassen of teamverantwoordelijkheden verduidelijken. Zo komen aanvragen meteen bij het juiste team terecht.

Een belangrijke metriek om inefficiëntie in het proces op te sporen. Veel nieuwe toewijzingen hangen vaak samen met langere oplostijden en ontevreden gebruikers.

Dit is een berekende metriek: het aantal wijzigingen in het veld ‘AssignedAgent’ of ‘AssignedTeam’ voor een bepaalde ‘CaseId’.

Dit attribuut geeft aan bij welke afdeling of bedrijfseenheid de persoon hoort die de serviceaanvraag heeft ingediend. Zo krijgt de aanvraag organisatorische context.

Door aanvragen per afdeling te analyseren, kun je behoeften, trends of problemen binnen een afdeling opsporen. Een groot aantal aanvragen van een bepaald type bij de financiële afdeling kan bijvoorbeeld wijzen op behoefte aan gerichte training of een systeemverbetering. Ook kun je hiermee kosten doorbelasten en de vraag naar IT-services binnen de organisatie in kaart brengen.

Geeft organisatorische context en maakt het mogelijk aanvraagpatronen en de vraag naar services per bedrijfseenheid te analyseren.

Deze informatie komt meestal uit het gebruikersprofiel van de aanvrager in de medewerkersdirectory of het ITSM-systeem.

De eindtijd legt de exacte datum en tijd vast waarop een activiteit is afgerond. De starttijd markeert het begin, de eindtijd het einde. Samen bepalen ze hoelang een processtap duurt. Niet elke gebeurtenis heeft een aparte eindtijd; sommige gebeurtenissen zijn direct voorbij.

Met dit attribuut bereken je de verwerkingstijd van afzonderlijke activiteiten. Door de starttijd van de eindtijd af te trekken, kunnen analisten meten hoelang medewerkers of systemen actief aan een taak werken. Zo wordt duidelijk welke activiteiten veel tijd kosten en mogelijk geoptimaliseerd of geautomatiseerd kunnen worden.

Maakt het mogelijk de verwerkingstijd per activiteit te berekenen en te zien welke processtappen de meeste tijd kosten.

Te vinden in tabellen met event logs of auditsporen. Als de eindtijd niet expliciet beschikbaar is, kan deze worden afgeleid van de starttijd van de volgende activiteit.

Het indieningskanaal geeft aan hoe de serviceaanvraag is aangemaakt, bijvoorbeeld via een self-serviceportaal, e-mail, telefoon of API. Per kanaal kunnen andere processen of verwachtingen van gebruikers gelden.

Door het proces per indieningskanaal te analyseren, kun je belangrijke verschillen ontdekken. Aanvragen via een self-serviceportaal zijn bijvoorbeeld vaak vollediger en sneller op te lossen dan aanvragen via e-mail, waarbij gegevens handmatig moeten worden ingevoerd. Met deze analyse kunnen organisaties efficiëntere kanalen stimuleren of de processen voor minder efficiënte kanalen verbeteren.

Helpt bepalen of de indieningsmethode invloed heeft op de procesefficiëntie, de oplostijd of het percentage aanvragen dat bij het eerste contact wordt opgelost.

Meestal een standaardveld in de registratie van de serviceaanvraag.

Dit booleaanse attribuut geeft aan of de serviceaanvraag niet aan de afgesproken service level agreement heeft voldaan. De waarde is waar als de aanvraag na de ‘SlaDueDate’ is opgelost, en onwaar als dat niet zo is.

Dit attribuut maakt rapportages en analyses over SLA-compliance eenvoudiger. In plaats van in elke query datums te vergelijken, kun je met deze eenvoudige aanduiding aanvragen filteren en groeperen. Het is een belangrijke metriek voor dashboards over SLA-prestaties en maakt snel zichtbaar hoeveel aanvragen de servicetargets niet halen, zowel in aantallen als in percentages.

Geeft een duidelijke, eenvoudige aanduiding voor SLA-prestatieanalyses. Zo kun je aanvragen met een overschreden deadline makkelijk filteren en rapporteren.

Dit is een afgeleid attribuut dat tijdens de datatransformatie wordt berekend door de definitieve oplostimestamp te vergelijken met het veld ‘SlaDueDate’.

Met de oplossingscode wordt de uitkomst van een serviceaanvraag op een vaste manier ingedeeld. Voorbeelden zijn ‘Door gebruiker opgelost’, ‘Hardware vervangen’, ‘Software geïnstalleerd’ en ‘Dubbele aanvraag’. De medewerker vult deze informatie meestal in bij het sluiten van de aanvraag.

Deze codes zijn nuttig voor oorzaakanalyse. Door te bekijken hoe vaak verschillende oplossingscodes voorkomen, kunnen organisaties terugkerende problemen, veelgebruikte oplossingen en mogelijkheden voor kennisbankartikelen of automatische oplossingen opsporen. Een groot aantal oplossingen met de code ‘Wachtwoord opnieuw instellen’ kan bijvoorbeeld aanleiding zijn om te investeren in een self-servicefunctie voor het opnieuw instellen van wachtwoorden.

Maakt oorzaakanalyse mogelijk door de manier waarop aanvragen worden opgelost in categorieën in te delen. Zo kun je trends en mogelijkheden voor proactief probleembeheer opsporen.

Een veld dat de medewerker meestal handmatig invult bij het oplossen of sluiten van de serviceaanvraag.