Waarom managementdashboards zo vaak teleurstellen

Power BI is een krachtig platform. De software is beschikbaar, de licenties zijn vaak al aanwezig via Microsoft 365, en er zijn genoeg tutorials online. Toch worden veel Power BI-dashboards gebouwd en daarna nauwelijks gebruikt. Management kijkt één keer, vindt het "niet kloppen" of "te langzaam", en keert terug naar de Excel.

Dit is niet de fout van Power BI — het is de fout van hoe het project is aangepakt. De acht fouten hieronder zijn de meest voorkomende oorzaken van mislukte dashboard-implementaties. Ze zijn allemaal vermijdbaar.

Fout 1 Power BI direct op de brondatabase koppelen

De meest technisch risicovolle fout. Power BI DirectQuery op een productiedatabase (Exact Online, AFAS of een custom SQL-database die ook de dagelijkse operaties ondersteunt) leidt tot: trage dashboards (analytische queries zijn niet geoptimaliseerd in OLTP-databases), belasting op het bronsysteem (elke dashboardklik genereert queries op de productiedatabase), geen historische data (bronsystemen bewaren alleen de huidige staat), en DAX-beperkingen (time intelligence functies werken niet in DirectQuery).

Oplossing: Bouw een Azure SQL tussenlaag. ETL-pipeline haalt data op uit de bron, slaat op in Azure SQL, Power BI leest uit Azure SQL in Import mode. Dagelijkse refresh is voldoende voor 90% van de management-rapportages.
Fout 2 Geen Star Schema datamodel gebruiken

Veel Power BI-beginners laden alle data in één grote platte tabel. Dit werkt aanvankelijk, maar leidt tot problemen: slechte performance bij grote datasets (geen geoptimaliseerde joins), complexe DAX-formules (alles zit in één tabel), moeilijk uitbreidbaar (elke nieuwe bron voegt kolommen toe aan de mega-tabel), en gedupliceerde data.

Oplossing: Bouw een Star Schema: één centrale feittabel met sleutels naar compacte dimensietabellen voor datum, klant, medewerker, product, etc. DAX-formules worden eenvoudiger, performance verbetert 10x, en het model is makkelijk uitbreidbaar.
Fout 3 Te veel visuals op één pagina

We zien regelmatig dashboards met 15–25 visuals op één pagina. Het resultaat is visuele overload: management weet niet waar te kijken, de laadtijd is lang (Power BI berekent alle visuals bij het openen), en de boodschap is onduidelijk.

Management wil de beantwoording van 3–5 kernvragen op pagina 1. Alles daarboven is ruis. De rest van de informatie kan op detail-pagina's die toegankelijk zijn via drill-through.

Oplossing: Maximaal 5–7 visuals op de executive summary pagina. Stel de vraag: welke drie dingen wil de directie dagelijks zien? Bouw die eerste. Detail-pagina's voor diepere analyse, bereikbaar via knopjes of drill-through.
Fout 4 Geen ROW-level security instellen

Als iedereen alle data kan zien, is het dashboard een privacyrisico. Een teamleider die de salarissen van andere teams ziet, een medewerker die de marges van de concurrent in zijn eigen bedrijf ziet, of een klant die data van andere klanten kan inzien — dit zijn concrete GDPR-risico's met potentiële boetes.

Row-level security (RLS) is een ingebouwde functie van Power BI waarmee je per rol kunt beperken welke data zichtbaar is. Toch wordt het in meer dan de helft van de dashboards die wij reviewen niet geconfigureerd.

Oplossing: Definieer altijd RLS-rollen als onderdeel van het dashboard-ontwerp. Stel de vraag: wie mag welke data zien? Configureer rollen in Power BI Desktop via Modeling → Manage Roles, en koppel gebruikers aan rollen in Power BI Service via Dataset → Security.
Fout 5 Geen scheduled refresh configureren

Een dashboard dat niet automatisch wordt ververst, wordt niet gebruikt. Na de eerste keer dat management ontdekt dat de data van vorige week is, verliest het vertrouwen in het dashboard. Ze keren terug naar de Excel of de handmatige exports.

Scheduled refresh in Power BI Service is eenvoudig in te stellen maar wordt regelmatig over het hoofd gezien bij de oplevering van een dashboard.

