Onlangs zat ik bij een organisatie waar een offerte op tafel lag voor het bouwen van een datawarehouse op basis van Microsoft Fabric.

Op zichzelf is daar niets vreemds aan. Fabric is een krachtig platform en een datawarehouse kan veel waarde toevoegen.

Toch stelde ik eerst een andere vraag:

Welk probleem gaat dit datawarehouse eigenlijk oplossen?

Daar bleek geen duidelijk antwoord op te zijn.

En juist daar begint voor mij het gesprek.

Technologie is niet het vertrekpunt

Bij data- en BI-projecten wordt al snel gesproken over oplossingen.

Een datawarehouse.
Microsoft Fabric.
Power BI.
Een lakehouse.
AI.

Maar voordat je een technologie kiest, moet eerst duidelijk zijn waarom je die nodig hebt.

Welke beslissing wil de organisatie beter kunnen nemen?

Welke informatie ontbreekt daarvoor?

Welke problemen ervaren medewerkers vandaag?

En waarom lossen de huidige systemen of rapportages dat niet op?

Als die vragen nog niet beantwoord zijn, is het moeilijk om te bepalen of een datawarehouse überhaupt de juiste oplossing is.

Kun je de brondata vertrouwen?

Tijdens het gesprek ontstond nog een belangrijker vraagstuk.

De organisatie wist niet zeker of de beschikbare data volledig en betrouwbaar was. Ook waren de processen rondom een aantal bronsystemen niet overal duidelijk.

Dat is belangrijk.

Een datawarehouse kan data uit verschillende systemen verzamelen, structureren en beschikbaar maken. Maar het maakt slechte brondata niet automatisch goed.

Als gegevens niet consequent worden ingevoerd, definities verschillen of processen niet duidelijk zijn, neem je die problemen mee naar het nieuwe platform.

Je krijgt dan misschien een technisch mooier landschap, maar nog steeds geen informatie waarop mensen met vertrouwen kunnen sturen.

Een datawarehouse maakt onbetrouwbare data niet betrouwbaar.

Eerst het fundament

In zo'n situatie zou ik daarom niet beginnen met het bouwen van een groot dataplatform.

Ik zou eerst teruggaan naar de basis.

Welke informatie is al beschikbaar?

Welke data ontbreekt?

Waar zitten problemen in de invoer?

Welke definities worden binnen de organisatie gebruikt?

Welke processen liggen achter die gegevens?

En vooral:

Waar wil de organisatie eigenlijk op sturen?

Dat hoeft niet te betekenen dat je maandenlang moet analyseren voordat je iets kunt doen.

Juist kleine rapportages kunnen in deze fase veel waarde toevoegen.

Door met bestaande data een eerste rapportage te maken, zie je bijvoorbeeld snel:

  • welke gegevens beschikbaar zijn;
  • waar waarden ontbreken;
  • waar definities niet overeenkomen;
  • welke informatie gebruikers werkelijk nodig hebben;
  • welke datakwaliteitsproblemen eerst opgelost moeten worden.

Zo gebruik je Business Intelligence niet alleen om resultaten te presenteren, maar ook om de kwaliteit van je informatievoorziening zichtbaar te maken.

Wanneer is een datawarehouse wel logisch?

Er kan uiteindelijk heel goed blijken dat een datawarehouse de juiste volgende stap is.

Bijvoorbeeld wanneer informatie uit meerdere systemen structureel moet worden gecombineerd, historische gegevens nodig zijn, definities centraal moeten worden vastgelegd of rapportages onafhankelijk moeten worden van bronsystemen.

Maar dan bouw je het datawarehouse vanuit een aantoonbare behoefte.

Niet omdat een leverancier een voorkeur heeft voor een bepaalde technologie.

En niet omdat een modern dataplatform nu eenmaal klinkt als de logische volgende stap.

De technologie volgt uit het probleem. Niet andersom.

Microsoft Fabric kan uitstekend zijn, als het past

Dit is ook geen verhaal tegen Microsoft Fabric.

Fabric kan voor organisaties een uitstekend platform zijn.

Maar dezelfde regel geldt voor Fabric als voor iedere andere technologie:

Het platform moet passen bij de informatiebehoefte van de organisatie.

Een technisch goede oplossing voor het verkeerde probleem blijft de verkeerde oplossing.

Daarom kijk ik liever eerst naar de organisatie. Daarna naar de informatie en processen. Pas vervolgens kijk ik naar de technologie.

De belangrijkste vraag

Voordat je een offerte voor een datawarehouse goedkeurt, zou ik daarom altijd één vraag stellen:

Welk probleem lossen we hiermee op?

Kun je daar geen concreet antwoord op geven?

Dan is het waarschijnlijk nog te vroeg om te bouwen.

Onderzoek eerst welke beslissingen je beter wilt kunnen nemen, welke informatie daarvoor nodig is en of je de onderliggende data kunt vertrouwen.

Van daaruit ontstaat vanzelf een veel beter gesprek over architectuur en technologie.

En soms is de conclusie inderdaad dat je een datawarehouse nodig hebt.

Maar soms ook niet.

Eerlijk advies begint niet met de grootste oplossing. Het begint met begrijpen wat er werkelijk nodig is.