Uw Beheer van serviceaanvragen datatemplate
Uw Beheer van serviceaanvragen datatemplate
- Aanbevolen attributen voor grondige analyse
- Belangrijkste activiteiten om te volgen voor process discovery
- Begeleiding bij data-extractie uit je bronsysteem
Beheer van serviceaanvragen Attributen
| Naam | Omschrijving | ||
|---|---|---|---|
|
Activiteitsnaam
ActivityName
|
De naam van de gebeurtenis of taak die op een specifiek punt plaatsvond in de cyclus van de serviceaanvraag. | ||
|
Omschrijving
Dit attribuut beschrijft een specifieke stap of statuswijziging binnen het serviceaanvraagproces, zoals 'Aanvraag ingediend voor goedkeuring' of 'Serviceaanvraag afgehandeld'. Het analyseren van de volgorde en frequentie van activiteiten is onmisbaar voor het begrijpen van de processtroom, het vinden van knelpunten en het bekijken van afwijkingen van de standaardprocedure.
Het belang
Het definieert de stappen in de proceskaart, waardoor de visualisatie en analyse van de processtroom mogelijk is, inclusief het vinden van herstelwerk, knelpunten en afwijkingen.
Vindplaats
Doorgaans afgeleid van statuswijzigingen, journaalboekingen, of auditlog gebeurtenis beschrijvingen binnen Ivanti Service Manager.
Voorbeelden
Serviceverzoek AangemaaktAanvraag GoedgekeurdServiceaanvraag OpgelostServiceaanvraag Gesloten
|
|||
|
Serviceaanvraag-ID
ServiceRequestID
|
De unieke ID voor elke serviceaanvraag. | ||
|
Omschrijving
De Service Request ID identificeer jeniek elke individuele serviceaanvraag die is ingediend door een gebruiker of systeem. Het dient als de belangrijkste link die alle volgende gebeurtenissen met elkaar verbindt, van initiële registratie tot definitieve afsluiting, waardoor een complete, end-to-end-analyse van het verloop van elke serviceaanvraag mogelijk is.
Het belang
Dit is de essentiële case kenmerk die alle gerelateerde activiteiten verbindt tot één procesinstantie, waardoor end-to-end procesanalyse mogelijk worden.
Vindplaats
Dit is de primary key van het Service Request business object, vaak te vinden als ServiceReqNumber in de ServiceReq-tabel.
Voorbeelden
SR-0012345SR-0012346SR-0012347
|
|||
|
TijdsTip Gebeurtenis
EventTime
|
De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis heeft plaatsgevonden. | ||
|
Omschrijving
Event Time, ook bekend als de starttijd, is de precieze datum en tijd waarop een activiteit in het systeem werd vastgelegd. Deze timestamp is belangrijk voor het correct sequencen van gebeurtenissen en vormt de basis voor alle tijdsgebonden process mining-analyse, zoals het berekenen van doorlooptijden, wachttijden en activiteitsduren.
Het belang
Deze timestamp is belangrijk voor het chronologisch ordenen van gebeurtenissen en het berekenen van alle op duur gebaseerde metrieken, die belangrijk zijn voor prestatieanalyse.
Vindplaats
Gevonden in auditlogs, journaalposten (bijv. Journal.CreatedDateTime), of statuswijzigings gerelateerd aan de Serviceaanvraag.
Voorbeelden
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de data is opgehaald. | ||
|
Omschrijving
Dit attribuut identificeert de herkomst van de procesdata. Voor deze weergave zal de waarde constant zijn, wat aangeeft dat alle data afkomstig is van Ivanti Service Manager. Dit is belangrijk in omgevingen waar data mogelijk wordt samengevoegd uit meerdere systemen, waardoor een duidelijke data lineage en context wordt gewaarborgd.
Het belang
Het biedt belangrijke context over de herkomst van data, waardoor analyses correct worden toegeschreven aan het specifieke bronsysteem, vooral in multi-systeemomgevingen.
Vindplaats
Dit is doorgaans een vaste waarde die tijdens het data-extractieproces wordt toegevoegd om de herkomst van de dataset aan te geven.
Voorbeelden
Ivanti Service Manager
|
|||
|
Tijdstip van extractie
LastDataUpdate
|
De timestamp van de meest recente gegevensverversing uit het bronsysteem. | ||
|
Omschrijving
Dit attribuut geeft de datum en tijd aan wanneer de data voor het laatst is opgehaald uit Ivanti Service Manager. Het biedt context over de relevantie van de geanalyseerde data, waarbij wordt gewaarborgd dat gebruikers op de hoogte zijn van de periode die door de analyse wordt gedekt en wanneer de volgende update kan worden verwacht.
Het belang
Informeert gebruikers over de relevantie van de data, wat belangrijk is voor het nemen van beslissingen op basis van de meest actuele beschikbare procesprestatie-Informatie.
Vindplaats
Deze waarde wordt gegenereerd en gestempeld op de dataset op het moment van data-extractie.
Voorbeelden
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
Afhandeling Timestamp
ResolutionDateTime
|
De datum en tijd waarop de serviceaanvraag officieel is afgehandeld. | ||
|
Omschrijving
Dit is een case-level attribuut dat de uiteindelijke timestamp markeert wanneer de service werd geleverd of het probleem werd opgelost, voordat de aanvraag formeel wordt afgesloten. Deze timestamp is het primaire eindpunt voor het berekenen van de end-to-end doorlooptijd van een serviceaanvraag. Het is een belangrijk onderdeel voor het meten van de algehele procesefficiëntie en SLA-naleving.
Het belang
Definieert het eindpunt voor de berekening van de doorlooptijd van het kernproces, een key prestaties indicator voor de efficiëntie van dienstverlening.
Vindplaats
Een specifiek timestamp-veld op het Service Request-object, vaak genaamd 'OpgelostDateTime' of vergelijkbaar.
Voorbeelden
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Eindtijd van het gebeurtenis
EventEndTime
|
De timestamp waarop een activiteit is afgerond. | ||
|
Omschrijving
De Event End Time markeert de voltooiing van een activiteit. De duur tussen de Event Time (start) en Event End Time vertegenwoordigt de verwerkingstijd voor die specifieke activiteit. Dit is belangrijk voor het vinden welke stappen in het proces de meeste tijd in beslag nemen, en helpt inefficiënties en verbeterpunten aan te wijzen.
Het belang
Het maakt de berekening van individuele activiteitsduren mogelijk, wat belangrijk is voor het vinden van knelpunten in processen en langdurige taken.
Vindplaats
Bestaat mogelijk niet als een afzonderlijk veld. Vaak is het de starttijd van de volgende activiteit in de volgorde voor dezelfde case.
Voorbeelden
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
Prioriteit
Priority
|
Het prioriteitsniveau toegewezen aan de serviceaanvraag. | ||
|
Omschrijving
Prioriteit geeft de urgentie van een serviceaanvraag aan, doorgaans op een schaal zoals 'Laag', 'Medium', 'Hoog', 'Kritiek'. Dit attribuut is onmisbaar voor het ewaarderen of het proces aanvragen met hoge prioriteit effectief versnelt. Analyse omvat vaak het vergelijken van doorlooptijden en SLA-naleving over verschillende prioriteitsniveaus om te waarborgen dat de prioriteringsregels werken zoals bedoeld.
Het belang
Belangrijk voor het beoordelen van de effectiviteit van de prioriteringsstrategie en het waarborgen dat aanvragen met hoge prioriteit sneller worden afgehandeld dan die met lage prioriteit.
Vindplaats
Een standaardveld op het Service Request-object, meestal genaamd 'Prioriteit'.
Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
|
|||
|
Service Request Status
ServiceRequestStatus
|
De status van de serviceaanvraag op het moment van de gebeurtenis. | ||
|
Omschrijving
Dit attribuut legt de status van de serviceaanvraag vast, zoals 'Geregistreerd', 'In Behandeling', 'In Afwachting', 'Afgehandeld' of 'Gesloten'. Statuswijzigingen definiëren vaak de activiteiten in het proces log. Het analyseren van de tijd doorgebracht in elke status kan knelpunten zichtbaar maken, bijvoorbeeld als aanvragen te lang in een 'In Afwachting'-status blijven.
Het belang
Biedt een momentopname van de status van de aanvraag op elk moment, wat belangrijk is voor het berekenen van de tijd besteed in specifieke statussen en het vinden van processtagnaties.
Vindplaats
Een standaardveld op het Service Request-object, algemeen genaamd 'Status'.
Voorbeelden
VastgelegdActiefWachten op `klant`AfgehandeldGesloten
|
|||
|
SLA-deadline
SLADeadline
|
De timestamp waartegen de serviceaanvraag naar verwachting moet zijn afgehandeld. | ||
|
Omschrijving
De SLA-deadline is de berekende datum en tijd waartegen een serviceaanvraag moet zijn afgehandeld om te voldoen aan de Service Level Agreement. Dit doel wordt doorgaans bepaald op basis van factoren zoals de prioriteit en het type van de aanvraag. Het vergelijken van de werkelijke afhandeltijd met deze deadline is de basis voor het meten van SLA-naleving.
Het belang
Het is de benchmark waartegen de werkelijke prestaties worden gemeten, wat direct de berekening van het SLA-nalevingspercentages ondersteunt en risicovolle aanvragen identificeert.
Vindplaats
Dit is vaak een berekend veld binnen Ivanti, opgeslagen in velden gerelateerd aan de Service Level Agreement of Offering, zoals 'ResolutionTargetDateTime'.
Voorbeelden
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
SLA-Status
SLAStatus
|
Geeft aan of de serviceaanvraag binnen de SLA-deadline is afgehandeld. | ||
|
Omschrijving
Dit is een afgeleid attribuut dat elke serviceaanvraag markeert als 'Voldaan' of 'Overtreden' op basis van de oplostijd ten opzichte van de SLA-deadline. Het is de basis voor het 'SLA Naleving Prestaties' dashboard en de 'Service Level Agreement Nalevingspercentage' KPI. De logica vergelijkt de ResolutionDateTime met de SLADeadline voor elke case.
Het belang
Meet direct de prestaties ten opzichte van serviceverplichtingen, wat belangrijk is voor het beoordelen van servicekwaliteit en het behouden van gebruikersvertrouwen.
Vindplaats
Berekend door 'ResolutionDateTime' te vergelijken met de 'SLADeadline'. Als ResolutionDateTime <= SLADeadline, is de status 'Behaald'; anders is deze 'Overtreden'.
Voorbeelden
BehaaldOverschreden
|
|||
|
Toegewezen agent
AssignedAgent
|
De individuele gebruiker of agent toegewezen aan de serviceaanvraag. | ||
|
Omschrijving
De toegewezen medewerker is de specifieke persoon die verantwoordelijk is voor de afhandeling van de serviceaanvraag. Dit attribuut maakt analyse op individueel niveau mogelijk, wat nuttig is voor prestatiemanagement, taakverdeling en het vinden van trainingsmogelijkheden. Het volgen van herverdelingen tussen agenten is belangrijk voor het berekenen van KPI's zoals 'Gemiddeld aantal herverdelingen per aanvraag' en voor het begrijpen van procesinefficiënties.
Het belang
Maakt analyse mogelijk van individuele werkbelasting, prestaties en herverdelingspatronen, wat kan wijzen op problemen met training, vaardigheden of initiële routering.
Vindplaats
Doorgaans te vinden in een veld zoals 'Eigenaar' op het Service Request object. Dit kan veranderen bij elke herverdeling en moet worden bijgehouden in het event log.
Voorbeelden
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
Toegewezen Team
AssignedTeam
|
Het supportteam of de groep momenteel toegewezen om de serviceaanvraag af te handelen. | ||
|
Omschrijving
Dit attribuut identificeert het team dat verantwoordelijk is voor het uitvoeren van de serviceaanvraag op een bepaald moment. Het analyseren van overdrachten tussen teams, de tijd doorgebracht met elk team en het volume aan aanvragen afgehandeld door verschillende teams is belangrijk voor het begrijpen van de werklastverdeling, het vinden van knelpunten en het ewaarderen van teamprestaties. Het ondersteunt direct dashboards gerelateerd aan SLA-naleving en agentwerklast.
Het belang
Volgt verantwoordelijkheid en overdrachten, helpt bij het analyseren van vertragingen tussen teams, werklastbalans en welke teams knelpunten vormen in het proces.
Vindplaats
Deze Informatie wordt doorgaans opgeslagen in een veld zoals 'OwnerTeam' op het Service Request object of in gerelateerde toewijzingsrecords.
Voorbeelden
IT Servicedesk`Netwerkbeheer`HR SupportFaciliteitenbeheer
|
|||
|
Type Serviceaanvraag
ServiceRequestType
|
De classificatie of categorie van de serviceaanvraag. | ||
|
Omschrijving
Dit attribuut categoriseert de serviceaanvraag, bijvoorbeeld 'Hardware aanvraag', 'Software installatie' of 'Wachtwoord reset'. Het is een kritieke dimensie voor analyse, waardoor teams procesprestaties, doorlooptijden en SLA-naleving kunnen vergelijken over verschillende typen diensten. Het begrijpen van deze verschillen helpt bij het afstemmen van procesverbeteringen en het effectiever toewijzen van middelen.
Het belang
Het segmenteren van het proces op type aanvraag maakt gerichte analyse mogelijk en onthult of bepaalde soorten aanvragen gevoeliger zijn voor vertragingen, herstelwerk of SLA-overschrijdingen.
Vindplaats
Waarschijnlijk een veld op het Service Request business object, vaak genaamd 'Service' of 'Categorie'. Raadpleeg de Ivanti Service Manager-documentatie voor specifieke veldnamen zoals 'SvcReqTmplKoppeling_Category'.
Voorbeelden
Nieuwe hardwareaanvraagSoftware AccessAccountwijzigingInformatieaanvraag
|
|||
|
Aantal Heropeningen
ReopenCount
|
Het aantal keren dat een afgehandelde serviceaanvraag opnieuw is geopend. | ||
|
Omschrijving
Dit attribuut is een teller die toeneemt telkens wanneer een serviceaanvraag vanuit een 'Afgehandeld' of 'Gesloten' status terug naar een 'Actief' status wordt verplaatst. Een hoog aantal heropeningen is een sterke indicator van een slechte 'first-time resolution' kwaliteit, onvolledige oplossingen of terugkerende problemen. Het ondersteunt direct de 'Service Request Herbewerkingspercentage' KPI.
Het belang
Meet direct herstelwerk en is een belangrijke indicator van de kwaliteit van de oplossing. Hoge aantallen suggereren dat de initiële oplossing niet effectief was.
Vindplaats
Dit is doorgaans een teller-veld op het Service Request object dat wordt verhoogd door een bedrijfsregel wanneer de status passend verandert. Het kan 'ReopenCounter' heten.
Voorbeelden
0123
|
|||
|
Aantal toewijzingen
AssignmentCount
|
Het totale aantal keren dat een serviceaanvraag is toegewezen of herverdeeld. | ||
|
Omschrijving
Deze berekende metriek telt het aantal toewijzingsgerelateerde activiteiten (bijv. 'Toegewezen aan team', 'Toegewezen aan agent') voor elke serviceaanvraag. Een hoog aantal herverdelingen, vaak 'ticket ping-pong' genoemd, duidt op inefficiënties in routering, gebrek aan 'first-contact resolution' of onduidelijke teamverantwoordelijkheden. Dit attribuut is belangrijk voor de 'Gemiddeld aantal herverdelingen per aanvraag' KPI.
Het belang
Kwantificeert inefficiënte overdrachten en routeringsproblemen. Een hoog aantal is een sterke indicator voor langere oplostijden en frustratie bij gebruikers.
Vindplaats
Berekend door het aantal toewijzingsgerelateerde activiteiten te tellen voor elke unieke ServiceRequestID tijdens datavoorbereiding.
Voorbeelden
12345
|
|||
|
Afdeling van aanvrager
RequestorDepartment
|
De zakelijke afdeling van de gebruiker die de serviceaanvraag heeft ingediend. | ||
|
Omschrijving
Dit attribuut identificeert de afdeling van de medewerker of het systeem dat de serviceaanvraag heeft geïnitieerd, zoals 'Verkoop', 'Financiën' of 'Human Bronnen'. Het maakt analyse van servicekwaliteit en -vraag mogelijk binnen verschillende onderdelen van de organisatie. Het kan bijvoorbeeld helpen vinden of bepaalde afdelingen langere oplostijden ervaren of een hoger volume aan aanvragen indienen.
Het belang
Maakt analyse mogelijk van serviceverbruik en -kwaliteit per businessunit, wat helpt bij het vinden van afdelingsspecifieke problemen of trends.
Vindplaats
Deze Informatie wordt meestal opgehaald uit het gebruikersprofiel van de aanvrager, gekoppeld aan de Service Request. Het veld kan 'Department' zijn in het Profile.Employee object.
Voorbeelden
FinanciënVerkoopMarketingInformatietechnologie
|
|||
|
Is herstelwerk
IsRework
|
Een booleaanse vlag die aangeeft of de serviceaanvraag rework omvatte. | ||
|
Omschrijving
Deze berekende vlag wordt ingesteld op 'waar' als een serviceaanvraag tekenen van herstelwerk vertoont, zoals opnieuw worden geopend na afhandeling of bepaalde activiteiten herhaaldelijk in een lus uitvoeren. Het vereenvoudigt de berekening van de 'Service Request Herbewerkingspercentage' KPI en helpt bij het filteren op inefficiënte procesinstanties in dashboards zoals 'Herbewerking en Herverdeling Flows'.
Het belang
Helpt om eenvoudig het volume aan aanvragen te vinden en te kwantificeren die extra, ongeplande inspanning vereisen, wat kwaliteits- en efficiëntieproblemen benadrukt.
Vindplaats
Afgeleid van de data. De logica kan gebaseerd zijn op het 'ReopenCount'-attribuut dat groter is dan nul, of door specifieke activiteitsvolgordes te detecteren, zoals meerdere 'Toegewezen aan Agent'-gebeurtenissen.
Voorbeelden
truefalse
|
|||
|
Kanaal
Channel
|
De methode of het kanaal waarmee de serviceaanvraag is ingediend. | ||
|
Omschrijving
Het kanaal geeft aan hoe de serviceaanvraag is aangemaakt, bijvoorbeeld via de Self-Service Portal, e-mail, telefoon, of automatisch door een ander systeem. Het analyseren van aanvraagvolumes en oplostijden per kanaal kan inzicht geven in welke kanalen het meest efficiënt zijn en welke mogelijk procesverbeteringen of gebruikerstraining vereisen.
Het belang
Helpt bij het begrijpen van gebruikersgedrag en kanaalefficiëntie, wat beslissingen kan Informapakketmeren over de servicedienstverleningsstrategie en automatiseringsmogelijkheden.
Vindplaats
Dit wordt vaak opgeslagen in een veld van het type 'Bron' of 'Aangemaakt door' op het Service Request object.
Voorbeelden
Self ServiceE-mailTelefoonDirecte invoer
|
|||
|
Naam Leverancier
VendorName
|
De naam van de externe leverancier die betrokken is bij het afhandelen van de aanvraag. | ||
|
Omschrijving
Dit attribuut identificeert de externe leverancier die is ingeschakeld om te helpen bij of een serviceaanvraag te voltooien. Het is belangrijk voor het 'Externe Leveranciersactiviteit Duur' dashboard, aangezien het meten en vergelijken van de prestaties van verschillende leveranciers mogelijk maakt. Het volgen hiervan helpt bij het beheren van leveranciersrelaties en het vinden van knelpunten veroorzaakt door externe afhankelijkheden.
Het belang
Maakt analyse mogelijk van de prestaties van derden en hun impact op de algehele afhandeltijden van serviceaanvragen, ter ondersteuning van leveranciersmanagement.
Vindplaats
Dit kan een veld zijn op een taakobject geassocieerd met de serviceaanvraag, of een specifiek veld op de Service Request zelf indien een leverancier is toegewezen.
Voorbeelden
Dell SupportOracle ConsultingMicrosoft Premiernull
|
|||
|
Oplossingscategorie
ResolutionCategory
|
Een classificatie van de geboden oplossing voor de serviceaanvraag. | ||
|
Omschrijving
De Afhandelingscategorie biedt een gestructureerde manier om te classificeren hoe een serviceaanvraag uiteindelijk is afgehandeld. Dit is vaak een hiërarchische classificatie (bijv. Categorie, Subcategorie) die helpt bij oorzaakanalyse en trendrapportage. Het kan bijvoorbeeld terugkerende problemen of veelvoorkomende typen afhandelingsacties benadrukken, die kunnen worden gebruikt om diensten te verbeteren of knowledge base artikelen te creëren.
Het belang
Biedt inzichten in de aard van oplossingen, wat helpt bij het vinden van veelvoorkomende problemen, serviceverbeteringsmogelijkheden en automatiseringskandidaten.
Vindplaats
Vaak opgeslagen in categorisatievelden die worden ingevuld bij afhandeling, zoals 'ResolutionCategory' of een aangepast sluitingscodeveld.
Voorbeelden
Gebruikerstraining vereistSoftware geïmplementeerdHardware gerepareerdToegang verleend
|
|||
Beheer van serviceaanvragen Activiteiten
| Activiteit | Omschrijving | ||
|---|---|---|---|
|
Aanvraag Toegewezen aan `Agent`
|
Een specifieke agent neemt de eigendom van de serviceaanvraag op zich. Deze activiteit wordt doorgaans afgeleid wanneer het 'Eigenaar'-veld, dat de individuele agent aanduidt, voor het eerst wordt ingevuld of bijgewerkt. | ||
|
Het belang
Dit markeert het einde van de initiële wacht- of wachtrijtijd. Het meten van de duur vóór deze activiteit helpt bij het vinden van problemen met bron-allocatie en ondersteunt het Agent Werklast dashboard.
Vindplaats
Afgeleid uit het vullen of wijzigen van het 'Eigenaar'-veld in de Service Request-record, zoals te zien in de audithistorie.
Vastleggen
De eerste timestamp waarbij het veld 'Eigenaar' is ingevuld met de naam van een agent na aanmaak of teamtoewijzing.
Gebeurtenistype
inferred
|
|||
|
Aanvraag toegewezen aan team
|
De serviceaanvraag is toegewezen aan een specifiek supportteam voor afhandeling. Dit wordt vastgelegd door het invullen of wijzigen van het veld 'OwnerTeam' in de Service Request record. | ||
|
Het belang
Deze gebeurtenis is belangrijk voor het analyseren van prestaties op teamniveau, werklastverdeling en overdrachtstijden tussen teams. Het helpt vinden welke teams knelpunten vormen in het proces.
Vindplaats
Bijgehouden door wijzigingen in het veld 'OwnerTeam' binnen de audithistorie of het journaal van de Service Request.
Vastleggen
Een update-gebeurtenis van het 'OwnerTeam'-veld, dat doorgaans wordt gelogd in een audittrail.
Gebeurtenistype
explicit
|
|||
|
Serviceaanvraag Gesloten
|
De serviceaanvraag is officieel afgesloten en er kunnen geen verdere acties worden ondernomen. Dit gebeurt vaak automatisch na een ingestelde periode in de status 'Afgehandeld', wat de definitieve afsluiting van de levenscyclus vertegenwoordigt. | ||
|
Het belang
Deze activiteit is het definitieve einde van het proces. De tijd tussen 'Afgehandeld' en 'Gesloten' kan vertragingen benadrukken bij bevestiging of geautomatiseerde systeemprocessen.
Vindplaats
Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Gesloten', samen met de bijbehorende timestamp.
Vastleggen
Het detecteren van de update van het 'Status'-veld naar 'Gesloten' uit de audithistorie.
Gebeurtenistype
inferred
|
|||
|
Serviceaanvraag Opgelost
|
De serviceaanvraag wordt als afgehandeld beschouwd en de oplossing is aan de gebruiker geleverd. Dit is een belangrijke mijlpaal, vastgelegd door een statuswijziging naar 'Afgehandeld', wat vaak de SLA-klok stopt. | ||
|
Het belang
Dit is een kritiek eindpunt voor het meten van de oplostijd en SLA-naleving. De duur vanaf de aanmaak tot deze activiteit is een kern-KPI voor procesprestaties.
Vindplaats
Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Afgehandeld', samen met de bijbehorende timestamp.
Vastleggen
Het detecteren van de update van het 'Status'-veld naar 'Afgehandeld' uit de audithistorie.
Gebeurtenistype
inferred
|
|||
|
Serviceverzoek Aangemaakt
|
Deze activiteit markeert het begin van de cyclus van de serviceaanvraag wanneer een nieuwe aanvraag formeel wordt ingediend en geregistreerd in Ivanti. Deze gebeurtenis wordt vastgelegd wanneer een nieuwe record wordt aangemaakt in het Service Request business object, waarbij een unieke Service Request ID wordt gegenereerd. | ||
|
Het belang
Dit is de primaire start gebeurtenis voor het proces. Het analyseren van de tijd vanaf dit punt tot aan de afhandeling is onmisbaar voor het meten van de totale doorlooptijd en procesefficiëntie.
Vindplaats
Dit wordt vastgelegd vanuit de aanmaak-timestamp van de Service Request record (bijv. CreatedDateTime veld in het ServiceReq business object).
Vastleggen
De recordaanmaak gebeurtenis in de ServiceReq-tabel, geïdentificeerd door de creatie-timestamp.
Gebeurtenistype
explicit
|
|||
|
Aanvraag Goedgekeurd
|
De serviceaanvraag heeft alle benodigde goedkeuringen ontvangen en kan nu worden afgehandeld. Deze gebeurtenis wordt vastgelegd wanneer de goedkeurings-workflow succesvol wordt afgesloten, waardoor de status van de aanvraag verandert. | ||
|
Het belang
Deze activiteit markeert een belangrijke mijlpaal, die het einde van de goedkeuringsfase en de start van de afhandeling aangeeft. Het maakt het meten van de efficiëntie van het goedkeuringsproces zelf mogelijk.
Vindplaats
Afgeleid van een statuswijziging van 'Wachten op Goedkeuring' naar 'Goedgekeurd' of 'Vervuld'. Dit kan ook een expliciete gebeurtenis zijn die is gelogd in het FRS_Approval business object.
Vastleggen
Een wijziging in het 'Status'-veld van de Service Request-record van een goedkeuringsstatus naar een actieve status.
Gebeurtenistype
inferred
|
|||
|
Aanvraag ingediend voor goedkeuring
|
De serviceaanvraag is ingediend voor de benodigde goedkeuringen voordat deze kan worden afgehandeld. Dit wordt doorgaans afgeleid wanneer de aanvraagstatus verandert naar 'Ingediend' of 'In afwachting van goedkeuring', wat vaak een goedkeurings-workflow activeert. | ||
|
Het belang
Het volgen van deze activiteit helpt vertragingen te vinden in de goedkeuringsfase. Lange wachttijden hier kunnen een significant knelpunt zijn, wat de algehele oplostijden en gebruikerstevredenheid beïnvloedt.
Vindplaats
Afgeleid van een statuswijziging op de Service Request-record, waarschijnlijk naar een status zoals 'Ingediend' of 'Wachten op Goedkeuring'. Dit kan ook worden verkregen uit de FRS_Approval of FRS_ApprovalVoteTracking business objects.
Vastleggen
Een wijziging in het 'Status'-veld van de Service Request-record naar een goedkeuring-in-afwachting status.
Gebeurtenistype
inferred
|
|||
|
Externe leverancier ingeschakeld
|
De afhandeling van de serviceaanvraag is overgedragen aan een externe leverancier of derde partij. Dit wordt doorgaans vastgelegd door een statuswijziging naar 'Wachtend op 3e Partij' of een vergelijkbare status. | ||
|
Het belang
Deze activiteit is belangrijk voor het meten van leveranciersprestaties en de impact ervan op de totale doorlooptijd. Het maakt analyse van leveranciersgerelateerde vertragingen mogelijk en ondersteunt het 'Externe Leveranciersactiviteit Duur' dashboard.
Vindplaats
Afgeleid van een statuswijziging in de Service Request-record naar een status zoals 'Wachten op 3e Partij' of 'In Afwachting van Leverancier'.
Vastleggen
Het detecteren van een wijziging in het 'Status'-veld naar een aangewezen 'wachten op leverancier'-status.
Gebeurtenistype
inferred
|
|||
|
Informatie geleverd door gebruiker
|
De aanvrager heeft de benodigde Informatie verstrekt, waardoor de agent het werk kan hervatten. Dit wordt vastgelegd wanneer de aanvraag vanuit een 'Wachtend op Klant'-status terugkeert naar een actieve status. | ||
|
Het belang
Deze gebeurtenis sluit de cirkel van Informatieaanvragen. De tijd tussen het aanvragen en ontvangen van Informatie is een belangrijk onderdeel van procesvertragingen en herstelwerkslussen.
Vindplaats
Afgeleid wanneer het 'Status'-veld van de Service Request verandert van een 'Wachten op Klant'-status naar een actieve status, zoals 'Actief' of 'In Behandeling'.
Vastleggen
Het detecteren van een statuswijziging van een 'wachten op gebruiker'-status naar een actieve status.
Gebeurtenistype
inferred
|
|||
|
Informatie gevraagd van gebruiker
|
De toegewezen medewerker heeft meer Informatie nodig van de aanvrager om verder te gaan met de afhandeling. Dit wordt vastgelegd wanneer de status van de aanvraag wordt bijgewerkt naar een status zoals 'Wachtend op Klant'. | ||
|
Het belang
Deze activiteit belicht vertragingen veroorzaakt door onvolledige initiële Informatie. Het bijhouden van de frequentie en duur ervan is belangrijk voor de Impactanalyse van Informatieaanvragen en het vinden van gebieden voor procesverbetering.
Vindplaats
Afgeleid van een statuswijziging in de Service Request-record naar een status zoals 'Wachten op Klant' of 'In Afwachting'.
Vastleggen
Het detecteren van een wijziging in het 'Status'-veld naar een aangewezen 'wachten op gebruiker'-status.
Gebeurtenistype
inferred
|
|||
|
Prioriteit Gewijzigd
|
De prioriteit van de serviceaanvraag is bijgewerkt na de initiële aanmaak. Deze gebeurtenis wordt vastgelegd vanuit het auditlog of de geschiedenis die veldniveauwijzigingen bijhoudt. | ||
|
Het belang
Het volgen van prioriteitswijzigingen is belangrijk voor het Overzicht Effectiviteit Prioritering. Het helpt te bepalen of escalaties correct worden beheerd en of de initiële prioritering accuraat is.
Vindplaats
Dit is een expliciete gebeurtenis vastgelegd uit de audithistorie van de Service Request record, die wijzigingen in het veld 'Prioriteit' registreert.
Vastleggen
Een update-gebeurtenis van het 'Prioriteit'-veld vastgelegd in de audittrail van het systeem.
Gebeurtenistype
explicit
|
|||
|
Service Request Uitgevoerd
|
Alle taken die nodig zijn om de serviceaanvraag te vervullen, zijn voltooid door de agent of het systeem. Dit wordt vastgelegd door een statuswijziging naar 'Vervuld', wat vaak voorafgaat aan de uiteindelijke 'Afgehandeld' status. | ||
|
Het belang
Deze mijlpaal markeert de voltooiing van het technische of procedurele werk. Het is een belangrijk punt voor het meten van de actieve afhandeltijd vóór de definitieve bevestiging en afsluiting.
Vindplaats
Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Vervuld'.
Vastleggen
Een wijziging in het 'Status'-veld naar 'Vervuld' gedetecteerd uit de historiek van het record.
Gebeurtenistype
inferred
|
|||
|
Serviceaanvraag geannuleerd
|
De serviceaanvraag is geannuleerd door de gebruiker of een agent voor de afhandeling. Dit is een alternatieve eindstatus, vastgelegd door een statuswijziging naar 'Geannuleerd' of 'Ingetrokken'. | ||
|
Het belang
Dit vertegenwoordigt een niet-standaard procesbeëindiging. Het analyseren waarom aanvragen worden geannuleerd, kan problemen inzichtelijk maken met het aanvraagproces zelf of veranderende gebruikersbehoeften.
Vindplaats
Afgeleid van een wijziging in het 'Status'-veld van de Service Request-record naar 'Geannuleerd'.
Vastleggen
Het detecteren van de update van het 'Status'-veld naar 'Geannuleerd' uit de audithistorie.
Gebeurtenistype
inferred
|
|||
|
Serviceaanvraag Heropend
|
Een eerder afgehandelde serviceaanvraag is opnieuw geactiveerd omdat het probleem aanhoudt of de oplossing onvoldoende was. Dit wordt vastgelegd wanneer de status verschuift van 'Afgehandeld' terug naar een actieve status zoals 'Actief' of 'Toegewezen'. | ||
|
Het belang
Deze activiteit is een directe indicator van herstelwerk en een slechte 'first-time resolution' kwaliteit. Het analyseren van heropenings-gebeurtenissen helpt proceszwaktes te vinden en de 'Service Request Herbewerkingspercentage' KPI te verbeteren.
Vindplaats
Afgeleid uit de audithistorie wanneer het 'Status'-veld verandert van 'Afgehandeld' of 'Gesloten' naar een actieve status.
Vastleggen
Een statuswijziging van een eindstatus ('Afgehandeld', 'Gesloten') naar een open status ('Actief', 'Toegewezen').
Gebeurtenistype
inferred
|
|||