ETL-Strecken, die keiner mehr anfasst: wann sich die Ablösung lohnt

In fast jedem Unternehmen mit gewachsenem Reporting gibt es sie: die ETL-Strecke, die keiner mehr anfasst. Sie läuft nachts, sie liefert Zahlen, und niemand kann im Detail erklären, was sie tut. Solange sie durchläuft, ist das ein Randthema. Auffällig wird es erst, wenn jemand eine Kennzahl ändern will – oder wenn zwei Berichte unterschiedliche Umsätze zeigen. Wie wir Datenstrecken und Reporting aufsetzen, steht auf unserer Seite zu Business Intelligence und ETL.

Woran man eine Strecke am Lebensende erkennt

Die Symptome sind erstaunlich einheitlich, unabhängig davon, ob die Strecke in SSIS, Talend, einem Stapel SQL-Skripte oder in einer selbstgebauten Job-Steuerung läuft:

• Niemand ändert sie freiwillig. Anpassungen werden aufgeschoben oder daneben gebaut, statt in der Strecke selbst vorgenommen. Das ist das verlässlichste Warnsignal.
• Es gibt manuelle Zwischenschritte. Eine Excel-Datei, die jemand morgens ablegt, ein Makro, ein Zwischenexport. Was als Übergangslösung begann, ist Teil des Produktivbetriebs geworden.
• Die Logik steht nur im Code. Warum ein Umsatz ab einem bestimmten Datum anders berechnet wird, weiß der Kollege, der vor drei Jahren gegangen ist – oder eine verschachtelte CASE-Anweisung, die niemand liest.
• Die Laufzeit wächst schneller als die Datenmenge. Ein Zeichen dafür, dass jedes neue Anforderungspaket zusätzlich verarbeitet wird, statt bestehende Schritte anzupassen.
• Fehler fallen erst der Fachabteilung auf. Nicht die Strecke meldet den Abbruch, sondern jemand wundert sich über eine leere Spalte im Bericht.

Zwei oder drei dieser Punkte sind normal in gewachsenen Systemen. Fünf davon bedeuten, dass die Strecke technische Schulden ausbezahlt, die irgendwann fällig werden.

Das eigentliche Risiko ist nicht die Technik

Man würde erwarten, dass alte Strecken an Performance scheitern. In der Praxis scheitern sie am Vertrauen. Sobald zwei Berichte für dieselbe Kennzahl unterschiedliche Werte zeigen, beginnt in der Fachabteilung eine Parallelwelt: Jemand baut sich eine eigene Excel-Auswertung, weil man „den Zahlen im Dashboard nicht trauen kann“. Von da an gibt es zwei Wahrheiten, und die teurere davon ist die, die niemand kennt.

Ein Dashboard, dem die Fachabteilung nicht glaubt, ist schlimmer als keines. Es kostet Geld im Betrieb und wird trotzdem nicht für Entscheidungen genutzt.

Genau deshalb ist die Frage, ob eine Strecke abgelöst gehört, keine rein technische. Sie entscheidet sich daran, ob die Zahlen noch als verbindlich gelten.

Was sich seit dem klassischen ETL verändert hat

Der klassische Aufbau transformiert Daten unterwegs und lädt das Ergebnis ins Zielsystem. Was dabei zwischendrin passiert, ist später schwer nachvollziehbar – die Rohdaten sind in dieser Form nirgends mehr vorhanden.

Moderne Aufbauten drehen die Reihenfolge um: Erst laden, dann im Zielsystem transformieren. Der Vorteil ist weniger die Geschwindigkeit als die Nachvollziehbarkeit. Wenn die Rohdaten unverändert liegen bleiben und jede Transformation als versionierter, testbarer Schritt darauf aufsetzt, lässt sich die Frage „warum steht hier diese Zahl?“ beantworten, ohne den Job neu zu starten. Werkzeuge wie dbt haben genau das zum Standard gemacht; auf Plattformseite gehen Power BI und Microsoft Fabric in dieselbe Richtung.

