Wat is een datawarehouse en heb je er een nodig?

Een datawarehouse is een centrale database waarin data uit je bronsystemen, zoals ERP, CRM en boekhouding, elke nacht wordt verzameld, opgeschoond en historisch bewaard, zodat elk rapport uit dezelfde cijfers put. Voor een mkb-organisatie is het meestal pas nodig vanaf drie of vier bronsystemen, of zodra Power BI alleen te traag, te groot of te onoverzichtelijk wordt.

Die laatste zin ontbreekt in vrijwel elke uitleg van het begrip, en dat is geen toeval. De uitleg komt meestal van de partijen die de opslag verkopen, en die hebben er weinig belang bij om te zeggen dat je het voorlopig nog niet nodig hebt.

Toch is dat voor veel organisaties van vijftig tot vijfhonderd medewerkers het eerlijke antwoord. Daarom staat hieronder eerst wat een datawarehouse is en hoe de architectuur werkt, dan hoe het zich verhoudt tot een data lake en een lakehouse, en daarna de vraag die er echt toe doet: aan welke signalen je ziet dat het tijd wordt, en wat het opzetten dan kost.

Wat is een datawarehouse?

De betekenis van datawarehouse zit al in het woord: een magazijn voor data. Alleen is het geen magazijn waar je dingen neerzet om ze kwijt te zijn, maar een waar je ze neerzet om ze terug te vinden, in dezelfde vorm, ook over drie jaar. Het datawarehouse haalt data uit de systemen waar het werk gebeurt, zet die om naar één structuur met één set definities, en bewaart elke versie.

Het verschil met een gewone database is niet de techniek, maar het doel. De database onder je ERP is gebouwd om snel één order te vinden en te wijzigen. Een datawarehouse is gebouwd om drie jaar aan orders in één keer op te tellen, per klantgroep, per maand, zonder dat iemand in het ERP daar iets van merkt. Het concept is eind jaren tachtig beschreven door Bill Inmon en komt neer op vier eigenschappen die nog steeds gelden:

• Onderwerpgericht. De data is geordend naar onderwerpen waar je op stuurt, zoals klanten, orders en producten, niet naar de applicatie waar ze vandaan komen.
• Geïntegreerd. Een klant uit het CRM en een debiteur uit de boekhouding zijn in het datawarehouse dezelfde klant, met hetzelfde nummer.
• Tijdgebonden. Elke waarde hoort bij een periode. Wat de voorraad op 31 maart was, blijft opvraagbaar, ook als het bronsysteem alleen nog de stand van vandaag kent.
• Niet-vluchtig. Wat er eenmaal in staat, wordt niet overschreven. Er komt een nieuwe versie bij.

Over de schrijfwijze nog dit: in het Nederlands is het één woord, datawarehouse. De Engelse vorm met spatie, data warehouse, wordt in Nederland net zo vaak gebruikt en Google behandelt ze als hetzelfde begrip. Data warehousing is dan weer het werkwoord: het proces van verzamelen, omzetten en laden.

Waarvoor gebruik je een datawarehouse?

Voor stuurinformatie, in de eerste plaats. Business intelligence en een datawarehouse zijn ongeveer even oud en om dezelfde reden ontstaan: de vraag van de directie liet zich niet beantwoorden uit één systeem. In de praktijk levert een datawarehouse drie dingen op die je zonder niet krijgt.

Ten eerste één bron van waarheid. De definitie van omzet staat één keer in het datawarehouse en elk rapport, elke draaitabel en elk exportje gebruikt die. Zonder datawarehouse staat die definitie in elk Power BI-bestand opnieuw, net iets anders, en gaat de maandvergadering over de vraag welk cijfer klopt in plaats van over wat je eraan doet.

