Een goed data platform: waarom het loont en waarom integratie meer is dan ETL

Elke organisatie heeft haar data verspreid over systemen: een ERP, een CRM, een webshop, een HR-systeem, een planningstool en een flink aantal Excel-bestanden. Op zich is dat geen probleem. Het probleem ontstaat zodra iemand een vraag stelt die over meer dan één systeem gaat. Hoeveel omzet maken we per klant, inclusief retouren en servicekosten? Dan blijkt dat de klant in het CRM anders heet dan in het ERP, dat de retouren in een apart systeem staan en dat de servicekosten in een spreadsheet worden bijgehouden. Drie mensen zijn een week bezig en het antwoord klopt net niet.

Een data platform is de plek waar dat probleem structureel wordt opgelost. In dit stuk leggen we uit wat het uw organisatie oplevert, waarom ‘integratie’ meer is dan de nachtelijke dataverwerking die de meeste mensen ervan kennen en welke afspraken u moet maken voordat de techniek gaat helpen.

Wat een data platform is, zonder techniek

Denk aan een distributiecentrum. Goederen komen binnen van tientallen leveranciers, elk met eigen dozen, labels en pallets. Bij de ingang worden ze gecontroleerd, van een standaardlabel voorzien en op een vaste plek gelegd. Vanaf dat moment weet iedereen in het gebouw wat er ligt, hoeveel en van wie. De winkels bestellen bij het distributiecentrum, niet bij de afzonderlijke leveranciers.

Een data platform doet hetzelfde met data. De bronsystemen zijn de leveranciers. Het platform controleert wat binnenkomt, geeft het één betekenis (een ‘klant’ is overal dezelfde klant) en legt het klaar voor wie het nodig heeft: rapportages, andere applicaties en, steeds vaker, AI-toepassingen. De databases, pipelines en cloud-diensten die daarvoor nodig zijn, zijn het gebouw en de stellingen. Nuttig, maar het platform wordt pas waardevol door de afspraken over labels, controle en eigenaarschap.

Wat het de business oplevert

Minder discussie over cijfers. Wanneer omzet, marge en klantaantallen op één plek en volgens één definitie worden berekend, verdwijnt het bekende overleg waarin drie afdelingen elk een ander getal meenemen. Beslissingen gaan sneller omdat het gesprek over de inhoud gaat en niet over wie het juiste bestand heeft.

Nieuwe vragen sneller beantwoord. Zolang elke vraag betekent dat iemand data uit vier systemen moet bij elkaar knippen, kost een nieuwe analyse weken. Staat de data eenmaal gestandaardiseerd op het platform, dan is een nieuwe rapportage of een nieuw model een kwestie van dagen. De winst zit niet in de eerste vraag, maar in de tiende.

Herkomst is aantoonbaar. De AVG, de EU AI Act en uw eigen accountant willen weten waar een cijfer vandaan komt en wie er verantwoordelijk voor is. Op een goed ingericht platform is dat na te lopen (data lineage) in plaats van te reconstrueren uit e-mails.

Een fundament voor AI. Een AI-model dat op tegenstrijdige of onvolledige data wordt getraind, geeft zelfverzekerde verkeerde antwoorden. Een platform met gecontroleerde, eenduidige data is de voorwaarde om AI verder te brengen dan een pilot. Wij schreven eerder over wat de EU AI Act daarin van u vraagt.

Minder afhankelijk van individuen. Veel organisaties draaien op één collega die weet hoe de exports werken. Een platform legt die kennis vast in afspraken en processen in plaats van in één hoofd.

Interoperability volgens DAMA: meer dan ETL

In het DAMA-wiel, het referentiemodel voor data management, heet dit kennisgebied Data Integration & Interoperability. Die twee woorden zijn bewust gekozen. Integratie is data van A naar B brengen. Interoperability is dat systemen elkaar ook begrijpen: dat ‘orderdatum’ in het ene systeem hetzelfde betekent als in het andere.

De meeste mensen kennen één vorm: ETL. Elke nacht wordt data uit de bronsystemen opgehaald (Extract), omgezet naar een gezamenlijk formaat (Transform) en in het data warehouse geladen (Load). Dat is de vrachtwagen die één keer per dag rijdt. Prima voor management reporting en de maandafsluiting, ontoereikend voor veel andere situaties. DAMA rekent daarom meerdere patronen tot dit gebied:

• Batch (ETL en ELT). De vrachtwagen op vaste tijden. Betrouwbaar en goedkoop, maar de data is meestal uren oud.
• Streaming en Change Data Capture (CDC). De lopende band. Elke wijziging in een bronsysteem wordt direct doorgegeven. Nodig voor fraudedetectie, voorraadbeheer en klantenservice, waar een antwoord van gisteren te laat is.
• Applicatie-integratie via API’s. De balie. Een systeem vraagt iets aan een ander systeem en krijgt op dat moment antwoord. De webshop vraagt het ERP: is dit artikel op voorraad?
• Events en messaging. De bel die gaat als er iets verandert. Een systeem meldt ‘order geplaatst’, en elk systeem dat daarin geïnteresseerd is (facturatie, logistiek, het data platform) handelt daar zelf op. Zender en ontvanger hoeven elkaar niet te kennen.
• Virtualisatie en federatie. Het raam. U kijkt in een ander systeem zonder de data te verhuizen. Handig als kopiëren niet mag of niet loont.
• EDI (Electronic Data Interchange). De standaardenvelop tussen bedrijven. Orders, pakbonnen en facturen reizen in een vast berichtformaat (EDIFACT, X12 en voor e-facturatie steeds vaker UBL via Peppol) tussen u en uw leveranciers of klanten. Weinig zichtbaar, maar in retail, logistiek en productie de ruggengraat van de keten.
• Bestandsuitwisseling en replicatie. Nog altijd gangbaar: een leverancier levert een bestand, of een database wordt één op één gespiegeld.

