Wat moet ik aanleveren voor een dashboard?

Beslisvragen, bronoverzicht, KPI-definities, gewenste gebruikers, actualiteit, toegang en acceptatiecriteria.

Moet de bron al schoon zijn?

De bron hoeft niet perfect te zijn, maar bekende afwijkingen en eigenaars moeten wel zichtbaar zijn.

Wie mag het dashboard zien?

Leg rollen en toegangsrechten vooraf vast, vooral als het persoonsgegevens of commerciële informatie bevat.

Hoe test ik een dashboard?

Vergelijk enkele afgesproken voorbeelden handmatig met de bron en laat de eigenaar de KPI-definitie accorderen.

Wat gebeurt er na oplevering?

Spreek beheer, refreshcontrole, wijzigingsprocedure en een eigenaar van iedere definitie af.

Dashboard laten maken: wat je vooraf vastlegt (2026)

Een dashboard laten maken werkt het best wanneer je vooraf vastlegt welke beslissingen het moet ondersteunen en hoe een uitkomst gecontroleerd wordt. Maak pas een eerste inschatting nadat de scope, bronnen en verantwoordelijkheden helder zijn; een los voorbeeldscherm is daarvoor onvoldoende.

Stappenplan

1. Beschrijf gebruikers en beslissingen

Noteer wie kijkt, welke vraag die persoon beantwoordt en welke actie daarop volgt. Gebruik een kort analyseplan als startdocument.

2. Maak een bron- en KPI-overzicht

Beschrijf per bron eigenaar, updatefrequentie, sleutel, definitie en bekende gaten. Leg per KPI teller, noemer, periode en gewenste uitsplitsing vast via KPI's kiezen.

3. Leg acceptatiecriteria vast

Kies een paar controleerbare bronvoorbeelden. Het dashboard is pas acceptabel wanneer die waarden, filters en definities aantoonbaar overeenkomen. Voer vooraf de datakwaliteitschecks uit.

4. Regel privacy en beheer

Beperk toegang en velden tot wat nodig is. De AP licht verantwoordingsplicht, privacy by design en dataminimalisatie toe. Spreek ook af wie een refreshfout, gewijzigde definitie of vertrokken eigenaar behandelt.

Controleerbaar voorbeeld

Vraag: "Welke regio heeft deze maand de meeste openstaande aanvragen?" Acceptatie: één afgesproken regio en maand geven hetzelfde aantal als de bronlijst na dezelfde statusfilter. Deze test is concreet genoeg om te herhalen zonder persoonsgegevens te delen.

Een dashboardopdracht is vooral een definitie-opdracht

Een goed dashboard begint niet met een kleur, template of lijst grafieken. Het begint met de vraag welke beslissing iemand regelmatig moet nemen en welk bewijs daarbij nodig is. Laat opdrachtgever, inhoudelijke eigenaar en gebruiker eerst één beslisvraag bevestigen. Voorbeelden zijn capaciteit verdelen, afwijkingen onderzoeken of voortgang tegen een afgesproken doel volgen. “Alles op één scherm” is geen bruikbare scope.

Leg per onderdeel vast wat de bron is, welke periode ververst wordt, welke status meetelt en welke drempel actie vraagt. Microsoft legt bij KPI-visualisaties uit dat een KPI-visual een basismeting, doel en drempel nodig heeft. Dat is een productvoorbeeld, geen vrijbrief om een doel te verzinnen. Een norm hoort uit een goedgekeurde afspraak, beleid of meetbare historische basis te komen.

Briefing in acht concrete onderdelen

Gebruikers en besluit: wie kijkt wanneer en welke keuze kan volgen?
Bronnen: systeem, eigenaar, export- of refreshmoment, bekende beperkingen.
KPI-definities: teller, noemer, periode, filters, eenheid en eigenaar.
Uitsplitsingen: welke regio, productgroep of team helpt de oorzaak onderzoeken?
Privacy en rechten: minimale velden, rollen, delen en bewaartermijn.
Acceptatievoorbeelden: een klein setje vooraf doorgerekende fictieve gevallen.
Beheer: wie controleert refresh, wijziging en foutmelding na oplevering?
Niet in scope: bijvoorbeeld voorspellen, individuele beoordeling of onbevestigde koppelingen.