Das heißt nicht, dass jede bestehende Strecke umgebaut gehört. Es heißt, dass eine Strecke, die ohnehin angefasst werden muss, nicht im alten Muster nachgebaut werden sollte.

Ablösen ohne Big Bang

Der häufigste Fehler bei der Ablösung ist die Stichtagsumstellung. Sie klingt sauber und erzeugt genau die Situation, die man vermeiden will: Am Montag liefert das neue System andere Zahlen als das alte am Freitag, und niemand kann sagen, welche stimmen.

Der belastbare Weg ist der Parallelbetrieb. Die neue Strecke läuft eine Zeit lang neben der alten, ohne dass jemand seine Berichte umstellt. Beide Ergebnisse werden automatisiert verglichen, und jede Abweichung wird einzeln geklärt – wobei sich regelmäßig herausstellt, dass die neue Strecke recht hat und die alte einen seit Jahren unbemerkten Fehler enthielt. Genau diese Abweichungen sind der eigentliche Gewinn der Umstellung, denn sie decken auf, worüber vorher niemand Bescheid wusste. Erst wenn die Differenzen erklärt sind, wird umgeschaltet; die alte Strecke bleibt danach noch eine Weile lauffähig.

Umgestellt wird dabei nicht alles auf einmal, sondern entlang fachlicher Bereiche – erst der Umsatz, dann die Lagerbestände, dann das Controlling. Das dauert länger und ist der einzige Weg, bei dem die Fachabteilung mitkommt.

Datenqualität lässt sich nicht in die Strecke hineinreparieren

Eine Erwartung, die regelmäßig enttäuscht wird: dass die neue Strecke die Datenqualität mitverbessert. Das tut sie nicht. Sie macht die vorhandenen Probleme nur sichtbarer, weil sie sie nicht mehr stillschweigend wegrechnet.

Dubletten, uneinheitliche Schreibweisen und fehlende Zuordnungen entstehen in den Quellsystemen und müssen dort behandelt werden. Eine Transformationsschicht, die das kaschiert, verlagert das Problem nur – und wird selbst zu der undurchsichtigen Logik, die man gerade loswerden wollte. Dieselbe Mechanik gilt bei Systemwechseln; wir haben sie im Beitrag zur verlustfreien Datenmigration beschrieben.

Wann sich der Umbau lohnt – und wann nicht

Er lohnt sich, wenn die Strecke Änderungen blockiert, wenn Zahlen in Frage stehen, wenn ohnehin ein Quellsystem gewechselt wird, oder wenn das Wissen über die Strecke nur noch an einer Person hängt. Dieser letzte Punkt wird gern unterschätzt, bis die Person kündigt.

Er lohnt sich nicht, wenn die Strecke stabil läuft, ihre Logik dokumentiert ist und niemand Änderungsbedarf hat – auch wenn sie technisch veraltet wirkt. „Läuft seit acht Jahren fehlerfrei“ ist ein Qualitätsmerkmal, kein Mangel. Modernisierung ohne Anlass ist Beschäftigung, nicht Wertschöpfung.

Ein pragmatischer Zwischenschritt für den Graubereich: die bestehende Strecke nicht umbauen, aber sichtbar machen. Monitoring auf Laufzeiten und Abbrüche, ein automatischer Plausibilitätstest auf die wichtigsten Kennzahlen, und die fachliche Logik einmal aufgeschrieben. Das kostet wenige Tage und nimmt der Sache den größten Teil des Risikos.

Fazit

Die Frage ist selten, ob eine ETL-Strecke technisch veraltet ist – das sind viele, ohne Schaden anzurichten. Die Frage ist, ob sie noch Vertrauen trägt und ob sich Änderungen darin noch durchführen lassen. Wo beides nicht mehr gegeben ist, hilft kein weiterer Anbau, sondern eine Ablösung im Parallelbetrieb, fachlich in Etappen und mit automatisiertem Abgleich gegen den Bestand. Wenn Sie einschätzen wollen, wo Ihre Strecken stehen, sprechen Sie uns an – oft reicht ein Blick auf Laufzeiten, Änderungshistorie und die Frage, wer die Logik erklären kann.