Power BI adoptie verhogen: het 4-fase model dat GGD-regio's gebruiken

25 GGD-regio's rapporteerden elk op hun eigen manier. Excel-bestanden die niet synchroon liepen, het RIVM zonder directe toegang tot regionale data, en volksgezondheidsbeleid gebaseerd op versnipperde informatie. Een situatie waarbij Power BI adoptie verhogen niet alleen een IT-vraagstuk was, maar een kwestie van nationale veiligheid.

Het startpunt: versnipperde rapportage zonder overzicht

Elke GGD-regio had zijn eigen Excel-templates. De ene regio gebruikte andere berekeningen dan de andere. Wanneer het RIVM landelijke cijfers nodig had, kostte het uren om alle individuele bestanden samen te voegen — als ze al beschikbaar waren.

Het probleem zat niet in de kwaliteit van de data zelf. Elke regio verzamelde nauwkeurig de gegevens over infectieziekten, vaccinaties en andere gezondheidsparameters. Maar het ontbrak aan een gestandaardiseerde manier om deze informatie samen te brengen tot één coherent beeld.

Management van individuele regio's werkten met dashboards die wel lokaal actueel waren, maar onmogelijk te vergelijken met andere regio's. Bij uitbraken of trends die meerdere regio's raakten, ontstond er vertraging doordat handmatige afstemming nodig was.

Het werd duidelijk dat dashboard adoptie verhogen alleen mogelijk was als we één centraal model zouden bouwen dat toch de autonomie van elke regio respecteerde.

De kernuitdaging: één model voor 25 autonome organisaties

De technische uitdaging leek op het eerste gezicht overzichtelijk: bouw één Power BI-model dat data van alle regio's combineert. Maar de echte complexiteit zat in de governance en beveiliging.

Elke GGD-regio is een zelfstandige organisatie met eigen privacy-verantwoordelijkheden. Regio Noord-Holland mag geen data van regio Zeeland zien, en andersom. Tegelijkertijd moet het RIVM wel toegang hebben tot alle data voor landelijke analyses.

De traditionele aanpak — 25 losse Power BI-modellen — zou betekenen dat er geen centrale aansturing mogelijk was. Updates zouden 25 keer handmatig uitgerold moeten worden. Berekeningen zouden kunnen gaan afwijken tussen regio's. En het RIVM zou alsnog geen geïntegreerd overzicht hebben.

Een ander probleem was gebruikersbetrokkenheid. De meeste GGD-medewerkers waren gewend aan Excel. Ze kenden de shortcuts, wisten hoe ze pivottabellen moesten maken, en hadden vertrouwen in hun eigen berekeningen. Overstappen naar Power BI betekende niet alleen nieuwe software leren, maar ook vertrouwen krijgen in een systeem dat zij niet zelf controleerden.

De beslissing: één centraal model met row-level security

We kozen voor één centraal semantisch model in Power BI met row-level security (RLS) per regio. Elke GGD ziet alleen zijn eigen data, maar alle regio's gebruiken hetzelfde datamodel en dezelfde berekeningen.

Het RIVM kreeg een aparte beveiligingsrol waarmee zij toegang hebben tot alle data op geaggregeerd niveau. Geen individuele patiëntgegevens, maar wel de landelijke trends en vergelijkingen tussen regio's.

Voor de uitrol hanteerden we een deployment pipeline met drie fases: development, test en productie. Elke wijziging aan het model moest eerst getest worden door een pilotgroep van gebruikers uit verschillende regio's voordat het naar alle 25 regio's ging.

De governance-structuur werd net zo belangrijk als de techniek. Elke regio benoemde een data-eigenaar die verantwoordelijk was voor de kwaliteit van hun regionale input. Deze personen vormden samen een stuurgroep die maandelijks overlegde over aanpassingen aan het model.

Voor training organiseerden we regionale sessies in plaats van één centrale training. Dit maakte het mogelijk om specifieke lokale vraagstukken te bespreken en ervoor te zorgen dat gebruikers direct konden oefenen met hun eigen data.

Wat we expliciet niet deden (en waarom dat cruciaal was)

We hebben bewust geen losse dashboards per regio gebouwd. Het alternatief — 25 individuele modellen — zou onderhoud onmogelijk hebben gemaakt. Elke keer dat er een nieuwe KPI bij zou komen of een berekening zou wijzigen, zouden we 25 verschillende modellen moeten aanpassen.

