De meeste VR-trainingspilots volgen hetzelfde traject. Een team krijgt budget voor een proof of concept, een studio bouwt een gepolijst scenario, iedereen zet de headset op tijdens de demo, en de zaal is onder de indruk. Zes maanden later liggen de headsets in een lade en is het project "in evaluatie".
Ik heb trainingssimulators gebouwd voor defensie en zorg, en de mislukte pilots die ik van dichtbij zag, faalden nooit op het VR-gedeelte. De tracking werkte. Het scenario zag er goed uit. Mensen vonden het leuk. De pilot strandde toch, om redenen die allemaal vastlagen vóór de eerste regel code.
De demo was het eindproduct
Een pilot die gebouwd is om te imponeren op een demo, optimaliseert het verkeerde. Alles gaat naar visuele afwerking en één perfect gescript pad door het scenario, want dat werkt in een sessie van tien minuten met een directeur die toekijkt.
Maar een uitrol heeft geen perfect pad nodig. Die heeft twintig middelmatige cursisten nodig die onverwachte dingen doen, een manier om scenariovarianten toe te voegen zonder de studio terug te bellen, en iemand op de trainingsafdeling die een sessie kan draaien zonder technicus in de ruimte. Niets daarvan staat op een demo-checklist, dus niets daarvan wordt gebouwd.
Niemand was eigenaar van de cijfers
Vraag wat de pilot moest bewijzen en je hoort meestal "dat VR-training werkt". Dat is geen claim die je kunt verifiëren met een headset en goede wil.
De pilots die de uitrol haalden, hadden vanaf dag één een saaie metriek: tijd tot competentie vergeleken met klassikale training, foutpercentages op een specifieke procedure, bespaarde instructeursuren per groep. De datapipeline die die cijfers vastlegt (sessielogs, scores, voltooiingsstatussen, geëxporteerd naar een plek waar een trainingsmanager echt kijkt) is onopvallend backendwerk. Het is ook het enige dat een tweede budget goedgekeurd krijgt.
De contentpipeline kwam achteraf
Eén scenario is een demo. Een trainingsprogramma is een bibliotheek van scenario's die mee verandert met de procedures. Als elke update een nieuw contract met de oorspronkelijke studio betekent, blijft de kostprijs per scenario hangen op "maatwerk softwareproject", en sterft het programma stilletjes bij de tweede factuur.
De oplossing is architecturaal, niet artistiek: bouw de scenariologica als data, niet als code. Configuratie voor ruimte-indelingen, procedurestappen, faaltriggers, scoreregels. Dan kost het tweede scenario een fractie van het eerste, en het tiende bijna niets.
Wat ik check voor ik iets bouw
- Een benoemde eigenaar aan klantzijde wiens werk erop vooruitgaat als de uitrol doorgaat.
- Eén meetbare claim die de pilot moet bewijzen, schriftelijk vastgelegd, met de bijbehorende datacapture in de scope van de build.
- Een plan voor het tweede scenario: wie maakt het, met welke tool, tegen welke kosten.
- Een test zonder technicus: kan een trainer in week twee zelfstandig een volledige sessie draaien?
Kan een pilot deze vragen niet beantwoorden, dan doet de content in de headset er nog niet toe. Dat gesprek is ongemakkelijk bij de kickoff, en veel goedkoper dan bij de post-mortem.