Maandelijkse modelupdates in een change-proces met twee CAB's per maand
Het shared service center van een logistiek dienstverlener verwerkt 240.000 inkoopfacturen per jaar. Sinds 2024 leest een AI-tool van leverancier CloudDoc facturen uit en stelt boekingsregels voor; 70% wordt automatisch geboekt, de rest gaat naar een medewerker. De leverancier brengt maandelijks een nieuwe modelversie uit, zonder changelog en met een release note van drie regels. In Q1 steeg het percentage facturen dat op de verkeerde kostenplaats belandde van 0,8% naar 4,1%; dat viel pas op bij de maandafsluiting, zes weken later. FB werkt met een normale wijzigingsprocedure: een CAB die twee keer per maand samenkomt en een doorlooptijd van tien werkdagen. Het contract verplicht de organisatie updates binnen 14 dagen te accepteren. De leverancier biedt wel een mogelijkheid om terug te vallen op de vorige modelversie, maar die staat niet ingericht. Er is geen vaste testset met facturen waarvan de juiste boeking bekend is.
1. Hoe classificeer je deze maandelijkse modelupdates in het change management? Onderbouw je keuze en benoem de voorwaarden waaronder die classificatie houdbaar is.
Read the worked answer
Een normale change is hier niet houdbaar: tien werkdagen doorlooptijd plus twee CAB-momenten past niet op een contractuele termijn van 14 dagen, en de CAB kan de inhoud van een modelversie niet beoordelen. Maar de update zonder meer als standaard change bestempelen is ook onjuist, want dan verandert het gedrag van een essentieel financieel proces zonder enige toets.
De houdbare route is een vooraf geautoriseerde standaard change, met drie harde voorwaarden:
- Een vaste regressietest. Een set van bijvoorbeeld 500 historische facturen met de juiste boeking, die bij elke release automatisch wordt gedraaid. Zonder die set is er geen objectief acceptatiecriterium en dus geen grond om vooraf te autoriseren.
- Drempels vooraf vastgesteld. Bijvoorbeeld: veldnauwkeurigheid mag niet meer dan 1 procentpunt dalen en de kostenplaatsnauwkeurigheid moet boven 99% blijven. De CAB autoriseert het criterium, niet elke release.
- Ingerichte rollback. De vorige versie moet binnen een dag terugzetbaar zijn, met een benoemde persoon die dat mag beslissen.
Als een release niet door de test komt, valt hij terug naar een normale change en gaat hij naar de CAB. Zo blijft de controle op het niveau van het criterium en niet op het niveau van de leveranciersrelease.
2. Ontwerp de minimale controle waarmee een stijging van 0,8% naar 4,1% volgende keer binnen een week wordt gezien.
Read the worked answer
De maandafsluiting is te laat en te grof: die meet het cumulatieve resultaat over een hele periode en kan een verschuiving niet meer toewijzen aan een gebeurtenis. De controle moet daarom dichter op de verwerking zitten.
Minimaal:
- Dagelijkse of wekelijkse steekproef van 150 tot 200 verwerkte facturen, met four-eyes-controle op de voorgestelde boeking. Bij 240.000 facturen per jaar is dat ongeveer 4.600 per week; een steekproef van 200 geeft bij een foutpercentage van 1% voldoende signaal om een sprong naar 4% binnen enkele dagen te zien.
- Een proces-KPI met alarmdrempel, niet alleen een model-KPI: percentage boekingen op de juiste kostenplaats, met een grens die direct na een release extra gevoelig staat (bijvoorbeeld een melding bij meer dan 1,5% afwijking in de steekproef).
- Koppeling met het releasemoment. De uitkomst van de steekproef wordt per modelversie vastgelegd, zodat een afwijking herleidbaar is tot de release in plaats van tot 'het systeem'.
Daarnaast: bij een release een verhoogde steekproef in de eerste drie dagen. Dat is de goedkoopste manier om de duurste fout - een fout die zes weken doorwerkt in de administratie - te vermijden.
3. Wat leg je vast in het CMDB en het modelregister, en waarom op twee plaatsen?
Read the worked answer
De twee registers dienen verschillende vragen en hebben daarom een verschillende eigenaar.
CMDB (FB): de applicatie, de interface naar het ERP, de modelversie die in productie is, de configuratie, en de koppeling met de change-records en de rollback-procedure. Dit is wat FB nodig heeft om een incident te kunnen diagnosticeren: welke versie draaide op 14 maart om 09:00?
Modelregister (proceseigenaar plus Data & Analytics): doel van het model, gebruikte variabelen, trainingsdata en periode, acceptatiecriteria, testresultaten per release, bekende beperkingen, eigenaar en de beoordeling op risico's zoals bias. Dit is wat nodig is om te verantwoorden waarom het model doet wat het doet.
Waarom niet één register: de CMDB is ingericht op configuratie-items en wijzigingen, niet op prestatiemetingen en datagrondslagen; het modelregister is een verantwoordingsdocument dat ook buiten IT wordt gelezen, bijvoorbeeld door de accountant of de FG. Ze moeten wel naar elkaar verwijzen via één unieke modelsleutel, anders ontstaat precies de situatie die hier optrad: een versie is terug te vinden, maar niemand weet meer welke prestatie daarbij hoorde.