Bewaar de briefing samen met het analyseplan. Vraag geen volledige exports met persoonsgegevens via WhatsApp of e-mail voor een eerste inschatting. Een bronlijst, kolomnamen en synthetisch voorbeeld zijn meestal genoeg om de scope te bespreken. De AVG-tekst op EUR-Lex beschrijft waarom doel, noodzakelijkheid en toegang vooraf horen te zijn bepaald.

Synthetisch acceptatievoorbeeld

Een fictieve operationsmanager wil wekelijks zien of leveringen tijdig zijn. De KPI luidt: “tijdig geleverd percentage = orders met leverdatum op of vóór afspraakdatum gedeeld door alle definitief leverbare orders in dezelfde kalenderweek.” Geannuleerde orders zijn uitgesloten; orders zonder afspraakdatum komen in een aparte kwaliteitskaart. De bron is een ordertabel waarvan de eigenaar iedere ochtend de statusregels bevestigt.

Voor acceptatie maakt het team zes volledig fictieve orderregels. Vier orders zijn tijdig, één is te laat en één heeft geen afspraakdatum. Die laatste regel valt volgens de definitie buiten de noemer en verschijnt uitsluitend als kwaliteitswaarschuwing. De noemer bevat daardoor vijf leverbare orders met een bekende afspraakdatum; vier daarvan zijn tijdig. De verwachte KPI is exact 4 gedeeld door 5, dus 80%, met daarnaast één kwaliteitswaarschuwing. Laat bouwer én inhoudelijke eigenaar dit voorbeeld onafhankelijk narekenen. Pas wanneer uitkomst, noemer, uitsluiting, filter en labels overeenkomen, is de tegel klaar voor een echte bron. Zo toets je betekenis zonder klantinformatie te kopiëren.

Neem ook grensgevallen op in de acceptatieset. Denk aan een order die precies op de afspraakdatum is geleverd, een geannuleerde order en een levering na middernacht in een andere tijdzone. Leg vóór de test vast hoe elk geval meetelt. Zo controleer je niet alleen de gewone uitkomst, maar ook de regels die later onverwachte verschillen veroorzaken.

De grafiek onder de KPI toont daarna de wekelijkse trend. Kies die vorm pas na de definitie: grafiek kiezen helpt bepalen of lijn, staaf of tabel de vraag werkelijk ondersteunt. Voeg altijd periode, bron, filterstatus en “laatst ververst” toe, zodat een lezer geen actuele actie baseert op een oude export.

Validatie, herstel en overdracht

Plan minimaal drie controles: een broncontrole vóór bouwen, acceptatie met afgesproken voorbeelden en een refreshcontrole na oplevering. Vergelijk bij iedere controle rijaantallen, relevante totalen en een steekproef met de bron. Laat niet alleen de ontwikkelaar controleren; de betekenis-eigenaar moet bevestigen dat status, norm en uitzondering kloppen. De Power BI-overzichtspagina over visualisaties laat zien dat verschillende visuals voor verschillende inzichten bestaan. Gebruik interactie en filters alleen als je ze met een duidelijke vraag en test kunt onderbouwen.

Wanneer een refresh faalt of een totaal onverwacht afwijkt, maak de rapportage niet stilzwijgend groen. Toon een zichtbare status, noteer tijdstip en eigenaar, stop desnoods distributie en herstel eerst de bron of definitie. Herbereken vanaf de vastgelegde bronversie. Schrijf in de overdracht wie de refresh controleert, waar de definitielijst staat en hoe een wijzigingsverzoek wordt beoordeeld. Zonder die afspraken wordt een dashboard een momentopname die niemand veilig durft te gebruiken.

Veelgemaakte fouten

Een dashboard als einddoel zien. De waarde zit in een betere, herhaalbare beslissing.
Doelen zonder eigenaar opnemen. Dan weet niemand of rood of groen betekenis heeft.
Rijen met ontbrekende waarden verbergen. Toon een kwaliteitsindicator of benoem de uitsluiting.
Eén scherm voor iedere doelgroep maken. Maak rollen en vragen expliciet.
Geen herstelprocedure afspreken. Een fout wordt dan pas zichtbaar nadat iemand erop stuurt.

Rond de voorbereiding af door eerst KPI's te definiëren en daarna de datakwaliteit te controleren. Een beoordeling kan met de briefing en synthetische voorbeelden; bronbestanden en persoonsgegevens zijn daarvoor niet nodig.