Waarom je dataproject staat of valt met je testdataset
Je dashboard is getest. De cijfers kloppen. Je organisatie gaat ermee werken. Maar na een paar weken blijken sommige resultaten onjuist. Niet omdat het dashboard niet werkt, maar omdat er bij het testen belangrijke uitzonderingen zijn vergeten.
Het gevolg? Extra herstelwerk, verkeerde beslissingen en medewerkers die het vertrouwen in de cijfers verliezen.
Het probleem zit hem dan niet in de gebouwde dashboards maar in de data waarop deze dashboards zijn gebouwd.
Leestijd: 10 minuten
Het model klopte, tot de echte data erbij kwam
Het dashboard ziet er goed uit. De berekeningen kloppen, de testgegevens laten precies zien wat je verwacht en de klant is tevreden over de testversie. Dan wordt de volledige dataset ingeladen. Ineens kloppen de totalen niet meer. Sommige regels vallen buiten elke categorie, andere worden dubbel geteld en een paar measures, de berekeningen achter de rapportages, geven uitkomsten die niemand kan verklaren.
Er is niets kapot. Het model doet precies wat het moet doen, met de gegevens waarvoor het gebouwd is. En dat waren niet alle combinaties van gegevens die er in de praktijk bestaan.
Het probleem zat niet in het model. Het zat in de testdataset.
“Het belang van een goed gekozen testdataset wordt pas duidelijk wanneer er een verkeerde keuze is gemaakt.”
Wat een testdataset eigenlijk moet zijn
Wanneer je een dataset of datamodel ontwikkelt, werk je bijna nooit direct met alle gegevens. Je bouwt eerst op een kleinere set, de testdataset. Dat is logisch. Een kleinere set is overzichtelijk, laadt snel en maakt het makkelijker om fouten te vinden.
Maar een goede testdataset is meer dan een willekeurig handje records. Hij bevat idealiter alle varianten die je in de praktijk tegenkomt, dus elke standaard werkwijze en elke uitzondering daarop. Denk aan een order die in delen wordt geleverd, een product dat zowel per stuk als per doos wordt verkocht of een klant met afwijkende afspraken. Zolang zulke gevallen niet in je testdataset zitten, weet je model niet dat ze bestaan. En wat je model niet kent, kan het ook niet goed verwerken.
Waarom de testdataset zo vaak onvolledig is
Dat een testdataset gaten bevat, komt zelden door slordigheid. Meestal ontstaat het op een heel begrijpelijke manier.
Je stelt de set samen in overleg met de eindgebruiker. In de praktijk zit je dan vaak met managers en procesverantwoordelijken aan tafel. Zij kennen het proces op hoofdlijnen goed en weten welke werkwijze de standaard is. Wat ze niet altijd weten, is welke varianten er in de loop der jaren op de werkvloer zijn ontstaan.
Een medewerker die een order net anders boekt omdat het systeem anders niet meewerkt. Een afdeling die een eigen code gebruikt voor een situatie die officieel niet voorkomt. Die kennis zit in de hoofden van de mensen die het werk elke dag doen, en komt in een gesprek met het management zelden vanzelf boven.
Daar komt bij dat processen veranderen terwijl de afspraken op papier hetzelfde blijven. Wat ooit een uitzondering was, is inmiddels gewoon een tweede standaard geworden. Niemand heeft dat bewust besloten, het is gegroeid. De eerste gesprekken waren grondig, de klant werkte goed mee en toch ontbraken er varianten in de testversie. Niet omdat iemand iets achterhield, maar omdat de mensen aan tafel simpelweg niet wisten dat ze bestonden.
Wat een onvolledige testdataset je kost
De zichtbare kosten zijn het eerst duidelijk. Zodra de volledige dataset binnenkomt, moet je terug. Measures moeten worden herschreven, relaties aangepast en logica uitgebreid voor gevallen die er eerst niet waren. Dat zijn extra uren, op een moment dat het project eigenlijk al bijna klaar leek.
Bij een middelgroot bedrijf waar ik een datamodel bouwde, gebeurde precies dit. De testdataset was samen met de klant opgesteld en leek compleet. Na het omzetten naar de volledige set bleken er meer standaarden te bestaan dan in de testdataset zaten. Een groot deel van de measures moest daarna opnieuw worden aangepast. Dat kostte tijd die met een grondigere voorbereiding niet nodig was geweest.
Minder zichtbaar is wat er gebeurt met de betrouwbaarheid. Ontbrekende varianten leiden niet altijd tot foutmeldingen. Vaak belanden ze stilletjes in een verkeerde categorie of vallen ze buiten een filter. Je krijgt dan cijfers die er correct uitzien, maar het niet zijn. Op basis daarvan worden beslissingen genomen. Dat is gevaarlijker dan een model dat zichtbaar vastloopt.
Ten slotte is er het vertrouwen. Een dashboard dat na oplevering nog een paar keer moet worden gerepareerd, wordt met andere ogen bekeken. Gebruikers gaan cijfers zelf narekenen in een spreadsheet, naast het model dat juist bedoeld was om dat overbodig te maken. En elke pleister die je achteraf plakt, maakt het model complexer en lastiger te onderhouden.
"Liever vooraf nadenken dan achteraf pleisters plakken"
Hoe je ziet of je testdataset tekortschiet
Er zijn een aantal vragen die je jezelf kunt stellen om te controleren of je testdataset te kort schiet.
- Is de set samengesteld op basis van gesprekken met alleen het management? Dan is de kans groot dat varianten van de werkvloer ontbreken.
- Bevat de set vooral nette records? Echte data bevat lege velden, afwijkende codes, correcties en tegenboekingen. Als je testdataset daar niets van laat zien, is hij waarschijnlijk te schoon.
- Weet je per veld welke waarden er in de volledige bron voorkomen? Een simpele telling van unieke waarden in de bron, naast dezelfde telling in je testdataset, laat snel zien wat je mist.
- Weet je hoe vaak een uitzondering voorkomt? Een variant die maar een paar keer per jaar voorbijkomt, kan toch een flinke invloed hebben op een totaal of gemiddelde.
Het effect dat je niet verwacht
Een goede testdataset levert meer op dan een stabieler model. Doordat de klant vooraf moet nadenken over alle standaarden en uitzonderingen, wordt zichtbaar hoeveel varianten er eigenlijk zijn. Voor veel organisaties is dat een eyeopener. Niet zelden besluit een klant op dat moment het proces zelf aan te passen. Waarom zijn er vijf manieren om een retour te verwerken als er een zou volstaan? Door het proces te vereenvoudigen, wordt niet alleen het datamodel eenvoudiger, maar ook het werk zelf.
Daarnaast legt het ook iets bloot wat minstens zo waardevol is, namelijk het verschil in kennis tussen de werkvloer en het management. Dat is soms ongemakkelijk. Maar een organisatie die weet waar haar kennis zit, kan er beter mee omgaan dan een organisatie die denkt dat iedereen hetzelfde beeld heeft.
Klaar om data écht voor je te laten werken?
Een datamodel is nooit beter dan de gegevens waarop het is gebouwd. Een testdataset die alleen de standaard laat zien, levert een model op dat alleen de standaard aankan. Je kunt de tijd vooraf investeren of achteraf. Vooraf is het een gesprek en een analyse.
Achteraf is het herstelwerk, onder tijdsdruk en met een gebruiker die al aan de cijfers is gaan twijfelen.
Kijk bij projecten eens kritisch naar je testdataset en vraag je af wie er niet aan tafel zat toen hij werd samengesteld. Grote kans dat daar de uitzonderingen zitten die je nog mist.
Door onze ervaringen kunnen wij klanten hier ook voorzien in een goede testdataset.
Meer kennis van Techspread!
Lees meer blogs met praktische tips, slimme strategieën en actuele ontwikkelingen rondom data.
De nieuwe data-analist: hoe AI de rol van analytics fundamenteel verandert
- AI | Business Intelligence | Data-analyse
De illusie van inzicht: standaardrapportages onder de loep
- Business Intelligence | Data-analyse
Efficiëntie op volle kracht: hoe GitHub onze workflow versnelt
- Data engineering | Optimalisatie
Van polis tot potentie: inzicht dat klantwaarde vergroot
- Business Intelligence | Data-analyse
De ambitie om een datagedreven organisatie te worden? Tijd voor een bakkie pleur!
Een eerste gesprek begint bij wat er speelt binnen je organisatie. Misschien loop je tegen een concreet datavraagstuk aan, wil je meer met AI doen of ben je vooral benieuwd wat er mogelijk is. Tijdens een kennismaking brengen we samen de situatie in kaart en kijken we waar kansen liggen.
Wij denken met je mee, stellen kritische vragen en geven concreet advies. Geen eindeloze rapporten, maar concreet advies en praktische stappen waar je direct mee aan de slag kunt.