In bijna elke organisatie waar ik binnenkom, is het aanmaken van een nieuwe medewerker een reeks losse handelingen die één persoon uit zijn hoofd kent. Account aanmaken, licentie toewijzen, aan de juiste groepen koppelen, mailbox delen, laptop klaarzetten, iemand van HR mailen. Het gaat meestal goed. Tot die persoon op vakantie is, of tot er drie mensen tegelijk starten.
Bij vertrek is het beeld vaak slechter. Het account wordt geblokkeerd omdat HR daarom vraagt, maar de gedeelde mailbox blijft staan, de licentie blijft lopen, de laptop ligt nog thuis en de toegang tot het klantportaal van een leverancier is nooit ingetrokken. Niet omdat iemand slordig is, maar omdat niemand het ooit heeft opgeschreven.
Automatiseren is hier verleidelijk en meestal ook verstandig. Maar een script dat een onduidelijk proces uitvoert, maakt de onduidelijkheid alleen sneller. Daarom leg ik het proces eerst vast. Dit artikel beschrijft wat ik dan opschrijf, in welke volgorde, en waar de valkuilen zitten.
Begin bij de bron: wie mag een wijziging aanvragen?
De eerste vraag is niet technisch. Wie mag zeggen dat er iemand start of vertrekt, en via welk kanaal? In veel organisaties komt dat nu binnen via een telefoontje, een Teams-bericht of een mailtje aan de beheerder persoonlijk. Dat werkt tot het niet werkt: een startdatum die verkeerd is overgenomen, een vertrek dat pas na twee weken doorkomt.
Wat ik vastleg:
- De aanvrager. Meestal HR of de leidinggevende. Niet de nieuwe medewerker zelf en niet een collega die "het even regelt".
- Het kanaal. Eén formulier of één ticketcategorie, met vaste velden: naam, functie, afdeling, startdatum, leidinggevende, benodigde applicaties, type apparaat.
- De doorlooptijd. Bijvoorbeeld: een volledige aanvraag minimaal drie werkdagen vóór de startdatum. Dat lijkt bureaucratisch, maar het is de enige manier om een laptop op tijd klaar te hebben.
Deze afspraak levert meteen het eerste automatiseringspunt op: een formulier dat een ticket aanmaakt, is later ook de trigger voor een workflow.
Onboarding: de standaardset per functie
Het grootste tijdverlies zit in het per persoon bedenken welke rechten iemand nodig heeft. De oplossing is een standaardset per functie of afdeling, vastgelegd in groepen in Entra ID.
Concreet betekent dat:
- Eén groep per rol (bijvoorbeeld "Rol-Administratie", "Rol-Buitendienst") die lidmaatschap van alle onderliggende groepen regelt: licentie, Teams-kanalen, SharePoint-sites, gedeelde mailboxen, applicatietoegang.
- Licenties via groepen, niet per gebruiker. Wie in de groep zit, krijgt de licentie. Wie eruit gaat, verliest hem.
- Geen uitzonderingen in de standaardset. Extra rechten worden apart aangevraagd en apart vastgelegd, met een reden en een eigenaar.
Wanneer dit staat, wordt onboarding een kwestie van één account aanmaken en één rolgroep toewijzen. Alles daarachter volgt vanzelf. Dat is precies het punt waarop automatiseren zin krijgt: de handeling is klein, herhaalbaar en voorspelbaar.
Het apparaat hoort bij het proces
Een account op dag één is niets waard als de laptop op dag drie komt. Ik neem het apparaat daarom op in dezelfde checklist:
- Wie bestelt, en bij welke leverancier?
- Wordt het apparaat via Windows Autopilot en Intune ingericht, of handmatig? Handmatig betekent: wie doet het, hoe lang duurt het en waar staat de instructie?
- Waar wordt geregistreerd welk apparaat bij welke medewerker hoort? Dit is later cruciaal bij vertrek.
Organisaties die Intune al gebruiken, hebben hier een groot voordeel. Het apparaat richt zichzelf in zodra de medewerker inlogt. Zonder Intune is het geen ramp, maar dan moet de handmatige stap wel expliciet in de planning staan.
Offboarding: volgorde is belangrijker dan snelheid
Bij vertrek wil iedereen snel handelen, maar de volgorde bepaalt of je later problemen krijgt. De volgorde die ik aanhoud:
- Aanmelden blokkeren en sessies beëindigen. Wachtwoord resetten is niet genoeg; actieve sessies en app-tokens moeten worden ingetrokken.
- Multifactor-methoden verwijderen. Anders kan een privételefoon nog steeds als verificatiemiddel dienen.
- Mailbox en bestanden veiligstellen. Mailbox omzetten naar een gedeelde mailbox of archiveren, OneDrive overdragen aan de leidinggevende, met een vervaldatum.
- Rolgroep verwijderen. Daarmee vervallen licentie en toegangen in één keer.
- Apparaat terughalen en wissen. Via Intune op afstand, of fysiek bij inlevering. Registreren dat het is gebeurd.
- Externe toegangen intrekken. Leveranciersportalen, SaaS-tools buiten Microsoft 365, fysieke toegangspassen. Dit vergeet bijna iedereen, en dit is precies waar een lijst voor bestaat.
- Na dertig dagen definitief verwijderen, tenzij er een bewaarplicht geldt.
Elke stap krijgt een eigenaar. ICT doet de technische stappen, HR bewaakt de aanleiding en de datum, de leidinggevende beslist over mail en bestanden. Zonder die verdeling blijft het bij ICT liggen en blijft ICT gokken.
Wat ik bewust niet automatiseer
Niet elke stap leent zich voor een script. Twee dingen laat ik altijd bij een mens:
- De beslissing over gegevens. Wat er met de mailbox en bestanden van een vertrekkende medewerker gebeurt, is een keuze van de organisatie, niet van een workflow. De workflow kan de vraag stellen en de uitkomst uitvoeren, maar niet zelf beslissen.
- De laatste controle bij vertrek onder spanning. Bij een ontslag op staande voet wil je dat iemand meekijkt, zodat blokkeren en veiligstellen in de juiste volgorde gebeuren.
Alles daaromheen, van accountaanmaak tot licentietoewijzing en de herinnering aan de leidinggevende dat er nog een laptop ligt, kan prima door PowerShell of n8n worden gedaan. Maar pas nadat de lijst hierboven een paar keer met de hand is doorlopen en klopt.
Wat je overhoudt
Aan het einde van dit traject heb je drie documenten: een aanvraagformulier met vaste velden, een overzicht van rolgroepen met wat erin zit, en een offboarding-checklist met eigenaar per stap. Dat is geen dik handboek. Het past op twee A4'tjes en het is precies wat een nieuwe beheerder of een vervanger nodig heeft om het proces over te nemen.
En het is de basis waarop automatisering daarna veilig kan worden gebouwd.
