Uw Power BI-model wordt onbeheersbaar: de signalen die u niet mag negeren

Zo’n model begon zelden slecht. Het startte klein en juist: een paar tabellen uit het ERP, een handvol measures, één rapport waar de directie blij van werd. Toen kwamen de vragen. Kan dat ook per vestiging? Kan budget erbij? Kan de marge zoals de vorige controller ze berekende? Elke vraag kreeg een antwoord, en elk antwoord liet iets achter in het model. Wie zelf bouwt, merkt die kanteling het laatst. Daarom hieronder de signalen zoals ze in de praktijk voorkomen. Per signaal leest u waarom het ernstiger is dan het lijkt, en welke ontwerpkeuze het herstelt.

Signaal 1: niemand durft nog een measure te verwijderen

Het model telt intussen honderden measures, waarvan een deel “test”, “kopie van” of “v2 finaal” heet. Niemand weet welke nog ergens gebruikt worden, dus blijft alles staan. Veiligheidshalve.

Dit lijkt onschuldig. Maar het betekent dat het model groter is geworden dan het begrip ervan. Vanaf dat punt gebeurt elke wijziging defensief. Iedereen voegt liever iets nieuws toe dan iets bestaands aan te passen. Zo versnelt de groei juist, en wordt het model elke maand minder overzichtelijk.

Maak afhankelijkheden zichtbaar, in plaats van te gokken. Externe hulpmiddelen zoals Tabular Editor 2, Measure Killer en DAX Studio tonen wat er in uw model zit en wat nergens gebruikt wordt. Verwijderen wordt zo een feitelijke beslissing. Verwijder in stappen en controleer na elke stap of de rapporten nog kloppen. Leg daarnaast een eenvoudige conventie vast. Elke measure krijgt een duidelijke naam, een logische plaats in een map en een omschrijving van één zin. Zonder naam en omschrijving legt een measure zichzelf niet meer uit.

Signaal 2: elke nieuwe vraag eindigt in een nieuwe tabel of een work-around

De vraag “kan dat ook per productgroep?” leidt tot een extra tabel die ertegenaan geplakt wordt. Een afwijkende klantindeling wordt een gekoppelde Excel. Een uitzondering voor één vestiging wordt hard gecodeerd in een measure. Elke oplossing werkt op zich. Samen maken ze het model elke keer een stuk moeilijker.

Wat u dan ziet, is een model zonder werkbare structuur. Daar zijn twee versies van. Ofwel is er nooit een sterschema geweest en kwamen de tabellen uit het ERP zoals ze daar stonden, met relaties kriskras door elkaar. Ofwel was er wel een sterschema, en is het stap voor stap tenietgedaan door wat erbij gebouwd werd, bijvoorbeeld een tabel die aan een andere tabel hangt in plaats van aan een feit of een dimensie.

Herstel begint dus bij een sterschema, waarin u scheidt wat u meet van waarmee u kijkt. Die structuur is de helft van het werk. De andere helft is wat u er daarna mee doet. Elke nieuwe vraag krijgt een plaats binnen die structuur. Meet u iets nieuws, dan hoort het in een feitentabel, op het detailniveau waarop het gemeten wordt. Kijkt u op een nieuwe manier naar iets wat u al meet, dan hoort het als kolom in een bestaande dimensie. Past het in geen van beide, dan is dat een gesprek waard voor u begint te bouwen.

Signaal 3: de refresh wordt trager en valt af en toe om

Het verversen van de gegevens duurde ooit enkele minuten, nu drie kwartier. Af en toe mislukt het, meestal op een ongelukkig moment. De work-around is voorspelbaar: minder vaak verversen, of ’s nachts draaien en hopen.

Een trage refresh is zelden een capaciteitsprobleem. Meestal laadt het model elke keer meer dan het nodig heeft: kolommen die niemand gebruikt, transformaties die in de bron thuishoren, tabellen die er ooit voor de zekerheid bijkwamen. De gevolgen zijn niet technisch maar zakelijk. Faalt de refresh op de ochtend van de managementvergadering, dan ondermijnt dat rechtstreeks het vertrouwen in de cijfers.

Herstel begint bij minder laden, niet sneller laden. Laad alleen de kolommen en tabellen die het model echt nodig heeft. Zet logica zo dicht mogelijk bij de bron. Werk met smalle tabellen. Voor modellen die echt groot worden, bestaat incremental refresh: alleen nieuwe gegevens worden dan ververst. Maar dat is de stap na het opruimen, niet in de plaats ervan.

Signaal 4: totalen verschillen tussen pagina’s

De marge op pagina één wijkt licht af van de marge op pagina drie. Het verkooprapport spreekt het managementrapport tegen. De verklaring klinkt vertrouwd: “die pagina berekent het iets anders”.

Dat is geen schoonheidsfout. Het betekent dat hetzelfde begrip op meerdere plaatsen gedefinieerd is. Twee omzet-measures, een berekende kolom hier, een filter in de visual daar. Zodra de directie dit opmerkt, verschuift elke bespreking van de beslissing naar de cijfers zelf. De directie wantrouwt het rapport eerst, en negeert het daarna. Dat is het duurste wat een rapport kan overkomen.