Oplossing: Configureer scheduled refresh als standaard onderdeel van de oplevering. Voor de meeste management-dashboards volstaat dagelijkse refresh om 05:00–06:00. Stel ook een alert in op mislukte refreshes via Power BI Service → Dataset → Alert.
Fout 6 Geen Power BI App gebruiken voor distributie

Een .pbix-bestand per e-mail versturen is de digitale equivalent van de Excel per e-mail. Eindgebruikers hebben Power BI Desktop nodig, ze zien een statisch moment van de data, en er is geen toegangscontrole. Elke versie-update vereist een nieuwe e-mail.

Oplossing: Publiceer altijd via een Power BI App. Eindgebruikers ontvangen één link die altijd de actuele versie toont. Toegang via browser of mobiele app, geen installatie nodig. Rechtenbeheer via workspace-rollen.
Fout 7 KPI's niet gedefinieerd vóór de bouw

Dit is de meest schadelijke fout qua tijdsverspilling. Als je begint met bouwen voordat de KPI's zijn gedefinieerd, bouw je het verkeerde ding. Het dashboard is klaar, maar management herkent de KPI's niet of hanteert een andere definitie.

Wat is "omzet"? Is dat inclusief BTW of excl.? Inclusief creditnota's? Wat is "productiviteit"? Is reistijd direct of indirect? Deze vragen moeten vóór de bouw worden beantwoord en gedocumenteerd.

Oplossing: Begin elk project met een KPI-workshop: welke vragen moet het dashboard beantwoorden? Leg de definities vast in een KPI-glossary. Argus BI levert dit als onderdeel van het intake-proces. Pas dan begint de bouw.
Fout 8 Geen eigenaar aanwijzen voor het dashboard

Dit is de meest organisatorische fout, maar niet minder belangrijk. Als niemand verantwoordelijk is voor het dashboard, wordt het niet onderhouden. Definities veranderen, nieuwe KPI's worden gewenst, data-issues worden niet opgepakt, en het dashboard veroudert.

Na 6 maanden is het dashboard "niet meer actueel" en wordt het niet meer gebruikt. De organisatie trekt de conclusie dat "Power BI niet werkt" — terwijl het probleem het ontbreken van eigenaarschap is.

Oplossing: Wijs bij de oplevering een dashboard-eigenaar aan (typisch een controller of BI-verantwoordelijke). Deze persoon is het aanspreekpunt voor gebruikersvragen, beheert de toegangsrechten, en beslist over doorontwikkeling. Argus BI levert kennisoverdracht en documentatie specifiek voor deze eigenaar.

Dashboard-review nodig?

Argus BI beoordeelt bestaande Power BI-implementaties op architectuur, datamodel, RLS en distributie. Of we bouwen uw volgende dashboard meteen goed de eerste keer.

Laat je dashboardvraag beoordelen

Veelgestelde vragen

Waarom werkt Power BI direct op een brondatabase niet goed?

Een directe verbinding (DirectQuery) op een productiedatabase heeft drie problemen: trage performance (analytische queries zijn niet geoptimaliseerd in OLTP-databases), belasting op het bronsysteem dat ook operationele processen ondersteunt, en geen historische data. Een Azure SQL tussenlaag lost alle drie op.

Wat is een Power BI App en wanneer gebruik je die?

Een Power BI App is een gepubliceerde collectie van rapporten die eindgebruikers ontvangen als een link. Ze openen de app in hun browser of mobiele app zonder Power BI Desktop te hoeven installeren. Een Power BI App is de juiste distributiewijze zodra meerdere mensen het dashboard moeten gebruiken. Rechtenbeheer via row-level security en workspace-rollen.

Hoe stel je ROW-level security in voor managementdashboards?

Row-level security in Power BI werkt via rollen in het datamodel. Je definieert een rol (bijv. "Teamleider") met een DAX-filter die de data beperkt (bijv. WHERE team_id = USERPRINCIPALNAME()). In Power BI Service koppel je gebruikers of Azure AD-groepen aan de rol via Dataset → Security. Argus BI configureert RLS als standaard onderdeel van elke dashboard-oplevering.

Hoeveel visuals zijn ideaal voor een managementdashboard?

De richtlijn: maximaal 5–7 visuals op de eerste pagina (de executive summary). Management kijkt naar een dashboard voor antwoord op 3–5 kernvragen. Als je 20 visuals op één pagina hebt, is het antwoord op geen enkele vraag duidelijk. Meer detail hoort op doorklikkende detailpagina's die bereikbaar zijn via drill-through.