Power BI of Fabric: wat een kmo echt nodig heeft

De vraag komt bijna altijd in dezelfde vorm. Iemand heeft ergens gelezen dat Fabric de opvolger is van Power BI, en wil weten of hij moet overstappen.

Het korte antwoord: Fabric is geen opvolger. Het is iets anders, met een ander prijsmodel, voor een ander soort probleem. En bij de meeste kmo's die het mij vragen, lost het een probleem op dat ze niet hebben.

Het verschil in één alinea

Power BI is de laag waar je je cijfers modelleert en toont. Rapporten, dashboards, een datamodel eronder, gebruikers die erop kijken. Je betaalt per gebruiker.

Fabric is het platform eronder. Opslag, verwerking, pipelines, een lakehouse, notebooks. Je koopt geen gebruikers maar capaciteit, en die capaciteit is er of ze is er niet. Power BI zit er als onderdeel in.

Dat verschil in prijsmodel is het belangrijkste dat je moet begrijpen. Bij Power BI schaalt je kost met het aantal mensen dat kijkt. Bij Fabric schaalt je kost met de capaciteit die je reserveert, los van hoeveel je ervan gebruikt. Voor een grote organisatie is dat voordelig. Voor een kmo met acht mensen die een dashboard openen, is het dat zelden. Controleer trouwens altijd de actuele tarieven, die bewegen.

De klant waar ik het afraadde

Bij een kmo lag Fabric concreet op tafel. Het zou een pak geld kosten, elke maand, voor iets dat ze op dat moment niet nodig hadden.

We hebben het anders opgelost. De data staat in Neon, een gehoste PostgreSQL waar je aan een fractie van de kost aan begint. De verwerking draait in Python, gepland via een gewone scheduler. Power BI zit er bovenop als visualisatielaag. Dat is geen compromis, dat is gewoon de juiste maat voor het volume waar het om gaat.

Ik zeg niet dat Fabric slecht is. Ik zeg dat je het pas nodig hebt als je volume of je organisatie het rechtvaardigt, en dat je dat moment zelf merkt. Je moet er niet naartoe verhuizen omdat het nieuw is.

Het platform is zelden je knelpunt

Hier zit het echte punt. In bijna elk traject dat ik doe, ligt het knelpunt niet bij de tool.

Neem Excel, waar de meeste kmo's vandaan komen. Waarom gaat een Excel-rapport stuk? Zelden door Excel. Wel doordat er meerdere mensen in hetzelfde bestand werken. Doordat iemand een kolom hernoemt. Doordat er geen unieke identificatie in de data zit, zodat je twee lijsten niet betrouwbaar aan elkaar kan koppelen. Doordat iemand het verkeerd opslaat.

Dat zijn allemaal problemen van structuur en afspraken. Die verhuizen gewoon mee naar het volgende platform als je ze niet oplost. Een duurdere tool maakt een slecht datamodel niet beter, ze maakt het alleen sneller slecht.

Datzelfde geldt voor definities. Bij een klant bleek actieve klant drie verschillende dingen te betekenen. De afgesproken definitie was: iemand die in de afgelopen twaalf maanden besteld heeft. Klinkt sluitend. Is het niet, want frequentie zegt veel meer dan het feit dat er ooit iets besteld is. Iemand die elke maand koopt en iemand die één keer per jaar koopt, zijn niet dezelfde klant, en toch vielen ze in dezelfde categorie.

Zulke vragen beslechten kost een namiddag. Ze overslaan kost je een jaar aan rapporten waar niemand op durft te sturen.

Waar je wel te weinig naar kijkt

Er is nog iets dat ik bij bijna elke kmo terugzie, en waar collega's het niet altijd met mij eens zijn.

Er wordt veel te smal gekeken. Boekhoudcijfers, misschien een export uit Odoo, en daarmee is het rond. Alleen zit de essentie vaak helemaal niet in die bronnen.

In retail bijvoorbeeld: passage, dus hoeveel mensen er binnenkomen. Conversie, hoeveel daarvan iets kopen. IPT, het aantal artikelen per transactie. Geen van die drie staat in je boekhouding, en samen verklaren ze je omzet beter dan je omzetcijfer dat zelf doet. Als je omzet daalt, wil je weten of er minder mensen binnenkwamen, of er evenveel binnenkwamen maar minder kochten, of dat ze kochten maar minder per bezoek. Dat zijn drie verschillende problemen met drie verschillende oplossingen.

Wie alleen naar de boekhouding kijkt, ziet dat verschil nooit. En dat is geen platformvraag, dat is een vraag over welke bronnen je binnenhaalt.

Wanneer Fabric wel

Voor de volledigheid, want ik wil niet overkomen alsof ik er tegen ben. Fabric wordt interessant wanneer je meerdere zware databronnen hebt die je echt moet verwerken in plaats van alleen uitlezen, wanneer je met data science aan de slag gaat, of wanneer je genoeg gebruikers hebt dat het licentiemodel kantelt. Dan is het een goede keuze en dan zeg ik dat ook.

Alleen is dat, bij de kmo's waar ik kom, eerder uitzondering dan regel.

Waarom wij eerst bouwen

Dit is ook de reden dat wij de eerste fase gratis doen, en dat is geen commerciële truc. Door te bouwen zie ik waar het misloopt. Welke bron rommelig is, welke definitie niet sluit, waar het echte knelpunt zit.

Dat kan ik niet inschatten in een intakegesprek, en jij kan het mij niet vertellen, want als je het wist had je mij niet nodig. Pas als er iets draait, weten we allebei of er een vervolg moet komen en waar dat dan over gaat. Vaak is dat iets anders dan waar het gesprek mee begon.

De stelling

Kies geen platform voor je weet welke vraag je wil beantwoorden en uit welke bronnen het antwoord moet komen. Negen van de tien keer is je knelpunt je datamodel, je definities of een bron die je nog niet binnenhaalt. Geen van die drie wordt opgelost door een factuur van Microsoft.