Rolgebaseerde toegang in het winstgevendheidsdashboard: wie ziet wat en waarom

Een winstgevendheidsdashboard bevat de meest commercieel gevoelige data die een groothandel produceert. De nettomarge per klant, de klantranglijst op marge, de werkelijke bedieningskost van elk account: het zijn cijfers die, in de verkeerde handen, tot prijsonderhandeling, interne wrijving of concurrentieschade kunnen leiden.

De vraag “wie mag dit zien?” is dan ook geen technische bijzaak. Het is een governancebeslissing die je maakt voordat het dashboard live gaat. Elke rol in de organisatie heeft een ander legitiem informatiebelang. De CFO wil het volledige beeld. De controller wil diepgaande analytische toegang. De salesmanager wil zijn eigen portefeuille kunnen sturen zonder de marge van zijn collega’s te kennen. Operations wil inzicht in kostensoorten en kanalen, niet in individuele klantmarges.

In dit artikel beschrijven we het vier-rollenmodel dat Kimura hanteert voor winstgevendheidsdashboards in de groothandel: welke rol welk perspectief krijgt, waarom die grenzen bewust zijn getrokken en hoe dynamische Row Level Security (RLS) in Power BI dit technisch afdwingt.

Key takeaways

• Klantwinstgevendheidsdata is commercieel gevoelig. Wie toegang heeft tot welke data is een governancebeslissing, niet alleen een IT-configuratie.
• Het Kimura-vier-rollenmodel onderscheidt CFO (volledige toegang), Controller (volledig analytisch), Salesmanager (eigen portefeuille) en Operations (kanaal en kostensoort).
• Dynamische Row Level Security (RLS) in Power BI dwingt deze rolverdeling technisch af via DAX-filterexpressies op basis van de loginidentiteit van de gebruiker.
• Elke salesmanager ziet automatisch alleen de klanten uit zijn eigen portefeuille. Er is geen handmatige filtering nodig en geen risico op onbedoelde data-exposure.
• De RLS-configuratie in het Kimura Data Framework is schaalbaar: nieuwe salesmanagers worden toegevoegd via een gebruikerstabel, niet via code-aanpassingen.

In dit artikel

We beschrijven het vier-rollenmodel voor winstgevendheidsdashboards en hoe rolgebaseerde toegang technisch en organisatorisch werkt:

• Waarom databescherming in een winstgevendheidsdashboard geen bijzaak is
• De vier rollen en hun dataperspectief
• Hoe dynamische RLS dit technisch afdwingt in Power BI
• Rolbeheer in de praktijk: aanpassen zonder herbouwen
• Veelgemaakte fouten bij rolgebaseerde toegang in winstgevendheidsdashboards
• FAQ: veelgestelde vragen over rolgebaseerde toegang in winstgevendheidsdashboards

Waarom databescherming in een winstgevendheidsdashboard geen bijzaak is

Winstgevendheidsinzicht op klantniveau is strategisch waardevolle informatie. De nettomarge per klant onthult welke klanten disproportioneel veel kosten genereren, welke accounts op basis van margeanalyse heronderhandeld zouden moeten worden en welke klanten juist beschermd en versterkt moeten worden. Dat zijn beslissingen die op directie- en managementniveau genomen worden, niet op het niveau van de individuele salesrep.

Toch is de primaire neiging bij dashboardimplementaties om data breed beschikbaar te maken. “Iedereen heeft toch baat bij meer inzicht?” is een redenering die begrijpelijk is maar risico’s met zich meedraagt:

• Concurrentiegevoeligheid. Als een salesmanager de margedata van zijn collega’s ziet, ontstaat er inzicht in de relatieve waarde van elkaars klantenportefeuilles. Dat kan leiden tot interne wrijving over klantoverdracht, bonusperceptie en portefeuille-allocatie.
• Onderhandelingsrisico. Als salesmedewerkers de kostprijs en nettomarge per klant kennen, verandert dat hun gedrag in klantgesprekken. Margedata in handen van de verkopende partij is comfortabel; in handen van de klant is het een onderhandelingsargument.
• Compliancerisico. Persoonsgebonden klantdata valt onder de AVG. Wie verantwoordelijk is voor klantdata, is ook verantwoordelijk voor de toegangscontrole erop. Ongedifferentieerde toegang tot klantniveau-data vergroot het compliancerisico.

Rolgebaseerde toegang lost deze risico’s op door elke gebruiker precies het inzicht te geven dat hij nodig heeft voor zijn functie, en niet meer dan dat.