Geen van deze patronen is beter dan de andere. Ze passen bij verschillende vragen: hoe snel moet de data er zijn, hoeveel is het en wie heeft het initiatief. Een volwassen platform gebruikt er meestal vier of vijf naast elkaar.

Waarom applicatie-integratie een goed startpunt is

De meeste dataproblemen ontstaan niet in het data warehouse, maar op het moment dat twee applicaties met elkaar praten. De webshop stuurt een order naar het ERP. Het CRM geeft een adreswijziging door aan de facturatie. Op precies die momenten wordt bepaald wat een ‘klant’, een ‘order’ of een ‘product’ is en in welke vorm die informatie reist.

Wie die uitwisselingen standaardiseert, lost het probleem bij de bron op. Eén afgesproken orderbericht met eenduidige velden betekent dat facturatie, logistiek en het data platform alle drie hetzelfde ontvangen. Het alternatief, elk systeem zijn eigen variant laten sturen en het data warehouse achteraf laten opruimen, werkt tijdelijk en wordt elk jaar duurder. Vergelijk het met een distributiecentrum dat leveranciers vraagt om standaardpallets in plaats van elke levering zelf om te pakken. Tussen bedrijven is dat idee al decennia normaal: EDI werkt alleen omdat beide partijen hetzelfde berichtformaat afspreken voordat er één order wordt verstuurd. Binnen de eigen organisatie wordt die discipline vaak overgeslagen.

Applicatie-integratie is daarmee de eerste laag van het data platform. De definities en afspraken die u daar maakt, erft de rest van het platform.

Architectuurprincipes die het verschil maken

Geen technische keuzes, maar afspraken die u als organisatie vastlegt en handhaaft.

Eén definitie per begrip. Voordat een systeem data doorgeeft, is afgesproken wat de begrippen betekenen. ‘Actieve klant’, ‘netto-omzet’ en ‘leverdatum’ hebben één definitie, vastgelegd in een business glossary, met een eigenaar die de definitie mag wijzigen.

Losse koppeling. Systemen praten met elkaar via afgesproken interfaces, niet door in elkaars database te kijken. Vervangt u het CRM, dan hoeft alleen de koppeling aangepast te worden, niet elk systeem dat klantdata gebruikt.

Bij de bron oplossen, niet achteraf repareren. Een fout adres wordt gecorrigeerd in het systeem waar het is ingevoerd, niet in twaalf rapportages die er gebruik van maken.

Het patroon volgt de vraag. Kies batch, streaming, API of events op basis van het tempo dat het proces vraagt. Alles real-time maken is duur en zelden nodig; alles nachtelijk verwerken maakt snelle processen onmogelijk.

Elke datastroom heeft een eigenaar. Eén persoon, geen afdeling, die weet wat er doorheen gaat, wie ervan afhankelijk is en wat er gebeurt als het stopt.

Herkomst is zichtbaar. Van elk cijfer op het platform is na te gaan uit welke bron het komt en welke bewerkingen het heeft ondergaan. Die zichtbaarheid houdt het vertrouwen in het platform in stand, en de auditor profiteert mee.

Bouw voor hergebruik. Een datastroom wordt één keer aangelegd en door meerdere afnemers gebruikt. Dat is ook het idee achter data products: één levering met een eigenaar en een contract, in plaats van een nieuwe export per vraag.

Waar te beginnen

Niet met een platform-selectie en niet met een programma van drie jaar. Kies één proces waar de pijn zichtbaar is: een cijfer waar twee afdelingen over discussiëren, of een handmatige export die elke week terugkomt. Breng in kaart welke systemen erbij betrokken zijn en waar de definities uiteenlopen. Spreek per begrip één definitie af, standaardiseer die ene uitwisseling tussen de applicaties en sluit die aan op het platform. Meet wat het oplevert: hoeveel uur handwerk verdwijnt, hoeveel discussie.

Het tweede proces gaat sneller. Vanaf het derde wordt de aanpak een patroon, en dan is er een data platform ontstaan zonder dat iemand het zo heeft aangekondigd.

Meer over hoe cimt dit aanpakt leest u bij Data Integration & Streaming en Data Architecture & Lakehouse. Wilt u weten waar uw organisatie staat op dit gebied? De DAMA maturity assessment geeft in een half uur een eerste beeld van uw positie op integratie en de andere kennisgebieden. Of bespreek uw situatie direct met een van onze consultants.