De echte waarde van Power BI

Een serie blogs over Excel en Power BI.

BLOG – De grootste problemen bij de ontwikkeling van grote ICT projecten zijn de benodigde doorlooptijd en de hoeveelheid mislukte projecten. Deze vraagstukken koppel ik aan de vraag waar de werkelijk waarde van Business Intelligence ontstaat. Om de beantwoording van deze vraag vorm te geven, maak ik gebruik van het vijflagen model voor Business Intelligence: delen, visualiseren, verbinden, voorbereiden en analyseren. 

Door Henk Vlootman, adviseur, trainer, spreker en auteur, en topspecialist op het gebied van Microsoft Power BI en Power Query.

Laat ik maar gelijk met de deur in huis vallen. De werkelijke waarde van Business Intelligence voor een organisatie is gelegen in de bovenste twee lagen van dit model: visualisatie en delen. De onderste drie lagen (verbinden, voorbereiden en analyseren) heb je traditioneel nodig voordat je toekomt aan de waarde vermeerdering. Met name de laag verbinden (lees: de database) vormt het probleem.

Vreemd genoeg heeft dit probleem alles te doen met relaties. Voor diegene die meer willen weten over hoe relaties werken, lees dan mijn vorige blog. Wat ik in die blog niet vertel is het verschil tussen relaties in SQL Server bedrijfsdatabases en in Power BI. Maar die verschillen zijn essentieel voor het ontwikkelen van complexe ICT projecten.

Power BI maakt net als SQL server gebruik van relaties. Zeker weten. Maar beide type relaties verschillen hemelsbreed van elkaar. Een relatie in SQL Server wordt berekend en heeft daardoor beperkingen. Dit type relatie heeft een statisch karakter. Je legt deze in de onderste laag, verbinden. In Power BI (en ook Power Pivot in Excel) leg je relaties in de derde laag analyseren. Deze laag ligt direct onder de lagen, die de waarde voor de organisatie creëren. Ooit heb ik gevraagd aan een Microsoft Program Manager hoe relaties in Power BI werken in vergelijk met SQL server. Zijn reactie was duidelijk: de werking is een trade secret van Microsoft. Hoe relaties in Power BI werken weet ik dus niet, maar ze zijn wel aantoonbaar een stuk sneller en flexibeler dan relaties in SQL. Voor mij geldt: doe mij maar relaties in Power BI.

 
Voordat een SQL Datawarehouse (DWH) waarde gaat opleveren worden eerst alle relaties binnen het project bedacht en aanbracht, zodat die relaties kunnen worden berekend. Dat is de reden waarom het bouwen van een DWH over het algemeen lang duurt. Naar mate het in kaart brengen van (alle relaties tussen) de tabellen complexer wordt, heb je meer doorlooptijd nodig. Een jaar is niets, maar doorlooptijden van drie jaar of langer is ook niet vreemd. Hoe gaat het ondertussen met het commitment van de business managers in dit soort langdurige projecten? De tijd verstrijk, maar ze zien geen toegevoegde waarde. Als je alle data vooraf moet overzien, zie je de meest vreemdsoortige modellen ontstaan. Er bestaan veel abstracte gedachte methoden om alleen die eerste laag in de hand te houden. De conclusie is dat, horizontaal gezien, veel energie wordt gestoken in de onderste laag verbinden. 

Het uiteindelijke resultaat in de laag visualisatie is vaak gebeiteld in steen. Zolang de gewenste nieuwe data niet in die eerste laag verbinden aanwezig is, moet de structuur van het DWH worden aangepast. Dat is heel lastig proces, want die nieuwe data ‘past’ niet in de bestaande structuur van het DWH. Dus kost het aanpassen tijd en kostbare (consultancy) kosten. In de praktijk zie ik vooral dat dit type dashboard handig is, en misschien ook wel speciaal gemaakt, voor de ‘C laag’ van de organisatie. Die dashboards zijn een stuk minder interessant voor een business manager, die graag antwoord krijgt op zijn steeds veranderde business vragen.

