Gegevensintegratie zonder gegevenskerkhof: CDC, event streaming en ETL vergeleken voor ERP, CRM en magazijn

Wie ERP, CRM en magazijnbeheer met elkaar verbindt, wil meestal twee dingen tegelijk: processen moeten doorlopend lopen (bijv. Auftrag → Kommissionierung → Versand → Rechnung), en gegevens moeten voor analyses beschikbaar zijn (bijv. Lieferfähigkeit, Deckungsbeiträge, Retourenquoten). In de praktijk ontstaat daar snel een spanningsveld tussen „Wir brauchen es heute in den Reports“ en „Wir dürfen das produktive ERP nicht destabilisieren“. Juist daar beslist zich, of Datenintegration ohne Datenfriedhof lukt of dat er zich over jaren een onoverzichtelijke mix van CSV-Exports, nächtlichen Jobs, Schatten-Tabellen und ungeklärten Datenkopien ophoopt.

Dieser Beitrag vergleicht drei zentrale Ansätze: ETL (Extract, Transform, Load), CDC (Change Data Capture, also das Erkennen und Übertragen von Datenänderungen) und Event Streaming (Ereignisse als fortlaufender Datenstrom über einen Broker). Der Fokus liegt nicht auf Programmierdetails, sondern auf Architekturfolgen, Betriebsrealität, Datenqualität, Sicherheits- und Rollout-Fragen – so, wie sie in Integrationsprojekten zwischen Unternehmenssystemen tatsächlich auftreten.

Warum Integrationen oft zum Datenfriedhof werden

Ein Datenfriedhof entsteht selten aus bösem Willen. Typische Ursachen sind:

• Unklare Systemgrenzen: ERP ist einmal „führend“, dann doch das CRM, und im Lager gibt es eigene Statuslogik. Ohne festgelegte Datenhoheit (System of Record) werden Konflikte vorprogrammiert.
• Ad-hoc-Anforderungen: „Wir brauchen schnell ein Dashboard“ führt zu Direktzugriffen aufs ERP, später kommen zusätzliche Abfragen, Materialized Views oder Kopien hinzu. Jeder Quick Win verschiebt Betriebslast und Verantwortlichkeiten.
• Fehlende Verträge: Schnittstellenverträge (welche Felder, welche Semantik, welche Versionierung) fehlen. Ergebnis: Schema-Drift – Felder ändern Bedeutung oder Struktur, ohne dass Downstream-Systeme es rechtzeitig merken.
• Kein Betriebskonzept: Jobs laufen „irgendwo“, Credentials liegen in Skripten, es gibt keine Alarmierung bei Datenlücken, und niemand kann beantworten, ob ein Report „vollständig“ ist.

ETL, CDC und Event Streaming lösen unterschiedliche Teile dieses Problems. Entscheidend ist, dass Sie den Ansatz passend zur Prozesskritikalität, Latenzanforderung und Betriebsreife auswählen – und dass Sie den Integrationsweg als Produkt betreiben, nicht als einmaliges Projektartefakt.

Begriffe sauber einordnen: ETL, CDC und Event Streaming

ETL steht für „Extract, Transform, Load“: Daten werden aus Quellsystemen entnommen, umgeformt (bijv. bereinigt, aggregiert, gemappt) und in ein Zielsystem geladen, häufig ein Data Warehouse. Klassisch passiert das batch-orientiert, bijv. nachts oder stündlich.

CDC (Change Data Capture) beschreibt Mechanismen, die Änderungen an Daten erkennen und als Delta übertragen: neue/aktualisierte/gelöschte Datensätze. CDC kann über Zeitstempel, Trigger oder – betrieblich oft am saubersten – über Transaktionslogs der Datenbank umgesetzt werden. Ziel ist meist „near realtime“, ohne ständig Vollabzüge zu fahren.

Event Streaming meint die Veröffentlichung von Ereignissen (bijv. „Auftrag freigegeben“, „Wareneingang gebucht“) als fortlaufenden Strom über einen Message Broker (bijv. Kafka-ähnliche Systeme oder Service-Bus-Konzepte). Konsumenten abonnieren Events und verarbeiten sie in eigener Geschwindigkeit. Wichtig: Ein Event ist nicht automatisch „die ganze Wahrheit“ der Daten, sondern oft eine Zustandsänderung mit Kontext.

