Data engineering voor het mkb: wat het is en wat je nodig hebt

Wat is data engineering in gewone taal?

Data engineering is het bouwen en onderhouden van de leidingen waar je bedrijfsgegevens doorheen stromen. Je boekhouding, CRM, webshop en urenregistratie houden elk hun eigen gegevens bij. Data engineering zorgt dat die gegevens op vaste momenten worden opgehaald, worden opgeschoond, op elkaar aansluiten en klaarstaan voor wie ze nodig heeft: een dashboard, een automatisering of een collega.

Je kunt het vergelijken met het leidingwerk in een gebouw. Niemand komt binnen voor de leidingen, maar zonder werkt de kraan niet. Een dashboard is de kraan. Data engineering is wat ervoor zorgt dat er schoon water uitkomt, elke keer.

Veel mkb-bedrijven doen al een vorm van data engineering, alleen met de hand. Iemand exporteert elke maandag een lijst uit de boekhouding, plakt die naast een export uit het CRM en zoekt met VERT.ZOEKEN de klantnummers bij elkaar. Dat is precies het werk dat data engineering automatiseert.

Wat is het verschil tussen data engineering en Power BI?

Power BI is het rapport: de grafieken, tabellen en filters waar je naar kijkt. Data engineering is alles wat daaronder ligt. Power BI kan zelf ook gegevens ophalen en bewerken, en voor een eenvoudig rapport op één bron is dat prima.

Het wordt lastig zodra je meerdere bronnen combineert, historie wilt bewaren of dezelfde cijfers in meerdere rapporten gebruikt. Dan zit de logica verspreid over losse rapporten, en krijg je vroeg of laat twee versies van dezelfde omzet. Met data engineering haal je die logica uit het rapport en zet je hem op één plek eronder. Het rapport wordt eenvoudiger en de cijfers kloppen overal hetzelfde.

Wanneer die stap de moeite waard is, lees je uitgebreider in ons artikel datawarehouse voor het mkb: wanneer wel en wanneer niet.

Waar bestaat data engineering voor een mkb'er uit?

Voor een mkb-bedrijf komt data engineering neer op vier onderdelen. Ze zijn alle vier nodig, maar ze hoeven niet groot te zijn.

1. Bronnen ontsluiten. Koppelingen die gegevens ophalen uit je pakketten, meestal via een API, soms via een database of een bestand. Hier spelen vragen als: hoe vaak haal je op, wat doe je als een pakket even niet bereikbaar is, en wat als de leverancier iets aan de API verandert?
2. Opslaan en ordenen. Een centrale database waar de opgehaalde gegevens landen. Daar leg je vast hoe tabellen heten, welke sleutels klanten en producten aan elkaar knopen en welke historie je bewaart.
3. Definities en bewerkingen. De afspraken over wat een getal betekent. Is omzet inclusief of exclusief creditnota's? Wanneer telt een klant als actief? Die regels schrijf je één keer uit, in de datalaag, in plaats van in elk rapport opnieuw.
4. Kwaliteit en bewaking. Controles die opvallen als er iets mist, dubbel staat of vreemd afwijkt, en een melding naar iemand die het oplost. Zonder dit onderdeel merk je pas dat een koppeling stil ligt als iemand in een vergadering zegt dat de cijfers niet kloppen.

Samen vormen deze onderdelen wat we een datafundament noemen. Hoe dat in elkaar steekt, lees je in wat is een datafundament.

Wat heb je als mkb'er écht nodig, en wat niet?

Zoek je op data engineering, dan kom je al snel termen tegen als data lake, streaming, Spark en lakehouse. Die zijn bedoeld voor organisaties met enorme hoeveelheden gegevens of gegevens die per seconde binnenkomen. Voor de meeste mkb-bedrijven is dat niet de situatie.

Wat je doorgaans wel nodig hebt:

• Koppelingen met de drie à vijf pakketten waar je belangrijkste cijfers in staan.
• Eén centrale database van bescheiden omvang. Een gangbare SQL-database is ruim voldoende voor de gegevens van een gemiddeld mkb-bedrijf.
• Een ververs-ritme dat past bij de vraag. Voor de meeste rapportages is één keer per nacht of een paar keer per dag genoeg.
• Een korte lijst vastgelegde definities voor je kernbegrippen.
• Bewaking met meldingen, en een afspraak over wie erop reageert.
• Documentatie, zodat je niet afhankelijk bent van één persoon die weet hoe het werkt.

