Als een forecast niet klopt, is de reflex om het model aan te passen. Het gaat snel, het voelt als problemen oplossen, en meestal werkt het een tijdje.
Het is ook de manier waarop een planningssysteem stilletjes ophoudt betrouwbaar te zijn. Adaptive Planning-modellen aanpassen om problemen in de brondata te compenseren, lost die problemen niet op. Het codeert ze, en het verwijdert het bewijs dat ze er ooit waren.
Dat is al jaren een beheersbaar risico. Het houdt op beheersbaar te zijn op het moment dat je er AI bovenop zet, en om een reden die de meeste teams niet zien aankomen.
Waarom teams het doen
Niemand begint bewust aan het bouwen van een planningsmodel op onbetrouwbare data. De beslissing wordt meestal genomen onder druk, laat in een Deployment, en om redenen die op dat moment volkomen begrijpelijk zijn.
Data repareren in het bronsysteem betekent onderzoek, root cause-analyse en vaak opnieuw invoerwerk. Weken voor de Go-live voelt dat als een herstart van het project. Het model aanpassen kost een middag.
Er is ook een eigenaarschapsprobleem. Als de kwestie in het bronsysteem zit, hoort die bij iemand anders. Werk eromheen in Adaptive en het eigenaarschap wordt vaag, wat op korte termijn voor iedereen comfortabeler is.
En modelaanpassingen zijn onzichtbaar op een manier die datacorrecties niet zijn. Niemand aan de businesskant ziet de workaround. Ze zien forecasts die aansluiten.
Dus de workaround wordt ingevoerd. Het werkt. Het project gaat live. Wat daarna gebeurt, is het deel dat het waard is om te begrijpen.
Wat er werkelijk breekt
Forecasts drijven af van de werkelijkheid. Wanneer een model een dataprobleem compenseert, verbetert de forecast ten opzichte van de eigen aannames van het model en wijkt af van de business. Werkelijke uitgaven blijven de echte data volgen. De forecast blijft de aanpassing volgen. De kloof wordt groter, en omdat de aanpassing niet zichtbaar is, wordt hij elke cyclus moeilijker uit te leggen.
Variantieanalyse houdt op nuttig te zijn. Planning is iteratief: forecasten, vergelijken met werkelijke cijfers, de variantie vinden, aanpassen. Als de forecast op een workaround rust in plaats van op betrouwbare data, kun je niet vaststellen of je het plan miste omdat een aanname verkeerd was of omdat het model iets in de data compenseerde. Elke cyclus begint met onzekerheid die niemand heeft gekwantificeerd.
De redenering vertrekt met de persoon. Dit is degene die teams verrast.
Na een Workday Financials-Deployment en een verzoek om Adaptive bij te werken, ontdekten we een probleem in de kostenplaatsmapping. De structuur in Financials was aanvankelijk verkeerd, dus tijdens de integratie werd een correctie in SQL toegepast. Financials werd daarna correct hersteld en geherstructureerd. De SQL bleef de oude logica volgen.
Niets faalde. Er werd geen foutmelding gegeven. De mapping was nooit gedocumenteerd, en de afwijking werd pas zes maanden later opgemerkt, tijdens een systeemreview en een grondige reconciliatie van Workday- naar Adaptive-data.
Er waren zes maanden aan forecasts uit voortgekomen. Ze zagen er prima uit.
Die specifieke correctieroute was specifiek voor hoe de integratie was gebouwd. Het patroon niet. Een workaround wordt toegepast omdat het de snelste weg is, hij wordt niet gedocumenteerd omdat hij tijdelijk bedoeld is, en de persoon die hem begreep vertrekt.
Hoe dit eruitziet binnen Adaptive
De reden dat deze problemen maanden overleven in plaats van dagen is het begrijpen waard, want die is specifiek voor hoe Adaptive omgaat met data die het niet herkent.
Adaptive weigert geen waarden die het niet kan plaatsen. Afhankelijk van de hiërarchie belanden onbekende waarden in een niet-gecategoriseerde bak. Dat is het detail dat telt: een onvolledige hiërarchie levert geen duidelijke fout op, maar een aannemelijk getal. De totalen kloppen bovenaan nog steeds. Rapportage en analyse worden beïnvloed afhankelijk van je systeeminstellingen, maar niets kondigt zichzelf aan.
De workarounds gedragen zich op dezelfde manier. Niet-geïdentificeerde kostenplaatsen mappen naar andere niveaus lost een reconciliatieprobleem op korte termijn op tussen Financials-werkelijke cijfers en Adaptive. Als het blijft staan, verstoort het varianties verderop terwijl het overzicht correct blijft ogen. Hardgecodeerde waarden en dimensies die binnen formules staan, waar ze aan duidelijk gedefinieerde aannames gekoppeld zouden moeten zijn, zijn niet anders. Ze werken, en dan houden ze op zichtbaar te zijn.
Reconciliatie is de controle, en in de praktijk is die zwakker dan de meeste teams aannemen. In een ideale Deployment zou je die niet nodig hebben. Omdat er workarounds op kostenplaatsstructuren bestaan, is de realistische positie dat Adaptive-output elke maand wordt gereconcilieerd met een Workday Financials-rapport. Dat kost tijd, en het niveau waarop je het doet bepaalt of het überhaupt de moeite waard is. Reconcilieer te hoog en het klopt, wat je niets vertelt. Verkeerd gemapte dimensies komen niet naar voren in een totaal. Ze komen eronder naar voren.
Waarom AI dit tot een blootstelling maakt
Dit is wat er verandert.
Iemand die een variantierapport leest, werkt van boven naar beneden. Eerst de totalen, dan de regels die bewogen. Een samenvatting die klopt lijkt op een systeem dat werkt.
AI leest het niet zo. Vraag het om te forecasten of variantieanalyse uit te voeren en het werkt op het meest granulaire niveau dat beschikbaar is. Als een dimensie niet-gecategoriseerd is, of een kostenplaats naar de verkeerde locatie is gemapt, bevat de forecast die het produceert niet alle data. Het leest niet de samenvatting die aansluit. Het leest het detail dat dat niet doet.
Dus het probleem keert om. Bij een traditioneel model komen dataproblemen uiteindelijk naar boven in variantieanalyse, omdat iemand ernaar zoekt. Bij een AI-model zitten dezelfde problemen bovenstrooms van een proces dat geen reden heeft ze te signaleren, en de output oogt geavanceerder in plaats van minder.
Dat is van belang vanwege wie het uiteindelijk moet verdedigen. Het model produceert een forecast. Finance presenteert die. Een kwartaal later is die verkeerd, de raad vraagt waarom, en het eerlijke antwoord is dat niemand zeker weet waarvan het model heeft geleerd. De AI faalde niet. De data wel. Finance blijft hoe dan ook met het geloofwaardigheidsprobleem zitten.
Het verschil tussen een AI-forecast die een CFO kan presenteren en een die dat niet kan is niet het model. Het is of het antwoord op "waar komt dit vandaan?" een zin is of een schouderophalen.
"Het heeft geleerd van drie jaar geauditeerde transactiedata, geanalyseerd per kostenplaats en uitgavencategorie, en het volgt de werkelijke cijfers binnen de tolerantie die we hebben afgesproken." Dat is verdedigbaar.
"Het heeft geleerd van data waarvan we wisten dat er gaten in zaten, waarvan we sommige in de planningslaag corrigeerden, en we weten niet zeker wat het heeft opgepikt." Hetzelfde model. Het valt niet te verdedigen.
Data-integriteit eerst
Adaptive Planning steunt op drie lagen, in deze volgorde: betrouwbare brondata, heldere datagovernance, en modellen die op die data zijn gebouwd in plaats van ervoor te compenseren. Sla de eerste twee over en de derde faalt uiteindelijk.
In de praktijk betekent dat een paar dingen.
Audit het bronsysteem voordat je iets configureert. Zijn de hiërarchieën compleet? Zijn de kostenplaatstoewijzingen consistent? Kloppen de saldi op elk niveau, niet alleen bovenaan? Documenteer de baseline, zodat je later kunt vaststellen of de kwaliteit verbetert of afdrijft.
Definieer eigenaarschap zolang het nog goedkoop is. Wie het rekeningschema onderhoudt. Wanneer kostenplaatsen worden aangemaakt. Wat een nieuwe dimensie valideert. Deze vragen zijn triviaal vóór de Go-live en duur erna.
Bepaal wat een aanvaardbare variantie werkelijk is. Er is hier geen branchecijfer, en wie je er een aanbiedt, gokt. Wat als een redelijke kloof tussen werkelijke cijfers en forecast telt, is een oordeel van de systeemeigenaar, en het hangt af van de business. Maak het expliciet, leg het vast, en reconcilieer ertegen.
Reconcilieer op een niveau laag genoeg om iets te vinden. Maandelijks, modeloutput tegen brondata, en als er een variantie is, onderzoek die in plaats van hem te absorberen. Los dataproblemen eerst op in het bronsysteem, pas dan het model aan als het nog steeds aanpassing nodig heeft.
Als je AI toevoegt, voer die audit uit voordat je begint, niet nadat de eerste forecast teleurstelt. AI versterkt datadrift, dus validatie moet doorlopend zijn in plaats van een eenmalige oefening aan het begin. En als je halverwege een AI-initiatief kwaliteitsproblemen vindt, stop dan en repareer de data. Er is geen configuratie die maakt dat een model eromheen werkt.
Twee vragen die het waard zijn om je team te stellen
Kun je elke aanname in je Adaptive Planning-model verklaren door te wijzen op betrouwbare data in het bronsysteem? Als het antwoord "niet helemaal" is, dan is dat een dataprobleem in plaats van een planningsprobleem, en geen modelaanpassing zal het oplossen.
En als je vandaag een AI-forecast op je huidige data zou bouwen, zou je die dan aan de raad kunnen verdedigen door hem terug te traceren naar de bron? Als het antwoord is "we zouden de data eerst willen opschonen," dan is dat het juiste antwoord. Het is ook een veel goedkoper gesprek om nu te voeren dan na de investering.
Michael Trussell is Workday Adaptive Planning Architect bij VirtualResource, waar we met finance- en HR-teams werken aan Workday-Deployments, doorlopende Adaptive Planning-Optimalisatie en AI-enablement. Als je een van beide overweegt, begint het gesprek meestal met een blik op waar de data zich werkelijk bevindt.