Vergelijking langs de vragen die in de operatie echt tellen

Latentie: Hoe snel moeten gegevens echt zijn?

Voor veel ERP-rapporten volstaan gegevens van „vorige nacht“. Voor operationele sturing in het magazijn kan „5 minuten oud“ al te laat zijn (bijv. bij krappe voorraden). Hier geldt:

• ETL levert planbare actualiseringsvensters, maar is per ontwerp niet „instant“.
• CDC is geschikt als u dataveranderingen snel in reporting- of zoeksystemen wilt spiegelen zonder de vaklogica opnieuw te modelleren.
• Event Streaming is passend als processen tijdig moeten reageren (bijv. verzendlabel genereren, klantstatus bijwerken, notificaties triggeren).

Een veelgemaakte fout is overal „realtime“ te eisen. Realtime verhoogt de complexiteit van monitoring, foutafhandeling en dataconsistentie. Zinvol is een classificatie: welke gegevens zijn operationeel (proceskritisch), welke analytisch (rapportagekritisch), welke archiefgericht (audit/compliance)?

Consistentie: Wat gebeurt er bij gedeeltelijke fouten?

In gedistribueerde integraties zijn gedeeltelijke fouten normaal: netwerkonderbrekingen, time-outs, vergrendelingen, onderhoudsvensters. Cruciaal is of uw aanpak dat robuust opvangt.

• ETL werkt meestal in runs. Als een run faalt, is de datastand in het doel vaak „tot tijdstip X“ consistent, daarna verouderd. Dat is voor rapportage vaak acceptabel, mits transparant.
• CDC draagt deltas over. Als het proces vastloopt ontstaat een achterstand. Dat is beheersbaar, maar u moet de lag (vertraging) meten en drempelwaarden alarmen.
• Event Streaming verschuift fouten naar de consumenten. Daarvoor heeft u idempotentie (meermalige verwerking zonder neveneffect), retry-strategieën en een Dead-Letter-Queue (opslag voor niet-verwerkbare berichten) nodig, anders worden fouten „stil“ en duiken ze pas in het vakgebied op.

Consistentie is ook een vakvraag: Moet „opdracht + posities + reserveringen“ als pakket aankomen, of volstaat een eventual consistency (latere afstemming)? Hoe hoger de pakketafhankelijkheid, hoe meer u transactiegrenzen en heldere volgorderegels nodig hebt.

Belasting en risico voor het ERP: Wat wordt hoe belast?

Veel integratieproblemen zijn in feite performance- en vergrendelingsproblemen in het bronsysteem. Het ERP is een OLTP-systeem (Online Transaction Processing): veel kleine transacties, hoge schrijfbelasting, gevoelige indexen.

• ETL haalt vaak grote hoeveelheden data op. Zonder nette tijdvensters, read-replica of gerichte extract-tabellen kan ETL het ERP afremmen.
• CDC via logs is doorgaans minder belastend omdat het de „reeds bestaande“ wijzigingsstroom benut. Trigger-gebaseerde CDC kan daarentegen schrijfpaden verlengen en is bij zwaar belaste tabellen een risico.
• Event Streaming voorkomt directe leesbelasting als events uit de applicatie zelf komen. Als events echter „uit de database gegenereerd“ worden, staat u weer dicht bij CDC — met vergelijkbare afwegingen.

Praktijkregel: Als het ERP nu al krap gedimensioneerd is, moet integratie niet beginnen met extra volledige afnames. Vaak loont eerst ontkoppeling, bijv. via CDC naar een apart reporting- of integratieschema, en pas daarna transformaties.

ETL in de praktijk: goed voor rapportage, gevaarlijk als proceslijm

ETL is in veel bedrijven de instap omdat het conceptueel tastbaar is: „We halen data op, bewerken ze, laden ze in het DWH.“ Voor klassieke BI-vereisten blijft dat zinvol.

Sterktes van ETL

• Planbaarheid: Nachtelijke of uurlijkse runs zijn goed te plannen en passen binnen onderhoudsvensters.
• Transformatielogica centraal: Opschoning, mapping, historisering (bijv. Slowly Changing Dimensions) zijn in de DWH-context ingeburgerd.
• Auditbaarheid: Met run-ID’s, row counts en checksums kunt u achterhalen wat wanneer is geladen.