De vier rollen en hun dataperspectief

In het Kimura-vier-rollenmodel voor winstgevendheidsdashboards worden vier gebruikersrollen onderscheiden. Elke rol heeft een eigen dataperspectief dat aansluit bij zijn functie en beslissingsbevoegdheid.

CFO / Financieel Directeur: volledige toegang. De CFO heeft toegang tot alle data in het winstgevendheidsdashboard. Alle klanten, alle kostensoorten, alle kanalen, alle regio’s en alle historische periodes. De CFO gebruikt het dashboard voor strategische besluiten over het totale klantenportfolio, de overall P&L en de richting van het commercieel beleid. Zonder volledige toegang is de strategische functie van het dashboard niet te vervullen.

Controller / Finance Manager: volledig analytisch. De controller heeft toegang tot alle analytische lagen van het dashboard, inclusief de volledige klantranglijst, de kostenallocatiedetails en de allocatielogica. De controller gebruikt het dashboard voor validatie, analyse en rapportage. Het enige wat de controllerrol niet heeft ten opzichte van de CFO-rol, zijn de managementsummary-pagina’s die specifiek zijn ingericht voor directiebesluitvorming.

Salesmanager: eigen portefeuille. De salesmanager ziet uitsluitend de klanten die aan hem zijn gekoppeld in de gebruikerstabel. Hij ziet de omzet, brutomarge, nettomarge en klantranglijst voor zijn eigen portefeuille, maar niet die van zijn collega’s. De klantranglijst op marge toont alleen zijn eigen accounts, in dezelfde volgorde als de totale lijst maar zonder context van de rest van de organisatie. Dit geeft de salesmanager de stuurinformatie die hij nodig heeft voor zijn accountstrategie, zonder de concurrentieproblemen die ontstaan bij volledig gedeelde margedata.

Operations / Logistiek Manager: kanaal en kostensoort. De operationsmanager heeft geen toegang tot klantindividuele margedata maar wel tot de kostenanalyse op kanaal- en kostensoort-niveau. Hij ziet de vrachtkosten per kanaal, de handlingskosten per ordertype en de kostentrends per logistieke activiteit. Dat stelt hem in staat om operationele beslissingen te nemen over kostenreductie en procesoptimalisatie, zonder toegang tot de commercieel gevoelige P&L per klant.

Hoe dynamische RLS dit technisch afdwingt in Power BI

Row Level Security (RLS) in Power BI is het technische mechanisme waarmee rolgebaseerde toegang op dataniveau wordt afgedwongen. Het werkt door aan elke rol een DAX-filterexpressie te koppelen die per datarij evalueert of de ingelogde gebruiker die rij mag zien. Als de expressie TRUE retourneert, is de rij zichtbaar. Als de expressie FALSE retourneert, bestaat die rij voor de gebruiker niet.

Voor het vier-rollenmodel in een groothandel-winstgevendheidsdashboard wordt dynamische RLS ingezet, gebaseerd op de USERPRINCIPALNAME() DAX-functie. Dit is de loginidentiteit van de gebruiker in Microsoft 365, typisch het e-mailadres. Dynamische RLS koppelt die loginidentiteit aan een gebruikerstabel in het datamodel, waarbij elke gebruiker is gekoppeld aan zijn rol en zijn dataperimeter.

Voor de salesmanagerrol werkt dit als volgt: in het datamodel bestaat een gebruikerstabel met drie kolommen: e-mailadres, salesmanager-ID en bijbehorende klantenlijst. De DAX-filterexpressie op de klanttabel evalueert bij elke query of het e-mailadres van de ingelogde gebruiker overeenkomt met de salesmanager die aan een klant is gekoppeld. Alleen de rijen waarvoor dat TRUE is, worden geretourneerd. De salesmanager ziet dus automatisch alleen zijn eigen klanten, zonder dat er iets handmatig hoeft te worden gefilterd en zonder dat hij weet hoeveel klanten zijn collega bedient.

Voor de CFO-rol geldt het tegenovergestelde: de DAX-expressie retourneert altijd TRUE, wat betekent dat alle rijen zichtbaar zijn ongeacht de filtercondities. De controllerrol werkt vergelijkbaar maar met een aanvullende OLS-laag (Object Level Security) die bepaalde directie-specifieke pagina’s of kolommen niet beschikbaar stelt.