Wat je meestal niet nodig hebt:

• Een eigen datateam in loondienst.
• Realtime gegevens voor rapportages waar je één keer per week naar kijkt.
• Elke tabel uit elk pakket "voor het geval dat".
• Een platformkeuze voordat je weet welke vraag je wilt beantwoorden.

De vuistregel: begin bij de vraag, niet bij de techniek. De techniek die je kiest, moet passen bij hoeveel bronnen je hebt, hoe vaak het moet verversen en wie het straks onderhoudt.

Een voorbeeld: data engineering bij een groothandel van 25 mensen

Een fictief, maar herkenbaar voorbeeld. Een groothandel met zo'n 25 medewerkers verkoopt via een webshop en via buitendienst. De omzet staat in de boekhouding, de webshoporders in het webshopplatform en de klantafspraken in het CRM. De directeur wil elke maandag weten welke klanten minder bestellen dan vorig jaar, zodat de buitendienst ze kan bellen.

Nu kost dat de office manager elke maandagochtend twee uur Excel-werk. En als zij op vakantie is, gebeurt het niet.

Zo pak je het aan met data engineering op mkb-formaat:

1. De vraag scherp maken. "Welke klanten bestellen de afgelopen twaalf weken minder dan in dezelfde periode vorig jaar?" Daarmee weet je welke gegevens nodig zijn: orders, factuurregels en klanten.
2. Drie koppelingen bouwen. Elke nacht worden klanten, facturen en orders opgehaald uit boekhouding, webshop en CRM en in de centrale database gezet.
3. Klanten aan elkaar knopen. Eén koppeltabel legt vast welk webshopaccount en welk CRM-bedrijf bij welk debiteurnummer horen. Hier zit vaak het meeste werk, want elk systeem noemt een klant net anders.
4. Definities vastleggen. Omzet is exclusief btw en inclusief creditnota's. Een klant telt als "dalend" bij meer dan 20 procent minder omzet dan vorig jaar. Die regels staan één keer in de database.
5. Bewaking inrichten. Komen er 's nachts geen nieuwe orders binnen of valt een koppeling uit, dan krijgt de beheerder een mail.
6. Het rapport erop zetten. Pas nu komt er een Power BI-rapport met de lijst dalende klanten, gesorteerd op omzetverschil.

Het resultaat is geen groot dataplatform. Het is een handvol koppelingen, een kleine database en één rapport. Maar het draait elke week vanzelf, de cijfers kloppen met de boekhouding en de volgende vraag (marge per klant, bijvoorbeeld) bouw je op hetzelfde fundament. Hoe je zo'n eerste traject in vier weken plant, staat in van Excel naar een datafundament in 30 dagen.

Doe je data engineering zelf of besteed je het uit?

Dat hangt vooral af van wie het daarna onderhoudt. Bouwen is één ding; koppelingen blijven werk vragen, omdat pakketten updates krijgen, velden veranderen en er nieuwe vragen bijkomen.

• Zelf doen kan als je iemand in huis hebt met kennis van SQL en API's, die er structureel tijd voor krijgt. Het risico is dat alles in één hoofd zit.
• Uitbesteden ligt voor de hand als die kennis er niet is of als je het eerste fundament snel en goed wilt neerzetten. Let er dan op dat je documentatie krijgt en dat de opzet zo is dat een ander het kan overnemen.
• Een mix komt veel voor: een externe partij bouwt het fundament en de lastige koppelingen, een eigen medewerker beheert de rapporten en kleine aanpassingen.

Welke route je ook kiest: spreek vooraf af wie een melding krijgt als er iets misgaat. Dat is het onderdeel dat het vaakst wordt vergeten.

Hoe begin je met data engineering?

Schrijf de één of twee vragen op die nu het meeste handwerk of discussie opleveren. Zet erbij uit welke pakketten de gegevens komen, hoe vaak je het antwoord nodig hebt en of je historie wilt kunnen terugzien. Met dat lijstje is snel duidelijk hoe groot de eerste stap moet zijn.

Bij Celsius BI bouwen we precies dit fundament onder data engineering: koppelingen, de centrale database, definities en bewaking. Welke pakketten we al kunnen ontsluiten, zie je bij onze koppelingen. De rapporten erbovenop vallen onder dashboarding, en hoe een traject in fases verloopt staat bij onze werkwijze.