Typische risico’s en „gegevenskerkhof“-patronen

• Wildgroei bij directe toegang: Hoe meer rapportages direct op geëxtraheerde tabellen gebaseerd zijn, hoe meer „onofficiële dataproducten“ ontstaan.
• Schema-drift zonder vroege waarschuwing: Als velden in het ERP wijzigen, valt dat vaak pas bij de volgende run op – of erger: helemaal niet, omdat nullwaarden „doorglippen“.
• Batch-vensters worden krap: Het gegevensvolume groeit, de looptijd neemt toe, en op den duur botst ETL met backups, reorgs of nachtelijke ERP-jobketens.

Concreet voorbeeld: Een magazijn heeft dagelijks een rapport „artikelen zonder voorraad maar met openstaande orders“ nodig. Als ETL-report is dat acceptabel. Wanneer dit rapport echter als basis voor operationele planning wordt gebruikt, is 24 uur vertraging plotseling vakinhoudelijk kritisch. Dan wordt ETL proceslijm – en dat is zelden stabiel.

CDC: De pragmatische weg naar deltas en near-realtime

CDC is vaak de „sweet spot“ wanneer u gegevens uit ERP/CRM/magazijn tijdig naar zoeksystemen, Data Warehouse of integratiedatabases wilt brengen, zonder elke bedrijfslogica als eventmodel opnieuw te moeten ontwerpen.

CDC-varianten en hun operationele consequenties

• CDC via tijdstempel/high-watermark: U leest „alles sinds de laatste tijdmarkering“. Dat is eenvoudig, maar kwetsbaar voor latere correcties, tijddrift en ontbrekende verwijdergebeurtenissen.
• Trigger-gebaseerde CDC: Wijzigingen worden daarnaast naar change-tabellen geschreven. Dat is functioneel duidelijk, maar verhoogt de schrijflast en vereist strikte rechten en extra onderhoud bij schemawijzigingen.
• Log-gebaseerde CDC: Wijzigingen worden uit het transactielog afgeleid. Dat is vaak performanter en dichter bij de werkelijkheid, maar vraagt zorgvuldige configuratie, omdat logretentie, backups en onderhoudsjobs plots integratierelevantie krijgen.

Belangrijk voor admins: CDC is niet „eens inschakelen“. U moet lag monitoren, resync-procedures definiëren (bijv. heropbouw van individuele tabellen) en vastleggen hoe lang change-historie in het doel wordt bewaard.

Waar CDC bijzonder goed in is

• Ontlasting van volledige extracties: Na een initiële snapshot lopen alleen nog deltas.
• Duidelijke scheiding OLTP vs. Analytics: Rapportage kan op een aparte database of een warehouse draaien, zonder het ERP te belasten.

Praktijkvoorbeeld: Een CRM moet dagelijks actueel weten of een klant openstaande leveringen heeft, zonder dat er in het ERP voortdurend complexe queries draaien. CDC spiegelt relevante tabellen of views naar een integratiedatabase; het CRM leest daar vandaan. Resultaat: minder belastingpieken in het ERP, en queries kunnen doelgericht geïndexeerd worden.

Event Streaming: Als processen moeten reageren – en u eigenaarschap accepteert

Event Streaming is vooral zinvol als u niet alleen data wilt kopiëren, maar procesreacties wilt orkestreren: statuswisselingen, notificaties, vervolgtaken, integraties met partners. Een event is een “ding dat is gebeurd” – inclusief timestamp, identificatoren en de minimaal noodzakelijke context.

Sterktes van Event Streaming

• Ontkoppeling: Producent en consument hoeven niet gelijktijdig beschikbaar te zijn. Dat vermindert storingsgevoeligheid tijdens onderhoudsvensters.
• Schaalbaarheid via consumenten: Meerdere systemen kunnen hetzelfde event gebruiken (bijv. CRM, verzending, BI), zonder dat het ERP voor elk doel afzonderlijk hoeft te leveren.
• Transparantie in de stroom: Met goed monitoring ziet u doorvoer, achterstanden en foutpercentages per consument.