Ten tweede historie. De meeste bronsystemen kennen alleen het nu. Wie vraagt hoe de pijplijn er drie kwartalen geleden uitzag, krijgt in het CRM geen antwoord, want die deals zijn inmiddels gewonnen, verloren of verplaatst. Het datawarehouse bewaart de stand van elke dag, en dat is precies wat je nodig hebt om te zien of iets beter wordt.

Ten derde rust in de bronsystemen. Een zware rapportagevraag rechtstreeks op de ERP-database vertraagt de collega’s die op dat moment orders invoeren. In het datawarehouse mag een query best een minuut duren, want niemand wacht erop bij de balie.

Dat betekent ook dat een dashboard zonder deze laag eronder maar kort houdbaar is. Het ziet er de eerste maand goed uit, en daarna wijkt het af van de boekhouding, valt de historie weg of blijkt de marge in het salesrapport anders berekend dan in het financiële. Het fundament bepaalt hoe lang het scherm erboven waarde houdt, niet de vormgeving.

Hoe werkt een datawarehouse? De architectuur in lagen

Vrijwel elke datawarehouse architectuur bestaat uit dezelfde lagen, hoe de leverancier ze ook noemt. Van bron naar scherm:

1. De bronsystemen. ERP, CRM, boekhouding, urenregistratie, webshop, HR-systeem. In het mkb vaak AFAS, Exact Online, Dynamics 365 Business Central, HubSpot of een branchepakket. Hoe je die koppelt, staat in onze artikelen over AFAS en Power BI en Exact Online en Power BI.
2. De laadlaag. Hier wordt data opgehaald, meestal één keer per nacht, en ruw weggeschreven. Dat heet ETL: extraheren, transformeren, laden. In de cloud is de volgorde vaak ELT geworden: eerst ruw laden, dan pas omzetten, omdat het omzetten in het datawarehouse zelf sneller en goedkoper is dan ervoor.
3. De historische laag. Elke wijziging in de bron wordt als nieuwe versie bewaard. Dit is de laag die de vraag “hoe stond het er op 31 maart voor” kan beantwoorden.
4. De datamarts. Per onderwerp een sterschema: één feitentabel met de cijfers, zoals orderregels, en daaromheen dimensietabellen met klanten, producten, datums en medewerkers. Dit is de vorm waar Power BI het snelst en het meest voorspelbaar op werkt, en Microsoft legt in de eigen richtlijnen uit waarom een sterschema de norm is.
5. Het semantisch model en de rapporten. Bovenop de datamart komt een semantisch model met de measures en definities, en daarop de dashboards. Vanaf hier ziet de gebruiker het.

Het hele proces draait ‘s nachts. Het datawarehouse is daarmee de enige collega die elke nacht om drie uur alle cijfers bijwerkt en er ‘s ochtends niet over klaagt.

Wat je hierin niet ziet, is de keuze die het meeste bepaalt: hoe je modelleert. Kimball met sterschema’s, Inmon met een genormaliseerd model, Data Vault voor grote landschappen met veel veranderingen. Voor het mkb is het antwoord vrijwel altijd Kimball: sterschema’s per onderwerp, omdat Power BI daar het beste mee overweg kan en omdat het voor de volgende ontwikkelaar te begrijpen is.

Datawarehouse, data lake, lakehouse en datamart: wat is het verschil?

De termen worden door elkaar gebruikt, terwijl ze vier verschillende dingen zijn:

Datawarehouse, data lake, lakehouse en datamart vergeleken op wat erin zit, wie het gebruikt en wanneer je het kiest

	Wat zit erin	Voor wie	Wanneer
Datawarehouse	Gestructureerde, opgeschoonde tabellen met vaste definities en historie	Rapportage en BI voor de hele organisatie	Zodra meerdere bronnen en meerdere rapporten dezelfde cijfers moeten delen
Data lake	Ruwe bestanden van elk formaat: exports, logbestanden, documenten, sensordata	Data-analisten en -wetenschappers die zelf structuur aanbrengen	Als je data wilt bewaren waarvan je het gebruik nog niet kent
Lakehouse	Opslag als een data lake, met tabellen, transacties en beheer als een datawarehouse erbovenop	Organisaties die rapportage en analyse op één platform willen	Als je beide nodig hebt en niet twee omgevingen wilt onderhouden
Datamart	Een deel van het datawarehouse voor één afdeling of onderwerp	Eén team, zoals finance of sales	Altijd, als bovenste laag van een datawarehouse of lakehouse

