Je data stroomt elke nacht vanzelf van bron naar rapportage.

Ergens in je organisatie draait een script dat elke nacht data ophaalt. Het is geschreven door een collega die inmiddels iets anders doet, het staat op een oude laptop onder een bureau en niemand weet precies wat het doet. Zolang het werkt, is er niets aan de hand. Tot de ochtend dat het dashboard leeg is, de laptop uit blijkt te staan en niemand weet waar hij moet beginnen met zoeken.

Wat een datapipeline eigenlijk is

Een datapipeline is niets meer dan een vaste route voor je data. Ophalen bij de bron, controleren of het compleet is, omzetten naar een bruikbare vorm en wegschrijven op de plek waar je rapportage of applicatie het verwacht. Het verschil met een los script is dat elke stap vastligt, wordt gelogd en opnieuw kan draaien als er iets misgaat. Draait een run twee keer, dan staat er niet ineens twee keer zoveel omzet in je database.

Per bron bepalen we hoe vaak de data moet verversen. De boekhouding eens per nacht is vaak genoeg. Het kassasysteem of de webshop elk kwartier. Sensordata uit een machine of een gebouw komt continu binnen en vraagt om een andere aanpak, die we samen met een IoT-dataplatform inrichten. Een pipeline die zeven keer per dag draait terwijl niemand voor het middaguur naar de cijfers kijkt, kost alleen maar serverruimte.

Fouten zien voordat iemand erop stuurt

Het gevaarlijkste dashboard is niet het lege dashboard, maar het dashboard dat vol staat met cijfers die net niet kloppen. Een webshopexport die een dag mist, een leverancier die het formaat van zijn prijslijst aanpast, een veld dat sinds een update leeg binnenkomt. Een los script merkt daar niets van. Het schrijft weg wat het krijgt en de rapportage ziet er de volgende ochtend gewoon normaal uit.

Daarom bouwen we controles in bij elke run. Komen er minder rijen binnen dan gisteren om deze tijd? Staan er dubbele ordernummers in? Ligt een datum in de toekomst? Bij een afwijking stopt de pipeline, blijft de oude data staan en krijgt de juiste persoon een melding met wat er precies fout ging. Liever een waarschuwing om acht uur dan een verkeerde marge op de directietafel om tien uur. Blijkt de bron zelf structureel vervuild, dan lost een pipeline dat niet op en pakken we het bij de wortel aan met Master data & opschonen.

Binnen tien werkdagen de eerste pipeline

We beginnen niet met een overzicht van al je bronnen. We pakken de datastroom die nu de meeste tijd kost of het vaakst kapot gaat. We kijken mee met de collega die het script nu draait of het bestand nu overzet, en we bouwen binnen tien werkdagen een pipeline die precies dat werk overneemt. Jij legt de uitkomst naast de cijfers die je al had, tot ze overeenkomen. Pas dan gaat de oude route uit.

Vanuit die eerste pipeline breiden we uit, bron voor bron. Waar de data naartoe gaat, hangt af van wat je ermee wilt. Voor een handvol rapportages is een gewone database genoeg en sluiten we aan op Data & rapportage. Komen er veel bronnen bij, of wil je jaren aan historie kunnen bevragen, dan richten we de bestemming in als Datawarehouse & lakehouse. Wat het ook wordt, we vertellen je dat direct, zodat je niet iets groots koopt voor iets kleins.

Draait bij jou, in jouw omgeving

Een pipeline hoort niet op een laptop te draaien. We zetten hem in onze beheerde omgeving binnen de EU of op je eigen server, met een planner die hem op tijd start en een logboek dat je zelf kunt lezen. De code en de configuratie zijn van jou. We gebruiken standaardtechnieken die elke ontwikkelaar kent, zodat je niet aan ons vastzit. Vertrekt de collega die er het meest mee werkt, dan ligt de documentatie van elke stap klaar voor zijn opvolger.

Je bedrijfsdata blijft van jou en blijft binnen de EU, en we regelen de toegang zo in dat de pipeline alleen de tabellen ziet die hij nodig heeft. Bevat de data persoonsgegevens, dan nemen we de bewaartermijnen en de rechten direct mee in de inrichting. Wil je die afspraken ook op papier hebben en bijhouden wie welke data mag zien, dan is Data-governance de logische volgende stap.