Dataintegration uden datakirkegård: CDC, Event Streaming og ETL sammenlignet for ERP/CRM/Lager

Den, der kobler ERP, CRM og lagerstyring sammen, vil som regel to ting på én gang: processerne skal køre gennemgående (f.eks. ordre → pluk → forsendelse → faktura), og data skal være tilgængelige til analyser (f.eks. leveringsdygtighed, dækningsbidrag, returneringsprocenter). I praksis opstår der hurtigt en spænding mellem „Wir brauchen es heute in den Reports“ og „Wir dürfen das produktive ERP nicht destabilisieren“. Netop her afgøres det, om dataintegration uden datakirkegård lykkes, eller om der over år hober sig et uoverskueligt miks af CSV-eksporter, natlige jobs, skygge-tabeller og uklare datakopier op.

Denne artikel sammenligner tre centrale tilgange: ETL (Extract, Transform, Load), CDC (Change Data Capture, altså detektering og overførsel af datændringer) og Event Streaming (begivenheder som en løbende datastream via en broker). Fokus ligger ikke på programmeringsdetaljer, men på arkitekturkonsekvenser, driftsrealitet, datakvalitet, sikkerheds- og rollout-spørgsmål – sådan som de rent faktisk optræder i integrationsprojekter mellem virksomhedssystemer.

Hvorfor integrationer ofte ender som en datakirkegård

En datakirkegård opstår sjældent af ond vilje. Typiske årsager er:

• Uklare systemgrænser: ERP er den ene gang „führend“, så igen CRM, og i lageret er der egen statuslogik. Uden fastlagt dataejerskab (System of Record) er konflikter forudbestemt.
• Ad-hoc-krav: „Vi skal hurtigt have et dashboard“ fører til direkte adgang til ERP; senere kommer yderligere forespørgsler, materialiserede views eller kopier til. Hver hurtig gevinst flytter driftsbyrden og ansvarsfordelingen.
• Manglende kontrakter: Grænsefladekontrakter (hvilke felter, hvilken semantik, hvilken versionering) mangler. Resultat: schema-drift – felter ændrer betydning eller struktur, uden at downstream-systemer opdager det i tide.
• Intet driftskoncept: Jobs kører „et eller andet sted“, adgangsoplysninger ligger i scripts, der er ingen alarmering ved datamangler, og ingen kan svare på, om en rapport er „fuldstændig“.

ETL, CDC og Event Streaming løser forskellige dele af dette problem. Det er afgørende, at I vælger tilgangen ud fra proceskritikalitet, latenskrav og driftsmodenhed – og at I driver integrationsvejen som et produkt, ikke som et engangs projektartefakt.

Begreber korrekt indordnet: ETL, CDC og Event Streaming

ETL står for „Extract, Transform, Load“: Data trækkes fra kildesystemer, omformes (f.eks. renses, aggregeres, mappes) og indlæses i et målsystem, ofte et Data Warehouse. Klassisk sker det batch-orienteret, f.eks. om natten eller timevis.

CDC (Change Data Capture) beskriver mekanismer, der opdager ændringer i data og overfører dem som delta: nye/opdaterede/slettede datasæt. CDC kan implementeres via tidsstempler, triggers eller – driftsmæssigt ofte mest rent – via databasens transaktionslogs. Målet er som regel „near realtime“, uden konstant at køre fulde udtræk.

Event Streaming betyder publicering af begivenheder (f.eks. „ordre frigivet“, „varemodtagelse bogført“) som en løbende strøm over en Message Broker (f.eks. Kafka-lignende systemer eller servicebus-koncepter). Konsumenter abonnerer på events og behandler dem i eget tempo. Vigtigt: Et event er ikke automatisk „hele sandheden“ om dataene, men ofte en tilstandsændring med kontekst.

Sammenligning ud fra de spørgsmål, der virkelig tæller i driften

Latens: Hvor hurtigt skal data reelt være?

