Neue Data Platform für Reporting bei einem Energieversorger

Ausgangslage

Das zentrale Reporting-Data-Warehouse eines Energieversorgers basierte auf Oracle und BODS. Nach vielen Jahren organischem Wachstum hatte die Plattform ihr Performance-Limit erreicht: Reports wurden langsamer, Datenvolumen stiegen weiter, und die laufenden Betriebs-, Infrastruktur- und Administrationskosten wuchsen überproportional.

Eine reine Erweiterung der Altplattform war keine realistische Option. Gleichzeitig war das Reporting geschäftskritisch – ein Big-Bang-Wechsel hätte zu Unterbrechungen und Abweichungen geführt, die weder Controlling noch Vorstand akzeptieren würden. Gesucht war ein Weg, die Plattform grundlegend neu aufzustellen, ohne das Tagesgeschäft zu gefährden.

Was wir gebaut haben

Wir haben die Plattformneugestaltung über mehrere parallele Streams koordiniert und eine konsistente Zielarchitektur etabliert, die über alle Teilprojekte hinweg trägt. Die Migration lief inkrementell – mit Parallelbetrieb und kontinuierlicher Qualitätssicherung gegen das Altsystem.

• Parallele Arbeitsströme: Ingestion, Modellierung, Reporting-Migration und Infrastruktur liefen koordiniert, aber nicht seriell
• Konsistente Zielarchitektur – jede Einzelentscheidung in jedem Stream gemessen am übergreifenden Architektur-Zielbild
• Inkrementeller Go-Live – neue Reporting-Strecken gingen produktiv, während Alt-Reports weiter aus Oracle/BODS bedient wurden
• Parallelbetrieb und Abgleich – jede migrierte Datenstrecke wurde business-seitig gegen das Altsystem geprüft, bevor der Altreport abgeschaltet wurde
• ~450 neu entwickelte ETL-Jobs – konsistent strukturiert, getestet und dokumentiert, als Grundlage für stabilen Betrieb nach dem Projekt

Ergebnisse

Nach 2,5 Jahren war die neue Datenplattform für das Reporting produktiv. Die Altsystem-Landschaft (Oracle/BODS) konnte abgelöst werden, ohne dass im laufenden Betrieb Brüche entstanden sind. Die neue Plattform ist skalierbar – sowohl technisch als auch organisatorisch: weitere Fachbereiche können anschließen, ohne die Architektur aufzubrechen.

Der business-seitige Abgleich war der entscheidende Qualitätsanker: Keine Reportzahl hat sich durch die Migration in relevanter Weise verändert – und wo doch, wurde gemeinsam mit dem Fachbereich geklärt, welche Version die korrekte ist. Das hat Vertrauen in die neue Plattform aufgebaut, das auch in die Folgeprojekte getragen wird.

Lessons Learned

Eine Plattform-Migration dieser Größenordnung steht und fällt mit der Koordination paralleler Streams gegen ein konsistentes Zielbild. Wer die Streams unabhängig arbeiten lässt, bekommt am Ende ein Flickwerk – wer zu stark zentralisiert, bremst jede einzelne Entscheidung aus.

Die zweite Lektion betrifft den Parallelbetrieb: Er ist teurer und aufwendiger als ein Big Bang. Aber er ist die einzige realistische Option, um in einem reporting-kritischen Umfeld Vertrauen aufzubauen und Abweichungen sauber zu klären. Wer diese Phase zu kurz plant, spart an der falschen Stelle.