Ook hebben we geen volledige migratie in één keer gedaan. In plaats daarvan behielden we Excel als fallback gedurende de eerste drie maanden. Dit gaf gebruikers de zekerheid dat ze hun werk konden blijven doen, ook als er in het begin nog kinderziektes waren met het nieuwe systeem.

Ten slotte hebben we geen uitgebreide customisatie per regio toegestaan. Elke regio wilde wel specifieke kleuren, logo's of extra grafieken. Door dit niet toe te staan, bleven alle dashboards herkenbaar en kon ondersteuning centraal georganiseerd worden. Een gestandaardiseerde workspace structuur was hierbij essentieel.

Het resultaat: van uren naar realtime rapportage

Na zes maanden had elk van de 25 GGD-regio's toegang tot realtime dashboards met hun eigen data. Het RIVM kon voor het eerst landelijke trends monitoren zonder te wachten op handmatige exports van individuele regio's.

De rapportagetijd ging van uren naar realtime. Waar het RIVM vroeger moest wachten tot alle regio's hun Excel-bestanden hadden ingeleverd, konden ze nu direct zien wat er speelde in het hele land.

Maar het belangrijkste resultaat was de verhoogde Power BI gebruikers betrekken: alle 25 regio's gebruikten actief het nieuwe systeem. Geen Excel-schakelbestanden meer, geen handmatige berekeningen die konden afwijken tussen regio's.

De data quality verbeterde doordat iedereen met dezelfde definities werkte. Een 'nieuwe infectie' betekende nu in alle regio's hetzelfde, waar dit voorheen kon verschillen afhankelijk van hoe iemand zijn Excel-formule had opgezet.

Het 4-fase model voor verhoogde adoptie

Uit deze implementatie ontstond een herhaalbaar 4-fase model dat andere organisaties kunnen gebruiken om Power BI adoptie te verhogen:

Fase 1: Governance voor techniek

Begin niet met dashboards bouwen, maar met afspraken maken. Wie is eigenaar van welke data? Wie mag wat zien? Welke berekeningen zijn leidend? Deze vragen oplossen voordat je begint met technische implementatie voorkomt maanden vertraging later.

Stel een stuurgroep samen met vertegenwoordigers uit elke business unit. Geef hen beslissingsbevoegdheid over datastandaarden en governance-regels. Zonder deze buy-in op management niveau blijft adoptie steken op individueel niveau.

Fase 2: Eén model, meerdere weergaven

Bouw één centraal semantisch model dat iedereen gebruikt, maar geef elke afdeling of regio hun eigen beveiligde weergave. Row-level security zorgt ervoor dat gebruikers alleen hun eigen data zien, terwijl je toch de voordelen hebt van één gedeeld model.

Test het model uitgebreid met een pilotgroep voordat je het breed uitrolt. Deze groep moet representatief zijn voor alle verschillende gebruikerstypen in je organisatie.

Fase 3: Parallelle periode met fallback

Schakel niet in één keer van het oude systeem naar Power BI. Laat beide systemen een periode naast elkaar draaien. Dit geeft gebruikers de tijd om vertrouwen op te bouwen in de nieuwe tool zonder de druk dat hun werk stil komt te liggen als er iets mis gaat.

Gebruik deze periode om verschillen tussen het oude en nieuwe systeem uit te leggen. Vaak zijn er goede redenen waarom cijfers kunnen afwijken (andere berekeningslogica, recentere data, andere filters), maar als gebruikers dit niet begrijpen, verliezen ze vertrouwen.

Fase 4: Lokale champions en continue verbetering

Identificeer in elke afdeling of regio een persoon die enthousiast is over de nieuwe tool. Train deze lokale champions intensiever dan de rest, zodat zij hun collega's kunnen helpen met dagelijkse vragen.

Organiseer maandelijkse sessies waar gebruikers nieuwe features kunnen voorstellen of problemen kunnen bespreken. Dit houdt de tool relevant en laat zien dat feedback wordt gewaardeerd.

Het succes van digitalisering in de publieke sector hangt vaak af van deze lokale betrokkenheid — techniek alleen is niet voldoende.

Veelgemaakte fouten die adoptie blokkeren

Uit verschillende implementaties bij overheidsorganisaties blijken er drie fouten te zijn die Power BI adoptie systematisch blokkeren:

Te veel dashboards tegelijk introduceren