For mange ERP-rapporter er data fra „sidste nat“ tilstrækkelige. Til operationel styring i lageret kan „5 minutter gamle“ allerede være for sent (f.eks. ved lave beholdninger). Her gælder:

• ETL leverer planlagte opdateringsvinduer, men er ikke designet til at være øjeblikkelig.
• CDC er velegnet, hvis I hurtigt vil spejle dataændringer til reporting- eller søgesystemer uden at genmodelere forretningslogikken.
• Event Streaming er velegnet, når processer skal reagere tidsnært (f.eks. generere forsendelseslabel, opdatere kundestatus, udløse notifikationer).

En hyppig fejl er at kræve realtid overalt. Realtid øger kompleksiteten i overvågning, fejlbehandling og datakonsistens. Fornuftigt er en klassificering: Hvilke data er operative (proceskritiske), hvilke analytiske (rapporteringkritiske), hvilke arkivmæssige (Audit/Compliance)?

Konsistens: Hvad sker der ved delvise fejl?

I distribuerede integrationer er delvise fejl normale: netværksafbrydelser, timeouts, låsninger, vedligeholdelsesvinduer. Afgørende er, om jeres tilgang robust absorberer det.

• ETL kører som regel i batchkørsler. Hvis en kørsel fejler, er datagrundlaget i målsystemet ofte konsistent „indtil tidspunkt X“, og derefter forældet. Det er ofte acceptabelt for reporting, så længe det er transparent.
• CDC overfører deltas. Hvis processen hænger, opstår der en ophobning. Det er håndterbart, men I skal måle lag (forsinkelse) og alarmere ved grænseværdier.
• Event Streaming flytter fejl over i forbrugerne. Derfor har I brug for idempotens (gentagen behandling uden sideeffekt), retry-strategier og en Dead-Letter-Queue (lagring af ikke-behandlelige beskeder), ellers bliver fejl „stumme“ og dukker først op i fagområdet.

Konsistens er også et fagligt spørgsmål: Skal „ordre + ordrelinjer + reservationer“ ankomme som en pakke, eller er eventual consistency (senere afstemning) tilstrækkelig? Jo højere afhængigheden i pakken, desto mere har I brug for transaktionsgrænser og klare rækkefølgebestemmelser.

Belastning og risiko for ERP: Hvad belastes, og hvordan?

Mange integrationsproblemer er i virkeligheden performance- og låseproblemer i kildesystemet. ERP’et er et OLTP-system (Online Transaction Processing): mange små transaktioner, høj skrivebelastning, følsomme indekser.

• ETL henter ofte store datamængder. Uden klare tidsvinduer, read-replica eller målrettede ekstrakt-tabeller kan ETL bremse ERP’et.
• CDC over logs er som regel mere skånsom, fordi den bruger den „allerede eksisterende“ ændringsstrøm. Trigger-baseret CDC kan derimod forlænge skriveveje og udgøre en risiko i meget belastede tabeller.
• Event Streaming undgår direkte læsebelastning, når events kommer fra selve applikationen. Hvis events derimod „genereres fra databasen“, kommer I igen tæt på CDC – med lignende afvejninger.

Praksisregel: Hvis ERP’et allerede i dag er knapt dimensioneret, bør integration ikke starte med yderligere fulde udtræk. Ofte betaler det sig først at afkoble, f.eks. via CDC til et separat reporting- eller integrationsschema, og først derefter lave transformationer.

ETL i hverdagen: godt til reporting, farligt som proceslim

ETL er i mange virksomheder indgangsvinklen, fordi det er konceptuelt håndgribeligt: „Vi henter data, forbereder dem, indlæser dem i DWH.“ Til klassiske BI-krav er det fortsat fornuftigt.

Styrker ved ETL

• Planlægbarhed: Nattekørsler eller kørsler hver time er let at styre og passer ind i vedligeholdelsesvinduer.
• Centraliseret transformationslogik: Rensning, mapping, historisering (f.eks. Slowly Changing Dimensions) er etableret i DWH-konteksten.
• Auditérbarhed: Med kørings‑ID’er, rækkeantal og checksums kan I efterprøve, hvad der blev indlæst hvornår.