Voor de meeste mkb-organisaties is de keuze eenvoudiger dan de tabel doet vermoeden. Er is zelden ongestructureerde data in hoeveelheden die een data lake rechtvaardigen. Wat er wel is, zijn vijf systemen met tabellen die niet met elkaar praten. Dat is een datawarehouse-vraag, en de medallion-architectuur met een bronzen, zilveren en gouden laag die je in Fabric tegenkomt, is niets anders dan de drie lagen hierboven met een nieuwe naam.

Cloud datawarehouse bij Microsoft: Azure, Fabric en Power BI

Tien jaar geleden stond een datawarehouse op een server in de kelder, met een licentie en een beheerder. Dat gebeurt nog, vooral waar de data het pand niet mag verlaten, maar voor het mkb is de cloud de standaard geworden. Niet omdat het hip is, maar omdat je betaalt voor wat je gebruikt en niemand hoeft te patchen.

In het Microsoft-landschap zijn er drie routes voor een cloud datawarehouse, en ze passen bij drie maten:

• Azure SQL Database. Een gewone relationele database in Azure, met de lagen uit de vorige sectie als schema’s erin. Goedkoop, bekend terrein voor elke ontwikkelaar, en voor de meeste organisaties tot enkele honderden gigabytes ruim voldoende. Dit is het klassieke datawarehouse van het mkb.
• Fabric Warehouse of Lakehouse. Microsoft Fabric bundelt opslag, verwerking en Power BI op één capaciteit, met OneLake als gedeelde opslag. Het warehouse spreekt gewoon SQL en Microsoft beschrijft hoe het zich verhoudt tot het lakehouse binnen hetzelfde platform. Dit is wat tegenwoordig een modern datawarehouse heet: opslag en rekenkracht los van elkaar, en rapportage direct erop. Wat zo’n capaciteit kost en wanneer die zich terugverdient, staat in ons artikel over Power BI-licenties.
• Power BI zonder datawarehouse. Voor kleine landschappen kan Power BI zelf de bronnen laden, omzetten en combineren. Dat is geen datawarehouse, maar het doet voor een organisatie met twee bronnen en één ontwikkelaar een tijd lang hetzelfde werk.

De naam op de factuur is bij alle drie belangrijker dan de techniek. Een datawarehouse dat in de Azure-tenant van je BI-partner draait, is van je partner. Waar het staat en op wiens naam, is precies het onderwerp van ons stuk over datasoevereiniteit.

Heb je als mkb-bedrijf een datawarehouse nodig?

Niet vanaf dag één. Het eerste dashboard bouw je meestal rechtstreeks op de bronnen, en dat is verstandig: je weet dan nog niet welke cijfers ertoe doen. Het probleem begint een half jaar later. Er zijn inmiddels vier rapporten, gebouwd door twee mensen, en de marge wordt in elk ervan net iets anders berekend. De historie van de pijplijn is weg, want het CRM overschrijft de fase van een deal. En het verversen duurt inmiddels drie kwartier, omdat elk rapport zelf alle bronnen ophaalt.

Herkenbaar? Dan is dit de lijst waarop je toetst. Twee of meer van deze signalen betekent dat een datawarehouse zich terugverdient:

• Drie of meer bronsystemen die in één rapport samenkomen, met klanten of producten die in elk systeem een ander nummer hebben.
• Dezelfde logica in meerdere rapporten. Zodra de margeberekening in twee Power BI-bestanden staat, lopen ze uit elkaar. Niet misschien, maar zeker.
• Historie die in de bron wordt overschreven. Voorraadstanden, dealfases, personeelsbestand: als je wilt weten hoe het vorig kwartaal was, moet iemand het vastleggen, en dat is het datawarehouse.
• Een model dat te groot of te traag wordt. Boven de grens van een Pro-licentie, of met een verversing die niet meer binnen het venster past, is de goedkoopste oplossing niet een zwaardere licentie, maar het werk verplaatsen naar een laag eronder.
• Meer dan één bouwer. Twee ontwikkelaars zonder gedeelde laag bouwen twee waarheden. Een datawarehouse is de plek waar ze het eens moeten worden.
• Vragen die niet uit één systeem komen. Omzet per medewerker, marge per project, verzuim tegen bezetting: elk daarvan vraagt twee bronnen die elkaar op één sleutel moeten vinden.

Wat geen reden is: de wens om “toekomstbestendig” te zijn, een aanbieding van een platformleverancier, of het feit dat een grotere concurrent er een heeft. Een datawarehouse zonder concrete vraag erachter is een verhuisdoos die niemand uitpakt.

Datawarehouse opzetten: stappen, kosten en wie het bouwt

Denk groot en begin klein. De architectuur uit de vorige secties teken je één keer in zijn geheel, en daarna bouw je die per onderwerp, te beginnen met het onderwerp waar de meeste pijn zit. In vier stappen:

1. Kies één stuurvraag en twee of drie bronnen. Meestal omzet en marge, uit de boekhouding en het ERP. Niet het hele landschap. Welke vraag eerst komt, hoort in je datastrategie te staan; zo niet, dan is dit het moment om die alsnog op één pagina te zetten.
2. Leg de definities vast voordat je laadt. Wat is omzet, wanneer telt een order, welke bron is leidend als twee systemen elkaar tegenspreken. Dit is een middag met finance en het voorkomt maanden herstelwerk.
3. Bouw de eerste datamart en het eerste scherm samen op. Eén sterschema, één semantisch model, één dashboard dat in de eerstvolgende maandvergadering wordt gebruikt. Hoe zo’n eerste scherm eruitziet en wat het kost, staat in ons artikel over een Power BI dashboard laten maken.
4. Voeg per kwartaal een onderwerp toe. Sales, operations, HR: elk op hetzelfde datawarehouse, met dezelfde klant- en datumdimensies. Dat is het moment waarop de investering zich terugbetaalt, want de tweede datamart kost een fractie van de eerste.

De kosten vallen in twee delen uiteen, en ze verhouden zich anders dan de meeste mensen verwachten. De cloudkosten zijn voor een mkb-organisatie het kleinste deel: een Azure SQL Database of een kleine Fabric-capaciteit kost tientallen tot enkele honderden euro’s per maand. Het grootste deel zit in het bouwen en beheren: de koppelingen, het model, de definities en het bewaken dat de nachtelijke lading ook echt gelukt is.

Wie dat bouwt, bepaalt of je er over drie jaar nog iets aan hebt. Een eigen datawarehouse-ontwikkelaar of data engineer is voor de meeste mkb-organisaties een te dure vaste kracht voor te weinig werk. Een freelance datawarehouse-specialist is snel en goed, zolang de kennis niet met de opdracht vertrekt. Een datawarehouse-consultant of BI-partner brengt de ervaring van tien landschappen mee, maar hoort dan wel in jouw tenant te bouwen, met documentatie die een volgende partij kan lezen. De vraag om te stellen is niet wie het het goedkoopst bouwt, maar wie het zo bouwt dat je hem niet nodig hebt om het te begrijpen.

---

Staan jullie cijfers in één datawarehouse waar elk rapport uit put, of in vijf Power BI-bestanden die elk hun eigen waarheid berekenen? Wil je weten of een datawarehouse zich in jouw situatie al terugverdient? Neem contact op, dan lopen we de signalen hierboven samen na.

Veelgestelde vragen