Een technisch voordeel van dynamische RLS is de schaalbaarheid: als een salesorganisatie groeit, worden nieuwe salesmanagers uitsluitend toegevoegd aan de gebruikerstabel. De DAX-filterlogica, de rapportstructuur en de datamodellen hoeven niet te worden aangepast. Dit is een directe uitdrukking van het principe van het Microsoft Fabric-fundament: configureerbaar zonder herbouw.

Rolbeheer in de praktijk: aanpassen zonder herbouwen

Een van de meest praktische vragen bij rolgebaseerde toegang is: wat gebeurt er als de organisatie verandert? Een salesmanager neemt een nieuwe portefeuille over. Twee regio’s worden samengevoegd. Een controller krijgt tijdelijk toegang tot een specifiek klantdossier. Hoe worden die wijzigingen doorgevoerd?

In de Kimura RLS-configuratie worden organisatiewijzigingen doorgevoerd via de gebruikerstabel en de portefeuille-toewijzingstabel in het datamodel. Die tabellen worden beheerd buiten de Power BI Desktop-rapportstructuur, direct in het Kimura Data Framework. Dat betekent:

• Portefeuille-overdracht: klanttoewijzing in de toewijzingstabel bijwerken. Bij de volgende dataverversing ziet de nieuwe salesmanager de overgedragen klanten, de vorige salesmanager niet meer.
• Nieuwe gebruiker toevoegen: e-mailadres, rol en eventuele portefeuille toevoegen aan de gebruikerstabel. Geen code-aanpassing, geen rapport-herbouw.
• Tijdelijke uitbreiding van toegang: een tijdelijke roltoewijzing in de gebruikerstabel met een einddatum, waarna de toewijzing automatisch vervalt bij de volgende verversing.

Dit beheersmodel maakt het mogelijk dat de CFO of HR verantwoordelijk wordt voor de feitelijke rolbeheer, terwijl de technische RLS-logica stabiel blijft. De governance-verantwoordelijkheid ligt bij de business, de technische infrastructuur wordt door Kimura beheerd.

Veelgemaakte fouten bij rolgebaseerde toegang in winstgevendheidsdashboards

Op basis van implementatiepraktijk zijn er vier patronen die structureel opduiken als RLS niet goed is geconfigureerd in een winstgevendheidsdashboard:

• Te brede beginset. De eerste versie van het dashboard wordt aan iedereen beschikbaar gesteld zonder RLS, “voor de testfase”. De testfase eindigt nooit formeel, en de brede toegang wordt de standaard. Rolgebaseerde toegang is moeilijker terug te draaien dan in te stellen. Stel RLS in vóór de eerste publicatie.
• Statische RLS zonder gebruikerstabel. Bij kleine teams wordt RLS soms statisch geconfigureerd: één rol per regio, hardcoded in de DAX-expressie. Zodra de organisatie groeit of verandert, moeten de roldefinities worden aangepast in Power BI Desktop en opnieuw worden gepubliceerd. Dynamische RLS met een gebruikerstabel is onderhoudsvriendelijker en schaalbaarder.
• Geen onderscheid tussen dashboard-toegang en model-toegang. Een gebruiker met bewerkingsrechten op de Power BI werkruimte omzeilt RLS automatisch: hij kan het semantisch model rechtstreeks bevragen. Het juiste beveiligingsniveau is Read-only op het semantisch model voor alle eindgebruikers, inclusief salesmanagers en controllers.
• Onvolledige drill-through-beveiliging. Als een salesmanager via een drill-through-pagina toch bij data van klanten buiten zijn portefeuille kan komen, is de RLS niet volledig doorgevoerd op alle tabellen in het model. RLS-filters moeten worden toegepast op dimensietabellen zodat ze via de modelrelaties automatisch propageren naar alle gerelateerde facttabellen. De juiste P&L per klant-structuur vereist dat klantfilters consistent doorwerken op alle gerelateerde datalagen.

Wil je weten hoe rolgebaseerde toegang werkt in jouw winstgevendheidsdashboard?

Kimura configureert het vier-rollenmodel standaard als onderdeel van elk winstgevendheidsdashboard. De RLS-configuratie is ingebouwd in het Kimura Data Framework en aanpasbaar zonder technische herbouw. Met de Profit Insight Scan beoordelen we de huidige situatie en stellen we vast welk rolmodel het beste aansluit bij de governance-structuur van jouw organisatie.

Plan een vrijblijvend gesprek en ontdek hoe een goed geconfigureerd winstgevendheidsdashboard de juiste data bij de juiste mensen brengt.