Typiske risici og „data-kirkegård“-mønstre

• Vildvækst i direkteadgang: Jo flere analyser der bygger direkte på de ekstrakterede tabeller, desto flere ‚uofficielle dataprodukter‘ opstår.
• Skemadrift uden forvarsel: Hvis felter ændres i ERP, opdages det ofte først ved næste kørsel — eller værre: slet ikke, fordi null‑værdier ‚glider igennem‘.
• Batch‑vinduer bliver snævre: Datamængden vokser, køretiden vokser, og på et tidspunkt kolliderer ETL med backups, reorgs eller natlige ERP‑jobkæder.

Konkrekt eksempel: Et lager har dagligt brug for en udtrækning „artikler uden lagerbeholdning men med åbne ordrer“. Som ETL‑rapport er det i orden. Hvis denne rapport derimod bruges som grundlag for operativ disponering, bliver 24 timers forsinkelse pludselig fagligt kritisk. Så bliver ETL proceslim — og det er sjældent stabilt.

CDC: Den pragmatiske vej til deltas og Near-Realtime

CDC er ofte den „sweet spot“, når I vil føre data fra ERP/CRM/lager hurtigt ind i søgesystemer, Data Warehouse eller integrationsdatabaser, uden at genforme al faglogik som et eventmodel.

CDC‑varianter og deres driftskonsekvenser

• CDC via tidsstempler/high‑watermark: I læser „alt siden sidste tidsmærke“. Det er enkelt, men sårbart over for efterfølgende korrektioner, tidsdrift og manglende slettebegivenheder.
• Trigger‑baseret CDC: Ændringer skriver desuden til change‑tabeller. Det er funktionelt klart, men øger skrivebelastningen og kræver klare rettigheder samt vedligehold ved skemaændringer.
• Log‑baseret CDC: Ændringer afledes fra transaktionsloggen. Det er ofte mere performativt og tættere på sandheden, men kræver omhyggelig konfiguration, fordi log‑retention, backups og vedligeholdelsesjob pludselig får integrationsrelevans.

Vigtigt for admins: CDC er ikke „én gang tændt“. I skal overvåge lag, definere resync‑procedurer (f.eks. genopbygning af enkelte tabeller) og fastlægge, hvor længe change‑historik gemmes i målet.

Hvad CDC er særligt god til

• Aflastning af fulde udtræk: Efter et initialt snapshot køres kun deltas.
• Ren adskillelse OLTP vs. Analytics: Reporting kan køre på en separat database eller et Warehouse uden at belaste ERP’et.

Praktisk eksempel: Et CRM skal være dagsaktuelt orienteret om, hvorvidt en kunde har åbne leverancer, uden at ERP’et konstant kører komplekse forespørgsler. CDC spejler relevante tabeller eller views til en integrationsdatabase; CRM’et læser derfra. Resultat: færre belastningstoppe i ERP’et, og forespørgsler kan blive målrettet indekseret.

Event Streaming: Når processer skal reagere – og I accepterer ejerskab

Event Streaming giver særlig værdi, når I ikke kun kopierer data, men vil orkestrere procesreaktioner: statusændringer, notifikationer, efterfølgende opgaver, integrationer med partnere. Et event er en „ting, der er sket“ – inklusive tidsstempel, identifikatorer og det minimalt nødvendige kontekst.

Styrker ved Event Streaming

• Afkobling: Producent og konsument behøver ikke være tilgængelige samtidigt. Det reducerer sårbarhed under vedligeholdelsesvinduer.
• Skalering via konsumenter: Flere systemer kan bruge samme event (f.eks. CRM, forsendelse, BI), uden at ERP’et skal levere separat til hvert mål.
• Gennemsigtighed i flowet: Med god overvågning kan I se gennemstrømning, køopbygning og fejlrater per konsument.