Dus de vraag rijst of je initieel zoveel tijd wilt besteden in de laag verbinden, terwijl de werkelijke waarde ligt in de lagen visualiseren en delen. De SQL database bouwer zegt: ‘Natuurlijk. Dit zijn de gebaande en bewezen paden.’ Maar gemakshalve vergeten ze de projecten die mislukt zijn. Projecten die nooit uit die onderste laag zijn gekropen, maar wel miljoenen hebben gekost.

Het alternatief in de laag verbinden heet Data lake. Een Data lake kan, maar hoeft niet, relaties bevatten. Maar een veel belangrijker kwaliteit van een Data lake is de catalogisering van de metadata van tabellen. Je bent in staat om heel snel je data bronnen te vinden. Omdat ik relaties in Power BI, in de derde laag analyse, prefereer, weet je al waar mijn voorkeur naar uit gaan.

Als je in de overweging mee neemt dat de hoeveelheid data explosief stijgt, kan de conclusie zijn dat vraag naar dynamisch aan te passen dashboards stijgt. Misschien wordt het tijd voor een nieuwe, meer eigentijdse, aanpak. Mijn voorstel is dat je de horizontale beweging in de eerste laag omzet in een verticale beweging door alle lagen heen. 

Je wilt zo snel mogelijk naar de bovenste twee lagen, waar de waardecreatie voor de organisatie plaats vindt. Dit betekent dat je anders om moet gaan met BI trajecten. En dat zal in veel organisaties ongetwijfeld weerstand oproepen.

Maar hoe werkt dat proces? Wel, je deelt grote projecten op in kleine, behapbare stukken. Het uitgangsprincipe hierbij daarbij is de vraag van de business. Die vraag zet je zo snel mogelijk om in dashboards. Daarbij hoef je helemaal niet te beschikken over een complete, ingerichte database. Je begint met een bak data in Excel. In heel korte termijn creëer je vervolgens een dashboard. Daarna volgen er een aantal iteraties om het dashboard bij te schaven. Vervolgens heb je een enthousiaste manager en daarmee het gewenste commitment. Pas daarna kijk jij (of een ICT’er) naar de werking in de onderste lagen en het omzetten van de Excel verbindingen naar de database. Een uitermate efficiënte manier van werken. 

In deze manier maak je gebruik van de flexibele relaties waarin Power BI voorziet, die je ‘on the fly’ aanbrengt. Zonder dat je direct relaties van de onderste laag nodig hebt, boor je wel allerlei verschillende data bronnen aan. De snelheid van ontwikkeling is ongekend snel, want je snijdt door de vijf lagen heen.

Natuurlijk is er in de onderste laag nog steeds behoorlijk veel werk te doen, want er zijn op het niveau van de transacties weldegelijk tijd consumerende handelingen noodzakelijk. Maar ook die werkzaamheden verlopen in kleine, overzichtelijke processen. Daarnaast heb je het voordeel dat je gebruik kunt maken van de nieuwste ontwikkelingen binnen de Microsoft familie: DataFlows, Flow en PowerApps, waardoor je stukken minder relaties nodig zijn in de eerste laag. 

De grootste voordelen van het verticaal benaderen van de vijf lagen voor Business Intelligence zijn veel snellere doorlooptijden van het project, meer beheersbaarheid van het project, dynamische dashboards en commitment bij managers. Maar bovenal creëer je heel erg snel waarde in de organisatie.

Blogs in deze serie:

• Excel: Tabellen for sale. Maar welke moet ik kiezen?
• Excel: De kunst van rij in kolom berekeningen
• Explosieve kracht in een cel: aggregaat berekeningen
• De liefdesverklaring van Power Pivot: relaties
• De echte waarde van Power BI
• Schema first of data first? Maar waar is je data?
• Visualiseren, de kunst van het verleiden (1)
• Visualiseren, de kunst van het verleiden (2)
• Low-code of no-code, de weg naar de toekomst (1)
• Low-code of no-code, de weg naar de toekomst (2)
• Controles, levensbloed voor je model (1)