Je measures komen leeg terug, en het ligt aan je kalender
Een klassieke fout in datamodellen: je datumtabel loopt verder dan je gegevens. Wat er dan misgaat en hoe je het oplost.
Je bouwt een berekening die kijkt naar de laatste datum in je model. De omzet van de laatste maand, de stand van vandaag, de vergelijking met dezelfde periode vorig jaar.
En je krijgt niets terug. Geen foutmelding, geen nul. Gewoon leeg.
Dan ga je twijfelen aan je formule, terwijl die waarschijnlijk klopt.
Waar het aan ligt
In elk fatsoenlijk datamodel zit een aparte kalendertabel: een tabel met alle dagen erin, waaraan je je feiten koppelt. Dat is goede praktijk en je hebt ze nodig om betrouwbaar met periodes te kunnen rekenen.
Die kalender wordt bijna altijd ruimer gemaakt dan de gegevens. Van enkele jaren terug tot enkele jaren vooruit, zodat je ze nooit meer moet aanpassen. Volkomen redelijk.
Maar dan schrijf je een berekening die zoekt naar de laatste datum in de kalender. Die vindt hij netjes, en dat is een datum ver in de toekomst. Op die datum staat geen enkele factuur. Dus je berekening kijkt naar een periode waar niets in zit en geeft leeg terug.
Ik heb dat zelf gehad in een model waar de kalender jaren verder liep dan de facturen. Alles klopte, alleen kwam elke berekening die op de laatste datum ankerde leeg terug.
De oplossing
Anker niet op de laatste datum van je kalender, maar op de laatste datum waarvoor je gegevens hebt.
Praktisch betekent dat: bepaal eerst het maximum van de datum in je feitentabel, niet in je kalender. Dat ene onderscheid lost het grootste deel van deze categorie fouten op.
Een tweede, nog eenvoudiger aanpak: zet een vlag in je kalender die aangeeft of een dag in het verleden ligt ten opzichte van je gegevens. Dan kan je alles wat in de toekomst ligt in één keer wegfilteren, in elk rapport, zonder elke berekening apart te moeten aanpassen.
Welke van de twee je kiest hangt af van je model. Het punt is dat je bewust kiest, in plaats van te veronderstellen dat je kalender en je gegevens even ver lopen.
De variant die erger is
Er is een stillere versie van dit probleem, en die kost meer.
Stel dat je kalender wel ophoudt bij vandaag, maar je gegevens lopen tot halverwege deze maand omdat de rest nog niet verwerkt is. Dan is je laatste maand onvolledig, en je gemiddelde per maand wordt naar beneden getrokken door een maand die nog niet af is.
Dat geeft geen lege uitkomst. Dat geeft een uitkomst die er redelijk uitziet en die fout is. Iedereen kijkt ernaar en niemand merkt het.
De verdediging daartegen is expliciet zijn over volledigheid. Markeer in je model welke periodes afgesloten zijn, en laat berekeningen die over gemiddelden of trends gaan alleen op die periodes rekenen. De lopende periode toon je apart, met het label erbij dat ze nog loopt.
Hoe je dit vroeg vindt
Twee controles die je bij elk model opzet en die tien minuten kosten.
Zet ergens zichtbaar wat de vroegste en de laatste datum in je feiten is. Niet in je kalender, in je feiten. Als dat afwijkt van wat je verwacht, weet je het meteen.
En tel het aantal rijen per maand over de laatste twaalf maanden. Een maand die er uitspringt naar boven of naar beneden is ofwel een echt verhaal ofwel een verwerkingsprobleem, en allebei wil je het weten.
De stelling
Als een berekening leeg terugkomt, verdenk je je formule. Kijk eerst naar je kalender. In de meeste modellen loopt die verder dan de werkelijkheid, en dan rekent een correcte formule over een periode waar niets gebeurd is.