Je dashboard lijkt te kloppen. Is dat ook zo?

Ergens in je dashboard staat een getal dat niemand heeft gecontroleerd aan de hand van het totaal waaruit het afkomstig is. Bij mij stond het in een eigen project over 120 jaar aan klimgegevens uit de Himalaya. Het liet zien dat ingehuurd personeel bijna twee keer zo vaak de top bereikt als klimmende expeditieleden. Na correct tellen verdween het verschil vrijwel. Zo kon dat gebeuren, en zo vind je jouw eigen variant ervan.

Het getal dat niet klopte

Voor we op pad gaan

Het klonk overtuigend, het stond op het scherm en het was fout.

Bij Bitmetric werken velen van ons naast klantwerk aan een eigen dataproject. Zo houden we onszelf scherp: we proberen nieuwe technieken uit op data die onze nieuwsgierigheid wekken. Deze keer experimenteerde ik met een Python-pipeline, versiebeheer voor het model en de Key Influencers-visual van Power BI.

De dataset: de Himalayan Database, met 120 jaar aan expedities van 1905 tot 2025. Achter elke rij zit een echt persoon, en niet iedereen kwam thuis.

In dit artikel volgen we de kop over sherpa’s van begin tot eind: hoe die op mijn scherm belandde, hoe ik de fout ontdekte en hoe je hetzelfde soort fout in je eigen dashboard kunt vinden. Aan het einde vind je vijf vragen om te toetsen of je cijfers te vertrouwen zijn.

Basiskamp: begrijp de data en bereid ze voor

Elke expeditie begint met voorbereiding: eerst begrijpen, dan pas aanpakken.

Elk project van Bitmetric doorloopt dezelfde zes stappen, in dezelfde volgorde:

De data uit de Himalaya zijn ongebruikelijk. De aanpak niet.

Stap 1: de vraag.

Je plant een expeditie. Welke bergtop, welk seizoen en met of zonder zuurstof?

Stap 2: verkennen.

De data: 11,690 expedities op 490 bergtoppen, met een Python-script in SharePoint geladen en door Power Query opgehaald.

Voordat ik iets aanpaste, controleerde ik wat er werkelijk wordt vastgelegd:

• Een ‘deelnemer’ is één persoon op één expeditie, niet één unieke persoon. Beklim je de Everest vijf keer, dan sta je in vijf rijen.
• Bij 84% van de expedities ontbreekt of er een commerciële route is gevolgd.
• De meeste velden bevatten numerieke codes en de zuurstofvelden spreken elkaar tegen.

Dat klinkt specifiek voor bergbeklimmen. Dat is het niet.

Stel: je wilt weten welke klanten het meeste opleveren. Je ERP bevat één rij per orderregel, niet per order. Het veld ‘klantsegment’ is pas een paar jaar geleden verplicht geworden en is daarom leeg bij oudere orders. En creditnota’s staan in een apart systeem. Het dashboard erbovenop ziet er prima uit, totdat iemand vraagt waarom de omzet per klant niet aansluit op de jaarrekening.

Stel voordat je dat dashboard vertrouwt dezelfde drie vragen die ik bij de Himalaya-data stelde:

1. Wat betekent één rij?
2. Wat betekent een leeg veld?
3. Sluiten de details aan op het totaal?

Alle drie komen verderop terug.

Stap 3: opschonen.

Ongeveer twee derde van dit project ging op aan het binnenhalen, begrijpen en opschonen van de data. Daarbij waren twee principes leidend. Leeg betekent niet ‘nee’ en een nul kan ‘onbekend’ betekenen: een ontbrekende aanduiding voor een commerciële route wordt ‘Routeclassificatie niet vastgelegd’. En elk label moet te onderbouwen zijn: ‘Niet-commercieel, ingehuurde ondersteuning’, niet het aantrekkelijkere maar onbewezen ‘deels begeleid’.

Naamvelden zijn verwijderd en elke klimmer is een sleutel: gepseudonimiseerd, niet geanonimiseerd, omdat de openbare bron een sleutel nog steeds aan een naam kan koppelen.

Vier echte expedities: links de ruwe codes, rechts leesbare labels en lege waarden weergegeven als ‘niet vastgelegd’.

Voor de techneuten: transformaties staan in Power Query, niet in DAX. Bijna 90% van de logica die ik heb geschreven staat daar, waar de data binnenkomt, zodat het model leesbaar blijft. Stapnamen beschrijven wat de stap doet, zodat de volgende developer alles kan volgen zonder het mij te vragen. Het rapport is opgeslagen als .pbip, zodat elke wijziging via versiebeheer verloopt.