Risico’s en veelvoorkomende misvattingen

• „We sturen events, dan klopt de datakwaliteit”: Events transporteren ook onjuiste toestanden als upstream-validaties ontbreken. Datakwaliteit blijft een vakinhoudelijke verantwoordelijkheid.
• Idempotentie wordt vergeten: Dubbele events komen voor (herhaalpoging, netwerk, rebalancing). Consumenten moeten dubbele verwerking tolereren, bijvoorbeeld via unieke event-IDs en „al-verwerkt“-controles.
• Schema- en versiebeheer: Event-berichten zijn interface-contracten. Zonder versiebeheer en een deprecatieplan ontstaat er chaos, alleen sneller.
• Volgorde komt niet vanzelf: Veel brokers bieden volgorde alleen binnen gedefinieerde partities/keys. Vakinhoudelijk moet duidelijk zijn welke key (bijv. opdracht-ID) orde garandeert.

Concreet scenario: in het magazijn wordt een goederenuitgang geboekt. Het ERP moet factureren, het CRM moet de klantstatus bijwerken, en het trackingportaal moet verzendinformatie beschikbaar stellen. Event Streaming kan dat netjes ontkoppelen. Als de facturatie echter per se vóór de statuswijziging moet plaatsvinden, heeft u ofwel procescoördinatie nodig (bijv. Saga/Choreografie) of duidelijke regels wie de orkestrator is. Anders flikkeren de toestanden.

Keuzehulp: Welke aanpak past bij welk doel?

In integratieprojecten is de verkeerde basisbeslissing kostbaar. Een praktijkgerichte indeling:

Als uw doel primair rapportage en analyse is

• Startpunt: ETL of ELT (eerst laden, later transformeren in het doelsysteem) – met duidelijke looptijden.
• Als actualiteit belangrijker wordt: CDC als gegevensaanvoer naar het datawarehouse, ETL/ELT voor transformatie en modellering.

Als uw doel operationele, tijdige synchronisatie is

• Startpunt: CDC voor tabel-/objectreplicatie, aangevuld met slanke services voor validatie en conflictoplossing.
• Als echte reactieketens nodig zijn: Event Streaming, maar alleen met gedefinieerd ownership en operationele verantwoordelijkheid per consument.

Als uw doel proceskoppeling tussen ERP/CRM/voorraad is

• Startpunt: Event Streaming of message-gebaseerde integratie, aangevuld met terugkanalen (Acknowledgements) en foutpaden.
• ETL hier alleen voor nevenstromen (bijv. dagelijkse afstemmingen, archief, BI), niet als trigger voor operationele acties.

Belangrijk: in de praktijk is het zelden „het één of het ander“. Veel stabiele architecturen combineren: events voor processen, CDC voor gegevensvoorziening en ETL/ELT voor rapportagemodellen.

Architectuurgevolgen die u vroeg moet regelen

Data-eigendom en Golden-Record-vragen

Wie mag wat wijzigen? Een „Golden Record“ is de vakinhoudelijk geldige dataset voor een object (klant, artikel, order). Als meerdere systemen kunnen schrijven, heeft u conflictregels nodig: prioriteiten, handmatige afhandeling of MDM-benaderingen (Master Data Management). Zonder deze regels wordt integratie een voortdurend „Waarom zijn de gegevens verschillend?“-ticket.

Foutafhandeling als ontwerp, niet als nabehandeling

Of ETL, CDC of Event Streaming: u heeft gedefinieerde foutklassen nodig. Beproefd is een driedeling:

• Technische fouten (timeout, netwerk, tijdelijke locks): automatische retry met backoff.
• Semantische fouten (verplicht veld ontbreekt, onbekende status): naar quarantaine/Dead-Letter, met ticketfunctionaliteit.
• Procesconflicten (volgorde geschonden, dubbele boeking): functioneel afhandelingsproces, vaak met handmatige besluitvorming.

Zonder quarantainemechanisme eindigt u bij „integratie draait groen, maar individuele gevallen ontbreken“. Dat is de snelste weg naar het datagrafveld, omdat niemand nog weet welke gegevensstand „waar“ is.

Monitoring, alerting en traceerbaarheid