De neiging bestaat om alle bestaande Excel-rapportages in één keer om te bouwen naar Power BI. Dit overweldigt gebruikers en maakt het onmogelijk om feedback te verwerken. Begin met één dashboard dat een duidelijk probleem oplost, en bouw langzaam uit.

Geen aandacht voor data-eigenaarschap

Als niemand verantwoordelijk is voor de kwaliteit van de input, dan helpt het mooiste dashboard niet. Gebruikers verliezen snel vertrouwen als zij fouten ontdekken die niemand kan of wil oplossen. Een governance framework voorkomt deze problemen.

Training zonder context

Algemene Power BI-cursussen leren gebruikers hoe knoppen werken, maar niet hoe zij hun specifieke werkprocessen kunnen verbeteren. Train mensen met hun eigen data en hun eigen vragen — dan zien ze direct de meerwaarde.

Technische succesfactoren die vaak vergeten worden

Naast governance en training zijn er technische aspecten die cruciaal zijn voor succesvolle adoptie maar vaak over het hoofd gezien worden:

Performance vanaf dag één

Een langzaam dashboard wordt niet gebruikt, ongeacht hoe mooi het eruitziet. Optimaliseer performance voordat je uitrolt, niet achteraf. Gebruikers vergeven veel, maar niet dat hun tijd wordt verspild door trage systemen.

Mobiele toegang die echt werkt

Veel professionals hebben onderweg toegang nodig tot hun dashboards. Zorg ervoor dat de mobiele ervaring niet een bijgedachte is, maar vanaf het begin meegenomen wordt in het ontwerp.

Integratie met bestaande workflow

Als gebruikers moeten inloggen op een aparte website om hun dashboard te bekijken, wordt de drempel hoger. Probeer Power BI-rapportages te embedden in systemen die mensen al dagelijks gebruiken, zoals SharePoint of Teams.

Meetbare indicatoren voor succesvolle adoptie

Hoe weet je of je Power BI adoptie-strategie werkt? Deze metrics geven meer inzicht dan alleen het aantal gebruikers:

• Frequentie van gebruik: Hoeveel dagen per week loggen gebruikers in? Dagelijkse gebruikers zijn waardevoller dan gebruikers die één keer per maand kijken.
• Self-service vragen: Hoeveel analysegebonden vragen komen er nog bij IT binnen? Een daling duidt op toenemende zelfstandigheid.
• Excel-export: Hoeveel Power BI-data wordt nog geëxporteerd naar Excel? Dit kan duiden op ontbrekende functionaliteit of onvoldoende vertrouwen.
• Nieuwe dashboard-aanvragen: Als gebruikers nieuwe dashboards willen voor hun werk, betekent dit dat zij de toegevoegde waarde hebben ervaren.

Bij GGDGHOR was de belangrijkste indicator dat het RIVM stopte met het vragen om Excel-exports. Dat gebeurde na vier maanden — een duidelijk teken dat het nieuwe systeem volledig was geaccepteerd.

Lessen die buiten deze case gelden

Multi-regio row-level security moet je één keer goed ontwerpen — achteraf aanpassen kost maanden. Plan beveiligingsrollen vanaf het begin en test ze uitgebreid met echte gebruikers voordat je uitrolt. Een beveiligingsmodel dat achteraf blijkt niet te werken, betekent vaak een volledige herstart.

Governance is belangrijker dan techniek: zonder data-eigenaarschap per afdeling werkt centralisatie niet. Iemand moet verantwoordelijk zijn voor de kwaliteit van elke dataset. Deze persoon heeft tijd nodig om die rol uit te voeren — het is niet iets wat je 'er even bij doet'.

Deployment pipelines zijn geen luxe maar een vereiste in elke gereguleerde sector — elke wijziging moet controleerbaar zijn. Een moderne Power BI-architectuur zonder gecontroleerde releases leidt tot chaos wanneer er iets mis gaat.

Lokale champions zijn effectiever dan centrale training. Eén enthousiaste collega die het systeem kent, helpt meer dan tien online cursussen. Investeer in deze mensen — geef ze extra training, erkenning en de tools die ze nodig hebben om anderen te helpen.

Ten slotte: dashboards die niet gebruikt worden hebben altijd een reden. Meestal ligt het niet aan de techniek, maar aan ontbrekende context, onduidelijke meerwaarde, of gebrek aan vertrouwen in de data. Los deze fundamentele problemen op voordat je focust op nieuwe features.