Ausgangslage
Ein internationaler Logistik- und Business-Process-Outsourcing-Dienstleister mit Standorten in 8 Ländern verwaltete Kundendaten, Transaktionsdaten und operative Kennzahlen in einem fragmentierten Ökosystem aus über 15 verschiedenen Quellsystemen:
- ERP-Systeme: SAP und Oracle in verschiedenen Landesgesellschaften
- CRM: Salesforce für den Vertrieb, ein Legacy-CRM für den Kundenservice
- Operative Systeme: Warehouse Management, Transport Management, Custom-Anwendungen
- Flat Files: CSV-Exporte von Partnern und Kunden, tägliche Lieferdateien
- APIs: Echtzeit-Daten von IoT-Sensoren und Tracking-Systemen
Die Konsequenzen:
- Kein einheitliches Kundenbild — dieselbe Firma existierte in 4 Systemen mit 4 verschiedenen Schreibweisen
- Berichte widersprachen sich, weil die Quellsysteme unterschiedliche Aggregationslogiken verwendeten
- Manuelle Datenabgleiche kosteten das Controlling-Team 3 Vollzeit-Stellen
- Neue Reportanforderungen dauerten Wochen, weil jede Datenquelle individuell angebunden werden musste
Herausforderung
Die Anforderungen an eine ETL-Plattform waren spezifisch:
- Heterogene Quellen: SQL-Datenbanken, REST APIs, SFTP-Dateien, SAP RFC — alles muss integrierbar sein
- Datenqualität: Automatische Bereinigung, Deduplizierung und Validierung vor dem Laden
- Skalierbarkeit: Heute 50 GB tägliches Datenvolumen, in 2 Jahren voraussichtlich 200 GB
- Self-Service: Das BI-Team soll einfache ETL-Workflows selbst erstellen können — ohne Entwickler
- Auditierbarkeit: Jeder Datensatz muss rückverfolgbar sein (Quelle, Zeitpunkt, Transformationsschritte)
- Kosten: Keine Enterprise-ETL-Lizenz im sechsstelligen Bereich
Lösung
Wir entschieden uns für KNIME Analytics Platform als zentrale ETL-Engine — aus drei Gründen:
- Open Source Core: Keine Lizenzkosten für die Kernplattform
- Visual Workflow Designer: Drag-and-Drop-Workflows, die auch Nicht-Entwickler lesen und anpassen können
- Konnektoren: Native Unterstützung für SAP, Oracle, Salesforce, REST APIs und Dateiformate
Architektur
Quellsysteme → KNIME ETL Server → Staging Area → Data Warehouse → BI Layer
SAP (Orchestrierung) (Roh-Daten) (Star Schema) (Power BI)
Oracle (Scheduling) (Validierung) (KPI-Tabellen)
Salesforce (Monitoring) (Bereinigung)
CSV/APIs (Error Handling) (Deduplizierung)ETL-Workflows
Wir implementierten 35 ETL-Workflows in KNIME, organisiert in drei Schichten:
Schicht 1: Extraktion (12 Workflows)
- SAP-Extraktion über RFC-Connector (Kundenstamm, Aufträge, Finanzen)
- Oracle-Extraktion über JDBC (operative Daten)
- Salesforce-Extraktion über REST API (Leads, Opportunities)
- Datei-Ingestion über SFTP-Watcher (tägliche Partner-Dateien)
Schicht 2: Transformation (15 Workflows)
- Master Data Matching: Fuzzy-Matching für Kundennamen und Adressen (Levenshtein-Distanz)
- Deduplizierung: Identifikation und Zusammenführung von Duplikaten über Quellsysteme hinweg
- Standardisierung: Einheitliche Formate für Datum, Währung, Ländercodes
- Berechnung: Abgeleitete KPIs (Durchlaufzeit, Auslastung, Kosten pro Sendung)
Schicht 3: Laden (8 Workflows)
- Inkrementelles Laden in den Data Warehouse (nur geänderte Datensätze)
- Star-Schema-Befüllung mit Dimensions- und Faktentabellen
- Fehlerhafte Datensätze in Quarantäne-Tabelle mit Alert
Datenqualitäts-Framework
Ein zentraler Bestandteil der Lösung war das automatisierte Datenqualitäts-Framework:
| Prüfung | Regel | Aktion bei Verstoß |
|---|---|---|
| Vollständigkeit | Pflichtfelder befüllt? | Quarantäne + Alert |
| Plausibilität | Umsatz > 0, Datum in der Zukunft? | Warnung + Review |
| Konsistenz | Kundenname in SAP = Kundenname in CRM? | Fuzzy-Match + manuelles Review |
| Aktualität | Daten älter als 48 Stunden? | Re-Extraktion auslösen |
| Duplikate | Gleicher Kunde in mehreren Quellen? | Merge-Regel anwenden |
Ergebnisse
Nach 8 Monaten im Produktivbetrieb:
- Datenquellen integriert: 15 (von zuvor 6 manuell angebundenen)
- Datenvolumen: 65 GB tägliche Verarbeitung, zuverlässig innerhalb des 4-Stunden-Ladefensters
- Duplikate bereinigt: 12.000 Kunden-Duplikate identifiziert und zusammengeführt
- Controlling-Aufwand: 2,5 FTE eingespart durch automatische Datenabgleiche
- Report-Erstellungszeit: von Wochen auf Tage für neue Reports (Daten sind bereits im Warehouse)
- Datenqualitäts-Score: von geschätzt 62 % auf gemessene 94 %
Lessons Learned
1. Datenqualität vor Integration
Wir haben in den ersten 6 Wochen nur Datenqualität gemessen — ohne etwas zu laden. Die Erkenntnis, dass 38 % der Kundendaten Qualitätsprobleme hatten, hat den Scope des Projekts fundamental verändert.
2. KNIME ist kein Spielzeug
Die visuelle Oberfläche verleitet zu der Annahme, dass KNIME für „einfache” Aufgaben ist. In der Praxis haben wir komplexe Fuzzy-Matching-Algorithmen, parallele Verarbeitung und Error Handling implementiert — alles visuell, aber nicht trivial.
3. Monitoring ist nicht optional
Ein ETL-Workflow, der stillschweigend fehlschlägt, ist schlimmer als keiner. Wir implementierten ein Monitoring-Dashboard, das jeden Workflow-Lauf protokolliert: Startzeit, Laufzeit, verarbeitete Datensätze, Fehler und Warnungen.