Datenintegration ohne Datenfriedhof: CDC, Event Streaming und ETL im Vergleich für ERP/CRM/Lager

Wer ERP, CRM und Lagerverwaltung miteinander verbindet, will meistens zwei Dinge gleichzeitig: Prozesse sollen durchgängig laufen (z. B. Auftrag → Kommissionierung → Versand → Rechnung), und Daten sollen für Auswertungen verfügbar sein (z. B. Lieferfähigkeit, Deckungsbeiträge, Retourenquoten). In der Praxis entsteht daraus schnell ein Spagat zwischen „Wir brauchen es heute in den Reports“ und „Wir dürfen das produktive ERP nicht destabilisieren“. Genau hier entscheidet sich, ob Datenintegration ohne Datenfriedhof gelingt oder ob sich über Jahre ein unübersichtlicher Mix aus CSV-Exports, nächtlichen Jobs, Schatten-Tabellen und ungeklärten Datenkopien ansammelt.

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 (z. B. bereinigt, aggregiert, gemappt) und in ein Zielsystem geladen, häufig ein Data Warehouse. Klassisch passiert das batch-orientiert, z. B. 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 (z. B. „Auftrag freigegeben“, „Wareneingang gebucht“) als fortlaufenden Strom über einen Message Broker (z. B. 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.

Vergleich entlang der Fragen, die im Betrieb wirklich zählen

Latenz: Wie schnell müssen Daten wirklich sein?

Für viele ERP-Reports reichen Daten von „letzter Nacht“. Für operative Steuerung im Lager kann „5 Minuten alt“ bereits zu spät sein (z. B. bei knappen Beständen). Hier gilt:

• ETL liefert planbare Aktualisierungsfenster, ist aber per Design nicht „instant“.
• CDC ist gut, wenn Sie Datenänderungen zügig in Reporting- oder Suchsysteme spiegeln wollen, ohne die Fachlogik neu zu modellieren.
• Event Streaming eignet sich, wenn Prozesse zeitnah reagieren sollen (z. B. Versandlabel generieren, Kundenstatus aktualisieren, Benachrichtigungen auslösen).

Ein häufiger Fehler ist, überall „Realtime“ zu fordern. Realtime erhöht Komplexität in Monitoring, Fehlerbehandlung und Datenkonsistenz. Sinnvoll ist eine Klassifizierung: Welche Daten sind operativ (prozesskritisch), welche analytisch (reportingkritisch), welche archivisch (Audit/Compliance)?

Konsistenz: Was passiert bei Teilfehlern?

In verteilten Integrationen sind Teilfehler normal: Netzwerkunterbrechungen, Timeouts, Sperren, Wartungsfenster. Entscheidend ist, ob Ihr Ansatz das robust abfedert.

• ETL arbeitet meist in Läufen. Wenn ein Lauf scheitert, ist der Datenstand im Ziel oft „bis Zeitpunkt X“ konsistent, danach veraltet. Das ist für Reporting häufig akzeptabel, solange es transparent ist.
• CDC überträgt Deltas. Wenn der Prozess hängt, entsteht ein Rückstau. Das ist beherrschbar, aber Sie müssen Lag (Verzögerung) messen und Grenzwerte alarmieren.
• Event Streaming verlagert Fehler in die Konsumenten. Dafür brauchen Sie Idempotenz (mehrfaches Verarbeiten ohne Nebenwirkung), Retry-Strategien und eine Dead-Letter-Queue (Ablage für nicht verarbeitbare Nachrichten), sonst werden Fehler „still“ und tauchen erst im Fachbereich auf.

Konsistenz ist auch eine Fachfrage: Muss „Auftrag + Positionen + Reservierungen“ als Paket ankommen, oder reicht eine eventual consistency (spätere Angleichung)? Je höher die Paketabhängigkeit, desto eher brauchen Sie Transaktionsgrenzen und klare Reihenfolgenregeln.

Last und Risiko fürs ERP: Was wird wie belastet?

Viele Integrationsprobleme sind in Wahrheit Performance- und Sperrprobleme im Quellsystem. Das ERP ist ein OLTP-System (Online Transaction Processing): viele kleine Transaktionen, hohe Schreiblast, sensible Indizes.

• ETL zieht oft große Datenmengen. Ohne saubere Zeitfenster, Read-Replica oder gezielte Extrakt-Tabellen kann ETL das ERP ausbremsen.
• CDC über Logs ist meist schonender, weil es den „bereits vorhandenen“ Änderungsstrom nutzt. Trigger-basierte CDC kann dagegen Schreibpfade verlängern und ist in stark belasteten Tabellen ein Risiko.
• Event Streaming vermeidet Direktlese-Last, wenn Events aus der Anwendung selbst kommen. Wenn Events aber „aus der Datenbank generiert“ werden, sind Sie wieder nahe an CDC – mit ähnlichen Abwägungen.

Praxisregel: Wenn das ERP schon heute knapp dimensioniert ist, sollte Integration nicht mit zusätzlichen Vollabzügen beginnen. Häufig lohnt sich zuerst eine Entkopplung, z. B. über CDC in ein separates Reporting- oder Integrationsschema, und erst danach Transformationen.

ETL im Alltag: gut für Reporting, gefährlich als Prozesskleber

ETL ist in vielen Unternehmen der Einstieg, weil es konzeptionell greifbar ist: „Wir holen Daten, bereiten sie auf, laden sie ins DWH.“ Für klassische BI-Anforderungen ist das weiterhin sinnvoll.

Stärken von ETL

• Planbarkeit: Nachtläufe oder stündliche Läufe sind gut steuerbar und passen zu Wartungsfenstern.
• Transformationslogik zentral: Bereinigung, Mapping, Historisierung (z. B. Slowly Changing Dimensions) sind im DWH-Kontext etabliert.
• Auditierbarkeit: Mit Lauf-IDs, Row-Counts und Checksummen können Sie nachvollziehen, was wann geladen wurde.

Typische Risiken und „Datenfriedhof“-Muster

• Direktzugriff-Wildwuchs: Je mehr Auswertungen direkt auf extrahierten Tabellen basieren, desto mehr „inoffizielle Datenprodukte“ entstehen.
• Schema-Drift ohne Frühwarnung: Wenn sich im ERP Felder ändern, fällt das oft erst beim nächsten Lauf auf – oder schlimmer: gar nicht, weil Nullwerte „durchrutschen“.
• Batch-Fenster werden eng: Datenvolumen wächst, Laufzeit wächst, irgendwann kollidiert ETL mit Backups, Reorgs oder nächtlichen ERP-Jobketten.

Konkretes Beispiel: Ein Lager benötigt täglich eine Auswertung „Artikel ohne Bestand aber offene Aufträge“. Als ETL-Report okay. Wenn dieser Report jedoch als Grundlage für operative Disposition genutzt wird, sind 24 Stunden Verzögerung plötzlich fachlich kritisch. Dann wird ETL zum Prozesskleber – und das ist selten stabil.

CDC: Der pragmatische Weg zu Deltas und Near-Realtime

CDC ist oft der „sweet spot“, wenn Sie Daten aus ERP/CRM/Lager zeitnah in Suchsysteme, Data Warehouse oder Integrationsdatenbanken bringen wollen, ohne jede Fachlogik als Eventmodell neu zu denken.

CDC-Varianten und ihre Betriebsfolgen

• CDC über Zeitstempel/High-Watermark: Sie lesen „alles seit letzter Zeitmarke“. Das ist einfach, aber anfällig für nachträgliche Korrekturen, Zeitdrift und fehlende Löschereignisse.
• Trigger-basierte CDC: Änderungen schreiben zusätzlich in Change-Tabellen. Das ist funktional klar, aber erhöht Schreiblast und braucht saubere Berechtigungen sowie Wartung bei Schemaänderungen.
• Log-basierte CDC: Änderungen werden aus dem Transaktionslog abgeleitet. Das ist oft performanter und näher an der Wahrheit, benötigt aber sorgfältige Konfiguration, weil Log-Retention, Backups und Wartungsjobs plötzlich Integrationsrelevanz haben.

Wichtig für Admins: CDC ist nicht „einmal einschalten“. Sie müssen Lag überwachen, Resync-Prozeduren definieren (z. B. Neuaufbau einzelner Tabellen) und festlegen, wie lange Change-Historie im Ziel gehalten wird.

Was CDC besonders gut kann

• Entlastung von Vollabzügen: Nach einem initialen Snapshot laufen nur noch Deltas.
• Saubere Trennung OLTP vs. Analytics: Reporting kann auf einer separaten Datenbank oder einem Warehouse laufen, ohne das ERP zu belasten.
• Technisch neutrale Datenbereitstellung: Downstream-Teams können Transformationsschritte unabhängig iterieren.

Praxisbeispiel: Ein CRM soll tagesaktuell wissen, ob ein Kunde offene Lieferungen hat, ohne im ERP ständig komplexe Abfragen zu fahren. CDC spiegelt relevante Tabellen oder Views in eine Integrationsdatenbank; das CRM liest von dort. Ergebnis: weniger Lastspitzen im ERP, und Abfragen können gezielt indiziert werden.

Event Streaming: Wenn Prozesse reagieren müssen – und Sie Ownership akzeptieren

Event Streaming lohnt sich besonders, wenn Sie nicht nur Daten kopieren, sondern Prozessreaktionen orchestrieren wollen: Statuswechsel, Benachrichtigungen, Folgeaufgaben, Integrationen mit Partnern. Ein Event ist ein „Ding, das passiert ist“ – inklusive Zeitstempel, Identifikatoren und minimal notwendigem Kontext.

Stärken von Event Streaming

• Entkopplung: Produzent und Konsument müssen nicht gleichzeitig verfügbar sein. Das reduziert Störanfälligkeit bei Wartungsfenstern.
• Skalierung über Konsumenten: Mehrere Systeme können dasselbe Event nutzen (z. B. CRM, Versand, BI), ohne dass das ERP für jedes Ziel separat liefern muss.
• Transparenz im Fluss: Mit gutem Monitoring sehen Sie Durchsatz, Rückstau und Fehlerraten pro Konsument.

Risiken und typische Fehlannahmen

• „Wir schicken Events, dann stimmt die Datenqualität“: Events transportieren auch falsche Zustände, wenn upstream Validierungen fehlen. Datenqualität bleibt eine fachliche Disziplin.
• Idempotenz wird vergessen: Doppelte Events passieren (Retry, Netzwerk, Rebalancing). Konsumenten müssen doppelte Verarbeitung tolerieren, z. B. über eindeutige Event-IDs und „already processed“-Checks.
• Schema- und Versionsmanagement: Event-Nachrichten sind Schnittstellenverträge. Ohne Versionierung und Deprecation-Plan entsteht Chaos, nur schneller.
• Reihenfolge ist nicht gratis: Viele Broker bieten Reihenfolge nur innerhalb definierter Partitionen/Keys. Fachlich muss klar sein, welcher Key (z. B. Auftrag-ID) Ordnung garantiert.

Konkretes Szenario: Im Lager wird ein Warenausgang gebucht. Das ERP soll fakturieren, das CRM soll den Kundenstatus aktualisieren, und das Tracking-Portal soll eine Versandinformation bereitstellen. Event Streaming kann das sauber entkoppeln. Wenn aber die Faktura zwingend vor der Statusänderung passieren muss, brauchen Sie entweder Prozesskoordination (z. B. Saga/Choreografie) oder klare Regeln, wer der Orchestrator ist. Sonst „flackern“ Zustände.

Entscheidungshilfe: Welcher Ansatz passt zu welchem Ziel?

In Integrationsprojekten ist die falsche Grundentscheidung teuer. Eine praxistaugliche Einordnung:

Wenn Ihr Ziel primär Reporting und Analytik ist

• Startpunkt: ETL oder ELT (Load zuerst, Transform später im Zielsystem) – mit klaren Laufplänen.
• Wenn Aktualität steigt: CDC als Datenzuführung in das Warehouse, ETL/ELT für Transformation und Modellierung.

Wenn Ihr Ziel operative, zeitnahe Synchronisation ist

• Startpunkt: CDC für Tabellen-/Objektspiegelung, dazu schlanke Services für Validierung und Konfliktlösung.
• Wenn echte Reaktionsketten nötig sind: Event Streaming, aber nur mit definiertem Ownership und Betriebsverantwortung pro Konsument.

Wenn Ihr Ziel Prozesskopplung zwischen ERP/CRM/Lager ist

• Startpunkt: Event Streaming oder Message-basierte Integration, ergänzt um Rückkanäle (Acknowledgements) und Fehlerpfade.
• ETL hier nur für Nebenströme (z. B. tägliche Abgleiche, Archiv, BI), nicht als Trigger für operative Aktionen.

Wichtig: In der Realität ist es selten „entweder-oder“. Viele stabile Architekturen kombinieren: Events für Prozesse, CDC für Datenbereitstellung und ETL/ELT für Reportingmodelle.

Architekturfolgen, die Sie früh klären sollten

Datenhoheit und Golden-Record-Fragen

Wer darf was ändern? Ein „Golden Record“ ist der fachlich gültige Datensatz für ein Objekt (Kunde, Artikel, Auftrag). Wenn mehrere Systeme schreiben, brauchen Sie Konfliktregeln: Prioritäten, manuelle Klärung oder MDM-Ansätze (Master Data Management). Ohne diese Regeln wird Integration zum ständigen „Warum sind die Daten unterschiedlich?“-Ticket.

Fehlerbehandlung als Design, nicht als Nacharbeit

Ob ETL, CDC oder Event Streaming: Sie brauchen definierte Fehlerklassen. Bewährt ist eine Dreiteilung:

• Technische Fehler (Timeout, Netzwerk, temporäre Sperren): automatischer Retry mit Backoff.
• Semantische Fehler (Pflichtfeld fehlt, unbekannter Status): ab in Quarantäne/Dead-Letter, mit Ticketfähigkeit.
• Prozesskonflikte (Reihenfolge verletzt, Doppelbuchung): fachlicher Klärprozess, oft mit manueller Entscheidung.

Ohne Quarantäne-Mechanismus landen Sie bei „Integration läuft grün, aber einzelne Fälle fehlen“. Das ist der schnellste Weg in den Datenfriedhof, weil niemand mehr weiß, welcher Datenstand „wahr“ ist.

Monitoring, Alerting und Nachvollziehbarkeit

Für IT-Leitung und Betrieb zählen konkrete Fragen: Wie viele Datensätze/Events pro Stunde? Wie groß ist der Rückstau? Welche Schnittstelle verursacht die meisten Retries? ETL braucht Laufmonitoring (Start/Ende, Row-Counts), CDC braucht Lag-Metriken, Event Streaming braucht Consumer-Lag und Dead-Letter-Quoten. Dazu gehören Logs mit Korrelation (z. B. Auftrag-ID), damit Supportfälle nicht in Screenshots enden.

Sicherheit und Compliance: Datenkopien sind Verantwortung

Integration erzeugt Kopien. Kopien bedeuten neue Angriffsflächen und neue Aufbewahrungsfragen. Typische Punkte, die in Projekten zu spät kommen:

• Least Privilege: ETL- und CDC-Accounts sollten nur lesen, was nötig ist. Für Event-Produzenten/Konsumenten sind Service Accounts mit minimalen Rechten Pflicht.
• Secrets-Handling: Passwörter in Skripten oder Task Scheduler sind ein Klassiker. Besser: zentrales Secrets-Management oder zumindest saubere Rotation und Audit.
• DSGVO und Löschung: Wenn im ERP gelöscht/gesperrt wird, muss klar sein, was im DWH/Data Lake/Stream passiert. CDC muss Löschereignisse abbilden, ETL braucht Lösch- oder Anonymisierungslogik.
• Audit Trails: Für kritische Prozesse kann relevant sein, wer wann welchen Status geändert hat. Diese Information darf nicht in Transformationen „wegoptimiert“ werden.

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

Gerade bei gewachsenen Prozessen ist ein schrittweiser Übergang stabiler. Ein praxistaugliches Vorgehen:

1. Inventarisieren: Welche Datenflüsse existieren (inkl. Excel, SFTP, Direkt-DB-Zugriffe)? Welche sind prozesskritisch?
2. Stabiler Zielzustand pro Domäne: z. B. „Lagerstatus kommt aus WMS, Auftragsstatus aus ERP, Kundenkommunikation aus CRM“.
3. Parallelbetrieb mit Abgleich: CDC/ETL laufen zunächst „shadow“, Ergebnisse werden gegen den bisherigen Stand verglichen (Delta-Reports, Stichproben).
4. Cutover mit Rückfall: Für operative Integrationen: Umschalten auf Event/CDC-Quelle, aber mit klarer Rückfallebene (z. B. Read-only-Abfragen oder temporärer Batch).
5. Aufräumen: Alte Jobs abschalten, Zugriffe entziehen, Dokumentation und Ownership festziehen. Ohne diesen Schritt bleibt der Datenfriedhof bestehen, nur mit neuer Deko.

Wichtig ist die Erwartungssteuerung: Eine Integration ist nie „fertig“. Neue Felder, neue Prozesse, neue Standorte – das alles wirkt auf Datenflüsse. Erfolgreiche Teams definieren deshalb einen Wartungsmodus: Versionierung, Tests, Freigaben, Monitoring-Anpassungen.

Fazit: Datenintegration ohne Datenfriedhof braucht Technik – und Betriebsklarheit

ETL bleibt ein solides Werkzeug für Reporting, solange Sie Laufpläne, Datenverträge und Wachstum der Batch-Fenster im Griff haben. CDC ist häufig der pragmatische Weg zu aktuellen Datenständen, entlastet Quellsysteme und schafft eine saubere Trennung zwischen OLTP und Auswertung. Event Streaming ist dann stark, wenn Prozesse reagieren müssen und mehrere Systeme Ereignisse nutzen – verlangt aber konsequentes Fehlermanagement, Versionierung und Ownership pro Konsument.

In der Praxis ist die entscheidende Frage nicht „welche Technologie ist modern“, sondern: Welche Latenz und Verlässlichkeit brauchen unsere Prozesse – und welche Betriebsfähigkeit können wir dauerhaft tragen? Wenn Sie das früh klären, lassen sich Integrationen so aufbauen, dass sie wachsen, ohne zu verrotten.

Wenn Sie Ihre Integrationen zwischen ERP, CRM und Lager strukturiert modernisieren möchten – inklusive Betriebskonzept, Datenverträgen und Migrationspfad – sprechen Sie mit uns:

Für dieses Thema sind auch Change Data Capture (Cdc) und ERP Integration wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.