Los dit op met één definitie per begrip, op één plaats. Elk kerncijfer krijgt één basismeasure. Elke variant, cumulatief, vorig jaar, per segment, bouwt daarop voort in plaats van een eigen versie te krijgen. Verandert de definitie van marge, dan verandert ze overal tegelijk. Berekeningen die verstopt zitten in visuals of losse kolommen, verhuizen naar measures. Daar zijn ze zichtbaar en controleerbaar.

Signaal 5: de documentatie zit in het hoofd van de bouwer

Nergens staat beschreven waarom een tabel bestaat, waarom een measure een vreemde uitzondering bevat of welke bron leidend is wanneer twee systemen elkaar tegenspreken. De uitleg is mondeling, op aanvraag, bij één persoon.

Zolang die persoon er is, lijkt er geen probleem. Maar onbeschreven keuzes worden na een jaar ook voor de bouwer zelf een raadsel. Ze blokkeren elke vorm van hulp. Een collega of een externe reviewer moet eerst alles zelf uitzoeken voor die iets kan verbeteren. Documentatie is hier geen administratie. Het is de voorwaarde om ooit nog iemand te laten meewerken.

Documenteer in het model zelf, niet in een apart document dat veroudert. Power BI laat toe om elke tabel, kolom en measure een omschrijving te geven. Die verschijnt waar ze gebruikt wordt. Niet alles hoeft beschreven. De afspraak dat elk kerncijfer een definitie heeft en elke afwijking een reden, volstaat om het model overdraagbaar te houden.

Signaal 6: alles passeert via één persoon

Aanpassingen, nieuwe vragen en fouten komen allemaal bij dezelfde collega terecht. Is die op verlof, dan kan er niets gewijzigd of hersteld worden.

Dit is het signaal waarin de vorige vijf samenkomen. Het is ook het enige dat de directietafel rechtstreeks aanbelangt. In softwaretermen heet dit een bus factor van één. Het aantal mensen dat mag wegvallen voor het stilvalt, is één. Vertrekt die persoon, of valt die langdurig uit, dan stopt niet alleen het onderhoud. Ook het vermogen van het bedrijf om zijn eigen cijfers te begrijpen valt dan stil. Wie ooit een overname of due diligence meemaakte, weet dat kopers hier expliciet naar vragen. Kritieke afhankelijkheid van één persoon drukt de waardering.

Hier is de ontwerpkeuze organisatorisch, niet technisch. Zorg dat het model leesbaar wordt voor een tweede paar ogen. Dat begint bij de structuur van signaal twee en de definities van signaal vier en vijf. Voeg daar een terugkerend reviewmoment aan toe, met een collega of een externe expert. De echte test is eenvoudig: kan een buitenstaander het model in een paar uur volgen? Zolang het antwoord nee is, loopt de rapportering elke maand risico.

Herstructureren kan meestal zonder te herbouwen

Herkent u drie of meer signalen, dan is de reflex vaak: alles weggooien en opnieuw beginnen. Dat is zelden nodig. In de meeste gegroeide modellen klopt de businesslogica grotendeels. Het is de structuur die niet is meegegroeid. De volgorde van herstel is dan: eerst meten wat er echt gebruikt wordt, dan de basisstructuur rechttrekken, dan de definities centraliseren, en pas daarna verfraaien. Dat kan stapsgewijs, naast de bestaande rapporten, zonder dat de maandrapportering stilvalt.

De grootste fout is een andere. Nog een jaar work-arounds stapelen, omdat opruimen nooit dringend voelt. Tot het dat plots wel is, op het moment dat u het minst kunt kiezen.

Veelgestelde vragen

Hoeveel tabellen mag een Power BI-model bevatten?

Er bestaat geen vast maximum. De structuur telt, niet het aantal. Een model met vijftien tabellen in een helder sterschema is beter beheersbaar dan een model met tien tabellen en kriskras relaties. Het bruikbare criterium: kan iemand anders in enkele uren volgen hoe het model in elkaar zit?

Moet ik een organisch gegroeid model herbouwen of kan ik het herstructureren?

Meestal volstaat herstructureren. De businesslogica klopt vaak grotendeels, alleen de structuur niet. Werk stapsgewijs: dood gewicht verwijderen, feiten en dimensies scheiden, definities centraliseren. Volledige herbouw is pas nodig wanneer het fundament, zoals de bronkoppelingen of het detailniveau van de gegevens, niet meer te redden valt.

Hoe beperk ik het risico dat alle Power BI-kennis bij één persoon zit?

Maak het model leesbaar voor een tweede paar ogen: een herkenbare structuur, omschrijvingen in het model zelf en consequente naamgeving. Plan daarnaast geregeld een review door een collega of een externe expert. De test is simpel: kan iemand anders een aanpassing doen zonder de bouwer te moeten bellen?

Volgende stap

Herkent u drie of meer van deze signalen, dan loont een tweede paar ogen, voor er iets breekt of iemand vertrekt. Beyond KPI licht bestaande Power BI-modellen door: waar zit het risico, wat is gericht te herstellen en wat verdient herbouw? U krijgt een concreet beeld van waar u staat en wat de eerstvolgende stappen zijn.

Plan een vrijblijvend gesprek, en vraag daarin gerust naar een review van uw model, een technische second opinion of sparring over hoe u het beheersbaar houdt.

Dennis Houthoofd, oprichter Beyond KPI. 25+ jaar ervaring in finance, data en AI voor Vlaamse KMO's. Meer over Dennis.