Twee stappen uit het model:

// FACT_Expeditions: a 0 in days or team size means "not recorded", not zero
#"replace 0s with null" = Table.ReplaceValue(#"Changed Type1", 0, null,
    Replacer.ReplaceValue, {"SMTDAYS", "TOTDAYS", "TOTMEMBERS"}),

// FACT_Members: an empty nationality becomes "Unknown", not a blank that disappears
#"null nationality = unknown" = Table.ReplaceValue(#"insert summit month",
    each [CITIZEN],
    each if [CITIZEN] = "" or [CITIZEN] = null then "Unknown" else [CITIZEN],
    Replacer.ReplaceValue, {"CITIZEN"}),

Bepaal de route: model en definities

Eén waarheid per getal

Stap 4: model.

Als twee rapporten een ander succespercentage tonen, vertrouwt niemand een van beide. Daarom heeft elk getal in dit model één definitie, die één keer als measure is vastgelegd en overal wordt hergebruikt. De succespercentages voor ingehuurd personeel en klimmende leden zijn gebaseerd op dezelfde onderliggende measure, niet op twee sterk gelijkende varianten.

Feiten en aannames worden nooit ongemerkt vermengd. Elke ledenrij heeft het label “Listed” (in de bron) of “Derived” (gereconstrueerd op basis van expeditietotalen; deel 5 legt uit waarom). Klik onder “Data scope” op “Listed” en het totale succespercentage verandert van 36% naar 43%. Dezelfde data, een andere vraag — en je ziet welke vraag je beantwoordt.

Waar het model aannames doet, moet je die kunnen onderbouwen als iemand vraagt hoe je daartoe bent gekomen. Het dashboard deelt elke bergtop in een Risk Band in, van “Low” tot “Extreme”. Daarachter zit de risicomatrixbenadering uit risicomanagement (ISO 31000 en de bijbehorende norm IEC 31010): sterfte en succes blijven twee afzonderlijke assen in plaats van te worden samengevoegd tot één score, en hun combinatie bepaalt de categorie. De grenswaarden liggen vast op 1% en 3% voor sterfte en 30% en 60% voor succes.

Hetzelfde dashboard, twee selecties. Alle records: 109,997 ledenrecords, 36% succes, 1.07% sterfte. Alleen Listed: 92,731 records, 43% succes, 1.27% sterfte.

De top: het dashboard, live

Elke visual beantwoordt een vraag uit stap 1

Stap 5: dashboard.

Elke titel van een visual is een vraag die de planner zou stellen, zoals “Summit Rate: Who Reaches the Top?” of “Peak Selection: Mortality Risk vs Summit Reward”. Dat is het verschil tussen een muur vol grafieken en een dashboard dat mensen daadwerkelijk gebruiken: je opent het met een vraag en vindt het antwoord, zonder handleiding of analist naast je.

Collega’s testten het in de rol van gebruikers en vertelden me waar ze de weg kwijtraakten. Bij een klant zijn dat de mensen die de beslissingen nemen.

Neem het niet zomaar van mij aan. Het dashboard staat live, dus klik er zelf doorheen:

Drie dingen om te proberen:

• Klik rechtsboven onder “Data scope” op “Listed” en kijk hoe het succespercentage verandert.
• Kies in het filter “Peaks” een bergtop die je kent.
• Beweeg de muis over een punt in “Peak Selection” om de details van die bergtop te bekijken.

De hoofdpagina, gefilterd op klimmende leden, leiders en plaatsvervangers.

Eén pagina ontbreekt in de liveversie: Key Influencers, die de factoren rangschikt die een uitkomst waarschijnlijker maken. Microsoft ondersteunt deze niet in een openbare “Publish to web”-embed, dus zie je de pagina hier als screenshot. Achter een normale login werkt deze zoals gebruikelijk.

De pagina Key Influencers. Zoals de subtitel aangeeft, gebruikt deze alleen Listed-records: de mensen van wie persoonlijke kenmerken bekend zijn. De factoren tonen patronen in de records, geen oorzaken.

De afdaling: controleren, corrigeren, beperkingen

Waarom het Sherpa-aantal niet klopte.

Stap 6: check.