Voor IT-management en operatie tellen concrete vragen: hoeveel datasets/events per uur? Hoe groot is de achterstand? Welke interface veroorzaakt de meeste retries? ETL heeft looptijdmonitoring nodig (start/einde, rijenaantallen), CDC heeft lag-metrieken nodig, Event Streaming heeft consumer-lag en Dead-Letter-percentages nodig. Daarbij horen logs met correlatie (bijv. opdracht-ID), zodat supportgevallen niet in screenshots eindigen.

Beveiliging en compliance: datakopieën brengen verantwoordelijkheid met zich mee

Integratie genereert kopieën. Kopieën betekenen nieuwe aanvalsvectoren en nieuwe bewaarbeleidsvragen. Typische punten die in projecten te laat aan bod komen:

• Least Privilege: ETL- en CDC-accounts mogen alleen lezen wat nodig is. Voor event-producenten/-consumenten zijn service-accounts met minimale rechten verplicht.
• Secrets-Handling: wachtwoorden in scripts of taakplanners zijn klassiekers. Beter: centraal secrets-management of op z’n minst correcte rotatie en audit.
• AVG en verwijdering: als in het ERP iets wordt verwijderd/geblokkeerd, moet duidelijk zijn wat er in het DWH/Data Lake/stream gebeurt. CDC moet verwijderingsgebeurtenissen afbeelden, ETL heeft verwijderings- of anonimiseringlogica nodig.

Rollout und Migration: So vermeiden Sie Big-Bang-Integrationen

Bij gegroeide processen is een stapsgewijze overgang doorgaans stabieler. Een praktijkgericht stappenplan:

1. Inventariseren: Welke gegevensstromen bestaan er (incl. Excel, SFTP, directe DB-toegangen)? Welke zijn proceskritisch?
2. Stabiele Zielzustand pro Domäne: bijv. ‚voorraadstatus komt uit WMS, orderstatus uit ERP, klantcommunicatie uit CRM‘.
3. Parallelbetrieb mit Abgleich: CDC/ETL draaien aanvankelijk ’shadow‘, resultaten worden vergeleken met de bestaande situatie (delta-rapporten, steekproeven).
4. Cutover mit Rückfall: Voor operationele integraties: overschakelen naar Event/CDC-bron, maar met een duidelijke terugvaloptie (bijv. read-only-queries of tijdelijke batch).
5. Aufräumen: Oude jobs uitschakelen, toegangen intrekken, documentatie en Ownership vastleggen. Zonder deze stap blijft het data-kerkhof bestaan, alleen met nieuwe decoratie.

Belangrijk is het managen van verwachtingen: een integratie is nooit ‚klaar‘. Nieuwe velden, nieuwe processen, nieuwe locaties – dat alles beïnvloedt gegevensstromen. Succesvolle teams definiëren daarom een onderhoudsmodus: versionering, tests, goedkeuringen, monitoring-aanpassingen.

Fazit: Datenintegration ohne Datenfriedhof braucht Technik – und Betriebsklarheit

ETL blijft een solide tool voor reporting, zolang u draaiplannen, datacontracten en de groei van batch-vensters onder controle heeft. CDC is vaak de pragmatische weg naar actuele datastanden, ontlast bronsystemen en zorgt voor een duidelijke scheiding tussen OLTP en analyse. Event Streaming is krachtig wanneer processen moeten reageren en meerdere systemen gebeurtenissen gebruiken – maar vereist consequent foutbeheer, versionering en Ownership per consument.

In de praktijk is de cruciale vraag niet ‚welke technologie is modern‘, maar: Welke latentie en betrouwbaarheid hebben onze processen nodig – en welke operationele draagkracht kunnen we blijvend dragen? Als u dat vroegtijdig duidelijk hebt, zijn integraties zo op te bouwen dat ze meegroeien zonder te vervallen.

Als u uw integraties tussen ERP, CRM en magazijn gestructureerd wilt moderniseren – inclusief exploitatieconcept, datacontracten en migratiepad – neem contact met ons op:

Voor dit onderwerp zijn ook Change Data Capture (Cdc) en ERP-integratie belangrijk. Het artikel plaatst deze aspecten begrijpelijk en laat zien waar het in de praktijk om gaat.

Project of moderniseringsopdracht bespreken met Net-Base.