Risici og typiske fejlagtige antagelser

• „Vi sender events, så er datakvaliteten i orden“: Events kan også transportere falske tilstande, hvis upstream-valideringer mangler. Datakvalitet forbliver en faglig disciplin.
• Idempotens bliver glemt: Dobbelte events sker (Retry, netværk, Rebalancing). Konsumenter skal tolerere dobbelt behandling, f.eks. via entydige event-IDs og „already processed“-checks.
• Skema- og versionsstyring: Event-meddelelser er kontrakter for interfaces. Uden versionering og en deprecationsplan opstår der kaos – bare hurtigere.
• Rækkefølge er ikke gratis: Mange brokere tilbyder rækkefølge kun inden for definerede partitioner/keys. Fagligt skal det være klart, hvilken key (f.eks. ordre-ID) garanterer orden.

Konkret scenario: I lageret registreres en vareudgang. ERP’et skal fakturere, CRM’et skal opdatere kundestatus, og tracking-portalen skal levere en forsendelsesinformation. Event Streaming kan adskille det rent. Men hvis faktureringen nødvendigvis skal ske før statusændringen, har I enten brug for proceskoordinering (f.eks. Saga/koreografi) eller klare regler for, hvem der er orkestrator. Ellers opstår inkonsistente tilstande.

Beslutningshjælp: Hvilken tilgang passer til hvilket mål?

I integrationsprojekter er den forkerte grundlæggende beslutning dyr. En praksisnær inddeling:

Hvis jeres mål primært er rapportering og analyse

• Startpunkt: ETL eller ELT (Load først, transformér senere i målsystemet) – med klare kørselsplaner.
• Wenn Aktualität steigt: CDC som dataindspejling til warehouse, ETL/ELT til transformation og modellering.

Hvis dit mål er operationel, tidsnær synkronisering

• Startpunkt: CDC til tabel-/objektspejling, suppleret med slanke services til validering og konfliktløsning.
• Wenn echte Reaktionsketten nötig sind: Event Streaming, men kun med defineret ejerskab og driftsansvar per konsument.

Hvis dit mål er proceskobling mellem ERP/CRM/lager

• Startpunkt: Event Streaming eller meddelelsesbaseret integration, suppleret med returkanaler (acknowledgements) og fejlhåndteringsstier.
• ETL her kun til sekundære strømme (f.eks. daglige afstemninger, arkiv, BI), ikke som trigger for operative handlinger.

Vigtigt: I praksis er det sjældent „enten-eller“. Mange stabile arkitekturer kombinerer: events til processer, CDC til dataforsyning og ETL/ELT til rapporteringsmodeller.

Arkitekturkonsekvenser, som I bør afklare tidligt

Dataherredømme og Golden-Record-spørgsmål

Hvem må ændre hvad? En „Golden Record“ er den fagligt gyldige datapost for et objekt (kunde, artikel, ordre). Hvis flere systemer skriver, har I brug for konfliktregler: prioriteter, manuel afklaring eller MDM-tilgange (Master Data Management). Uden disse regler bliver integration til et konstant „Hvorfor er data forskellige?“-ticket.

Fejlbehandling som design, ikke som efterarbejde

Uanset om ETL, CDC eller Event Streaming: I har brug for definerede fejlkategorier. En tredeling er bevist effektiv:

• Tekniske fejl (timeout, netværk, midlertidige låse): automatisk genforsøg med backoff.
• Semantiske fejl (påkrævet felt mangler, ukendt status): i karantæne/Dead-Letter, med ticketfunktionalitet.
• Proceskonflikter (rækkefølge overtrådt, dobbeltbooking): faglig afklaringsproces, ofte med manuel beslutning.

Uden en karantænemekanisme ender I med „Integration kører grønt, men enkelte tilfælde mangler“. Det er den hurtigste vej til datagravpladsen, fordi ingen længere ved, hvilket datastatus der er „sand“.

