ITIL request fulfilment zonder ticket: een Microsoft-aanpak

In ITIL is request fulfilment het proces dat standaard service requests afhandelt: een nieuwe medewerker die toegang nodig heeft, iemand die een applicatie aanvraagt, een rechtenwijziging. Een groot deel daarvan gaat over toegang, en juist dat deel kun je laten afhandelen door regels in plaats van tickets. Dit artikel legt de vertaling uit.

TL;DR

• Request fulfilment is in ITIL het afhandelen van voorspelbare, herhaalbare service requests.
• Een groot deel van die requests gaat over toegang en volgt een attribuut.
• Wat een attribuut volgt, kun je modelleren als een regel in Entra ID, zonder ticket.
• Het proces blijft, alleen de uitvoering verschuift van handmatig naar regel-gedreven.
• Approval en uitzonderingen houd je in het proces, daar waar oordeel nodig is.

Wat request fulfilment in ITIL is

Request fulfilment is een van de processen in service operation. Het gaat niet over storingen (dat is incident management) maar over standaardverzoeken die vaak voorkomen en een bekende afhandeling hebben. Denk aan toegang tot een systeem, een softwarelicentie, een wijziging in lidmaatschap.

De kern is dat een service request voorspelbaar is. Hij past in een catalogus, heeft een vaste route, en vaak een vooraf bepaalde goedkeuring. Dat is precies wat hem geschikt maakt voor automatisering: voorspelbaar werk met een bekend patroon.

Waarom toegang het ideale startpunt is

Kijk je naar de service requests die het vaakst binnenkomen, dan zijn dat meestal toegangsverzoeken. Een nieuwe collega heeft de standaardtoegang nodig, iemand wisselt van afdeling, iemand wil bij een gedeelde resource.

In bijna al die gevallen bepaalt een attribuut de uitkomst. De afdeling bepaalt welke apps, de functie bepaalt welke rollen, de locatie bepaalt welke lokale rechten. En als een attribuut de uitkomst bepaalt, hoeft er geen mens tussen te zitten om het te beslissen.

De vertaling: van proces naar regel

Het ITIL-proces blijft staan. Wat verschuift is de uitvoering. In plaats van dat een medewerker per ticket de juiste groep opzoekt en de wijziging doorvoert, vang je de logica in een regel.

ITIL request fulfilment	Handmatige uitvoering	Attribuut-gedreven uitvoering
Standaard toegang nieuwe medewerker	Ticket, mens zoekt groep	Regel op afdeling en functie
Rolwisseling	Ticket, mens past lidmaatschap aan	Attribuut verandert, lidmaatschap volgt
Locatiegebonden recht	Ticket	Regel op stad of vestiging
Toegang tot gevoelig systeem	Ticket met approval	Approval blijft, mens beslist

De eerste drie rijen verschuiven naar regels. De laatste blijft bewust in het proces, want daar telt het oordeel.

Hoe dat eruitziet in Entra ID

In Entra ID-termen wordt het patroon een membership rule. Een paar voorbeelden:

user.department -eq "Finance" -> lid van Finance-Apps
user.jobTitle -contains "Controller" -> lid van Controllers
user.city -eq "Lichtenvoorde" -> lid van Office-Lichtenvoorde

Komt er een nieuwe Controller bij Finance in Lichtenvoorde binnen, dan pakken de regels dat op zonder dat iemand een ticket opent. Het request wordt vervuld op het moment dat de attributen kloppen.

Wisselt iemand later van rol, dan verandert het lidmaatschap mee. De rechten die niet meer passen, vallen weg zonder dat iemand daar een apart verzoek voor hoeft in te dienen.

Wat in het proces blijft

Niet alles wordt een regel. Wat in het ITIL-proces blijft:

• Goedkeuring voor gevoelige toegang. Admin-rechten, financiele systemen. Daar wil je een expliciete akkoord.
• Uitzonderingen. Een verzoek dat niet in het patroon past, hoort gewoon bij de servicedesk thuis.
• De catalogus zelf. Wat aanvraagbaar is en onder welke voorwaarden, blijft een bewuste keuze.

Zo automatiseer je het voorspelbare deel van request fulfilment en houd je het oordeel waar het hoort.

Hoe ServiceChanger hierin past

ServiceChanger past lidmaatschappen van groepen en rollen in Entra ID en on-prem AD toe op basis van attributen (ABAC). Dat maakt het de uitvoerende laag onder het deel van request fulfilment dat een attribuut volgt: je legt de logica vast, en het lidmaatschap klopt en blijft kloppen.

ServiceChanger werkt op de attributen die al in je directory staan, binnen Microsoft en Azure. De License-module houdt licentiegebruik bij op basis van Entra-aanmeldactiviteit; de toewijzing van licenties zelf blijft bij Microsoft. Standaard reageert ServiceChanger op de attributen die al in je directory staan. Wil je je HR-systeem koppelen voor onboarding en offboarding, dan bouwen we dat als maatwerk met automation accounts en runbooks in Azure. Voor het AI-gedreven afhandelen van tickets is er ITSM Autopilot, ons zusterproduct.

FAQ

Vervangt dit mijn ITSM-tool? Nee. Het ITIL-proces en je servicedesktool blijven. ServiceChanger neemt het uitvoerende toegangswerk over voor de requests die een attribuut volgen.

Wat met approval-flows? Die houd je. Voor gevoelige toegang blijft een bewuste menselijke goedkeuring onderdeel van het proces.

Geldt dit ook voor on-prem Active Directory? Ja. ServiceChanger past regels toe op zowel Entra ID als on-prem AD, zodat een hybride omgeving onder één model valt.

Hoe weet ik zeker dat een regel het juiste doet? Zet de regel eerst naast je huidige situatie en vergelijk wie de regel oppakt versus wie er nu in zit. Pas verschillen aan, zet daarna live.

Verder lezen

• Wat is ABAC in Entra ID voor de membership rules in detail.
• Servicedesk automatiseren: stop met handmatige toegangsverzoeken voor de praktische uitwerking.

Volgende stap

Wil je het voorspelbare deel van request fulfilment laten afhandelen door regels? ServiceChanger automatiseert groeps- en rollidmaatschap in Entra ID op basis van attributen. Plan een demo of lees de ABAC-documentatie.