Datawarehouse voor het mkb: wanneer wel en wanneer niet

Wat is een datawarehouse eigenlijk?

Een datawarehouse is een aparte database waarin je gegevens uit je verschillende systemen samenbrengt, opschoont en bewaart, speciaal om op te rapporteren. Je boekhouding, CRM en urenregistratie blijven gewoon hun werk doen. Het datawarehouse haalt er op vaste momenten de gegevens uit en zet ze in een vorm waar je rapporten op kunt bouwen.

Het woord klinkt groot, maar het principe is eenvoudig. Het verschil met een export naar Excel is dat het automatisch gaat, dat de logica op één plek staat en dat je historie opbouwt. In ons artikel wat is een datafundament zie je hoe dat past in het grotere geheel van bronnen, koppelingen, een datalaag en vaste definities. Het datawarehouse is in dat plaatje de datalaag.

Wanneer heb je als mkb'er géén datawarehouse nodig?

Eerlijk is eerlijk: lang niet elk bedrijf heeft er nu iets aan. Je kunt het voorlopig laten zitten als het volgende grotendeels klopt:

• Je rapporteert uit één systeem. Al je belangrijke cijfers komen uit je boekhouding, en daar zit een rapportage of directe Power BI-koppeling op die doet wat je wilt.
• Je kijkt vooral naar de stand van nu. Je hebt geen behoefte aan vergelijkingen met vorig jaar die het pakket zelf niet kan maken.
• Er is één rapport en één gebruiker. De logica zit in dat ene rapport, en dat is overzichtelijk.
• De cijfers kloppen en niemand discussieert erover. Er zijn geen twee versies van de omzet in omloop.

In die situatie is een directe koppeling tussen je pakket en je dashboard vaak genoeg. Hoe dat werkt, lees je in Power BI koppelen aan je boekhouding. Een datawarehouse toevoegen is dan extra onderhoud zonder duidelijke winst.

Wanneer heb je wél een datawarehouse nodig?

De omslag komt meestal niet door de hoeveelheid data, maar door de vragen die je wilt beantwoorden. Deze signalen zien we het vaakst:

1. Je combineert gegevens uit meerdere systemen. Marge per klant vraagt om omzet uit de boekhouding, uren uit de planning en kansen uit je CRM. Elk systeem noemt een klant anders. Die gegevens moeten ergens worden samengevoegd, en dat lukt slecht in losse rapporten.
2. Je wilt historie die je pakket niet bewaart. Veel systemen tonen alleen de huidige stand. Hoe groot was de pijplijn drie maanden geleden? Hoeveel openstaande facturen had je eind vorig kwartaal? Als je dat niet zelf vastlegt, is het weg.
3. Meerdere rapporten gebruiken dezelfde cijfers. Finance, sales en directie kijken elk naar omzet. Zit de definitie in elk rapport apart, dan krijg je vroeg of laat drie verschillende getallen.
4. Je rapporten worden traag of breken bij elke wijziging. Als een dashboard bij het verversen alle ruwe gegevens moet ophalen en omrekenen, merk je dat aan de snelheid. Een wijziging in een bronpakket breekt dan ook direct je rapport.
5. Je wilt de gegevens ook voor iets anders gebruiken. Bijvoorbeeld voor een automatisering of een AI-toepassing die op dezelfde schone klantgegevens moet draaien als je rapporten.

Herken je twee of meer van deze punten, dan is een centrale datalaag waarschijnlijk de moeite waard.

Hoe zwaar moet een datawarehouse voor het mkb zijn?

Hier gaat het vaak mis. Bij "datawarehouse" denken mensen aan een groot project met dure licenties en een eigen IT-afdeling. Voor de meeste mkb-bedrijven is dat niet nodig. Er zijn grofweg drie niveaus:

• Directe koppeling. Het dashboard haalt de gegevens rechtstreeks uit de bron. Snel opgezet, maar geen historie en de logica zit in het rapport.
• Lichte centrale database. Een eenvoudige database waar koppelingen de gegevens uit je bronnen in zetten, met een paar vaste tabellen voor klanten, omzet en andere kernbegrippen. Je bouwt historie op en de definities staan op één plek. Voor veel mkb-bedrijven is dit het juiste startpunt.
• Volwaardig datawarehouse. Meerdere lagen (ruw, opgeschoond, rapportageklaar), uitgebreide controles en veel bronnen. Zinvol als je organisatie groeit, je veel bronnen hebt of strenge eisen stelt aan herleidbaarheid.

Het mooie is dat het tweede niveau kan doorgroeien naar het derde. Je hoeft vandaag dus niet te kiezen voor iets wat je over vijf jaar misschien nodig hebt. Begin met één vraag en bouw van daaruit verder.

Een voorbeeld: van drie losse rapporten naar één datalaag

Een fictief, maar herkenbaar voorbeeld. Een technisch dienstverlener met zo'n veertig medewerkers heeft drie Power BI-rapporten: een voor finance op de boekhouding, een voor sales op het CRM en een voor de planning op de urenregistratie. Elk rapport haalt zijn gegevens direct uit het eigen pakket.

Dat werkt, tot de directie wil weten welke klanten het meest opleveren na aftrek van uren. Dan blijkt dat klantnummers in het CRM niet overeenkomen met debiteurnummers in de boekhouding, en dat de urenregistratie projecten gebruikt in plaats van klanten. Iemand gaat het in Excel aan elkaar knopen.

De oplossing is geen groot project, maar een lichte centrale database:

1. Koppelingen halen elke nacht klanten, facturen, kansen en uren op uit de drie pakketten.
2. Eén koppeltabel legt vast welk CRM-account bij welk debiteurnummer en welke projecten hoort.
3. Omzet, uren en marge worden één keer gedefinieerd, in de database.
4. De drie bestaande rapporten worden omgezet naar deze ene bron, en er komt een vierde rapport bij met marge per klant.

Er is daarna nog steeds geen enorm datawarehouse, maar wel één plek waar de cijfers kloppen en waar historie wordt opgebouwd. Hoe je zo'n traject in vier weken opzet, lees je in van Excel naar een datafundament in 30 dagen.

Welke fouten zie je vaak bij een datawarehouse in het mkb?

• Beginnen bij de techniek. Eerst een platform kiezen en dan bedenken wat je ermee wilt. Begin bij de vraag die je wilt beantwoorden; de techniek volgt daaruit.
• Alles tegelijk inladen. Elke tabel uit elk pakket ophalen "voor het geval dat". Dat maakt het traag, duur in onderhoud en onoverzichtelijk. Haal op wat je nodig hebt.
• Definities overslaan. Een datawarehouse met drie versies van omzet lost niets op. De afspraak over wat een getal betekent is net zo belangrijk als de techniek.
• Geen eigenaar en geen bewaking. Koppelingen kunnen stoppen als een bronpakket iets wijzigt. Spreek af wie een melding krijgt en wie het oplost.

Hoe begin je, als je denkt dat je er een nodig hebt?

Schrijf de één of twee vragen op die nu de meeste tijd kosten of tot de meeste discussie leiden. Zet erbij uit welke systemen de gegevens komen en of je historie nodig hebt. Met dat lijstje kun je vrij snel inschatten welk niveau past.

Het bouwen van de koppelingen en de centrale database is wat wij onder data engineering verstaan. Voor de rapporten erbovenop kun je kijken bij dashboarding, en welke pakketten we al kunnen ontsluiten zie je bij onze koppelingen. Hoe een traject in fases verloopt, staat bij onze werkwijze.