In de Himalaya sterven meer mensen tijdens de afdaling (347) dan tijdens de toppoging (128). Dataprojecten gaan op hetzelfde punt mis: het dashboard is af, het ziet er goed uit en niemand controleert het nog een keer. Controleren is de laatste van onze zes stappen en de eerste die onder druk komt te staan als een deadline nadert. Juist daarom staat deze stap op de lijst. Terug naar de kop aan het begin: ik vergeleek de mensen die afzonderlijk op de lijst staan met de totalen die elke expeditie rapporteert.

Het aantal sterfgevallen onder ingehuurd personeel klopte. Het aantal mensen niet: slechts iets meer dan de helft van het ingehuurde personeel dat de expedities rapporteren, staat afzonderlijk vermeld. De ontbrekende mensen bereikten de top meestal niet. Laat je hen buiten beschouwing, dan lijkt het succespercentage veel hoger dan het werkelijk is.

Als je correct telt, bereikt het ingehuurde personeel op de berg (de ‘Sherpa’s’ uit mijn kop) in 40% van de gevallen de top, tegenover 36% van de klimmende expeditieleden. Nog steeds hoger, maar niet twee keer zo hoog. En doordat het hiaat in de registratie per periode verschilt, was de ontwikkeling door de tijd heen deels ook een ontwikkeling in de manier van registreren.

Links: het percentage ingehuurd personeel dat de top bereikte, berekend op basis van alleen het vermelde personeel (72%) en van al het personeel dat de expedities rapporteren (40%), naast de klimmende expeditieleden (36%). Rechts: het aandeel ingehuurd personeel dat niet afzonderlijk is vermeld, per periode.

De oplossing volgt hetzelfde principe als het opschonen: ontbrekende mensen worden alleen toegevoegd op basis van de totalen uit de bron zelf, gelabeld als ‘Derived’ en zonder verzonnen details. Daarna controleerde ik opnieuw en bleek de oplossing een eigen teleffect te hebben veroorzaakt: Key Influencers zag de lege nieuwe rijen ten onrechte als een patroon. Elke correctie wordt opnieuw gecontroleerd.

Eén ding liet ik bewust achter in het basiskamp: de routenamen, waarvoor alpiene expertise nodig is die ik niet heb. Voor een klant zou ik een domeinexpert aan tafel brengen, want we benoemen een beperking liever nu dan dat die je later verrast.

Wat betekent dit voor jou? Jouw dashboard heeft waarschijnlijk zijn eigen Sherpa-getal: een marge, conversiepercentage of omzet per klant dat overtuigend lijkt omdat niemand het heeft gecontroleerd aan de hand van het totaal waaruit het voortkomt.

Een verkeerde hoofdconclusie in een bestuursvergadering kost meer dan één extra controle. Die kan een besluit de verkeerde kant op sturen. En zodra één getal onjuist blijkt, verliezen mensen ook het vertrouwen in de andere cijfers. Controleren voordat er vragen komen, kost weinig. Vertrouwen terugwinnen nadat die vragen zijn ontstaan niet.

Terug in het dal

Met livegang ben je pas halverwege

Livegang is de top. Wat daarna komt, bepaalt of een dashboard wordt gebruikt: onderhoud, adoptie en vertrouwen in de cijfers.

Vertrouwen begint met vijf vragen over je eigen dashboard:

1. Wat stelt één rij in je data eigenlijk voor?
2. Wat betekenen lege velden, nullen en ontbrekende waarden eigenlijk?
3. Kun je dit getal uitleggen en verdedigen in een bestuursvergadering?
4. Welke cijfers zijn feiten en welke zijn door jou afgeleid, aangenomen of geclassificeerd?
5. Kloppen de cijfers nog steeds als je ze op een andere manier controleert?

Sherpa is eerst de naam van een volk en pas daarna een functiebenaming. In deze data droegen zij een groot deel van de lasten en werden zij het minst meegeteld. Daarom gebruik ik de vergelijking met respect, en precies om die reden: het werk dat een getal betrouwbaar maakt, is zelden zichtbaar in het eindtotaal. Je weet welke top je wilt bereiken. Een getal controleren aan de hand van het totaal waaruit het voortkomt, is precies dat soort werk: traag, onzichtbaar en de reden dat het resultaat standhoudt.

Ik dook uit nieuwsgierigheid in 120 jaar aan bergbeklimmingsdata. Die nieuwsgierigheid neem ik ook mee naar jouw project.

Wil je bespreken wat we voor jouw omgeving kunnen doen? Laat het ons weten; we denken graag met je mee.