Het beschrijvingsveld bij je measure: vier zinnen die je cijfer navertelbaar maken

Ilse is manager klantenservice bij een producent van keukenapparatuur en bouwde het leverdashboard zelf. Vlak voor een overleg vraagt haar accountmanager of de 94,2 procent leverbetrouwbaarheid ook de orders meetelt die nog onderweg zijn. Ze opent haar eigen formule en vindt het antwoord daar niet, terwijl ze die formule prima kan lezen. Power BI vult bij een measure alles in behalve de betekenis, en er is precies één plek in het model waar die betekenis wel kan staan.

Wat een measure allemaal draagt, en wat niet

Een measure is meer dan de formule die erin staat. Power BI vult drie dingen automatisch in zodra je hem aanmaakt: een naam die in elk visual verschijnt, een formule die het rekenwerk doet, en een opmaak die bepaalt hoe de uitkomst wordt getoond. Daarnaast krijgt elke measure een beschrijvingsveld, en dat veld is het enige van de vier dat Power BI leeg laat tot iemand erin typt. Wat je daar neerzet reist met je model mee: een collega ziet het terug in het veldenpaneel, en het staat in TMDL, de leesbare tekstvorm waarin een PBIP-map je tabellen en measures bewaart. Zolang dat veld leeg blijft, staat de afspraak achter een cijfer nergens vastgelegd, en moet iedereen die het cijfer wil navertellen bij de maker aankloppen.

De measure van Ilse

In haar model staat Leverbetrouwbaarheid % = DIVIDE ( [Orders op tijd], [Geleverde orders] ), de functie die bij een lege noemer BLANK teruggeeft in plaats van een fout. Die twee namen tussen haken zijn zelf tellingen in het model. Over het kwartaal staat de noemer op 1.842 geleverde orders en de teller op 1.735, dus het rapport toont 94,2 procent. De formule vertelt precies wat ze zegt: een aandeel van de geleverde orders. Waarover ze zwijgt is welke orders als op tijd meetellen, en in de telling van Ilse gelden de 63 orders die nog onderweg zijn als op tijd. Die afspraak staat nergens in de code.

Als de teldatum verschuift

Verander één ding: laat [Orders op tijd] tellen op de datum waarop een order daadwerkelijk is afgeleverd, in plaats van de datum waarop hij werd verwacht. De 63 orders die nog onderweg waren, vallen dan af, er blijven 1.672 over, en dezelfde formule toont nu 90,8 procent. De regel code is niet veranderd, want hij wijst naar [Orders op tijd] en niet naar de afspraak die eronder ligt: telt een order mee zodra hij onderweg is, of pas zodra hij is afgeleverd? Twee uitkomsten, allebei te verdedigen, en het verschil zit volledig in een afspraak die buiten de code is gemaakt.

Wat je morgen opschrijft

De vraag die telt is niet of je formule klopt, maar of iemand anders over een half jaar uit je model kan halen wat je cijfer telt, zonder jou te bellen. Het beschrijvingsveld legt vast welke van de twee afspraken in dit model geldt; welke afspraak de juiste is blijft een gesprek tussen klantenservice en productie. Pak morgen het cijfer waar jouw klant je op afrekent en schrijf bij die measure vier dingen op: wat meetelt, welke datum telt, welke uitzondering er is, en wie erover beslist. Die vier zinnen blijven staan als een collega het cijfer over een half jaar weer tegenkomt, en ze reizen ook mee naar een Data Agent die je model bevraagt: die neemt veldbeschrijvingen mee als grondingsdata voor zijn antwoord.

Wil je die vier zinnen samen met je team doorlopen voor een rapport waar dit al langer speelt? Ik denk graag mee, kijk op trainerbjorn.nl.