Overvågning, alarmering og sporbarhed

For IT-ledelse og drift betyder konkrete spørgsmål noget: Hvor mange datasæt/events pr. time? Hvor stort er efterslæbet? Hvilke interfaces forårsager flest genforsøg? ETL kræver kørselsmonitorering (start/slut, row-counts), CDC kræver lag-matricer, Event Streaming kræver consumer-lag og Dead-Letter-andele. Hertil hører logs med korrelation (f.eks. ordre-ID), så support-sager ikke ender i screenshots.

Sikkerhed og compliance: Datakopier er et ansvar

Integration skaber kopier. Kopier betyder nye angrebsoverflader og nye opbevaringsspørgsmål. Typiske punkter, som ofte kommer for sent i projekter:

• Least Privilege: ETL- og CDC-accounts bør kun have læserettigheder til det nødvendige. For event-producenter/konsumenter er servicekonti med minimale rettigheder obligatoriske.
• Secrets-Handling: Passwords i scripts eller Task Scheduler er en klassiker. Bedre: centralt secrets-management eller mindst ordentlig rotation og audit.
• GDPR og sletning: Når der slettes/spærres i ERP, skal det være klart, hvad der sker i DWH/Data Lake/Stream. CDC skal afbilde slettebegivenheder, ETL har brug for slette- eller anonymiseringslogik.

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

Især for etablerede processer er en trinvis overgang mere stabil. En praksisnær fremgangsmåde:

1. Kortlæg: Hvilke dataflows findes (inkl. Excel, SFTP, direkte DB-adgang)? Hvilke er processkritiske?
2. Stabil måltilstand pr. domæne: f.eks. „Lagerstatus kommer fra WMS, ordrestatus fra ERP, kundekommunikation fra CRM“.
3. Paralleldrift med afstemning: CDC/ETL kører først som „shadow“, resultater sammenlignes med den hidtidige tilstand (delta-rapporter, stikprøver).
4. Cutover med tilbagefald: For operative integrationer: skift til Event/CDC-kilde, men med en klar tilbagefaldsmulighed (f.eks. read-only-forespørgsler eller midlertidig batch).
5. Oprydning: Sluk gamle jobs, fjern adgang, fastlæg dokumentation og ejerskab. Uden dette trin forbliver datakirkegården – blot med ny pynt.

Vigtigt er forventningsstyring: En integration er aldrig „færdig“. Nye felter, nye processer, nye lokationer – alt påvirker dataflows. Succesfulde teams definerer derfor en vedligeholdelsestilstand: versionering, tests, godkendelser, justeringer af overvågning.

Fazit: Datenintegration ohne Datenfriedhof braucht Technik – und Betriebsklarheit

ETL forbliver et solidt værktøj til rapportering, så længe man har styr på køreplaner, datakontrakter og væksten i batch-vinduerne. CDC er ofte den pragmatiske vej til aktuelle datatilstande, aflaster kildesystemer og skaber en klar adskillelse mellem OLTP og analyse. Event Streaming er stærkt, når processer skal reagere, og flere systemer bruger hændelser – men kræver konsekvent fejlbehandling, versionering og ejerskab pr. konsument.

I praksis er det afgørende spørgsmål ikke „hvilken teknologi er moderne“, men: hvilken latenstid og pålidelighed kræver vores processer – og hvilken driftskapacitet kan vi bære på lang sigt? Hvis dette afklares tidligt, kan integrationer bygges, så de vokser uden at forfalde.

Hvis I ønsker at modernisere jeres integrationer mellem ERP, CRM og lager struktureret – inklusive driftskoncept, datakontrakter og migrationssti – kontakt os:

Til dette emne er Change Data Capture (CDC) og ERP-integration også vigtige. Artiklen sætter disse aspekter i perspektiv og viser, hvad der betyder noget i dagligdagen.

Drøft projekt eller moderniseringsforløb med Net-Base.