Vom manuellen Reporting zur zentralen Datenplattform mit Databricks

Die Datenlandschaft war über Jahre entlang einzelner Fachprozesse gewachsen. SAP S/4HANA bildete die operativen Kernprozesse ab, SharePoint und Excel übernahmen bereichsübergreifende Auswertungen, eine interne Anwendung ergänzte fachliche Sonderprozesse. Für ein gemeinsames Reporting mussten diese Datenwelten regelmäßig manuell zusammengeführt werden.

Jeder Report folgte einem ähnlichen Ablauf: Exporte aus SAP S/4HANA ziehen, Excel-Dateien aus SharePoint einsammeln, Daten aus der Fachanwendung ergänzen, Dubletten prüfen und Kennzahlen zwischen den Beteiligten abstimmen. Die Ergebnisse standen am Ende bereit, der Weg dorthin band jedoch jeden Monat wertvolle Kapazitäten und erschwerte eine schnelle, reproduzierbare Analyse.

Parallel stand die Modernisierung der bestehenden Datenarchitektur an. Das gewachsene Legacy-Data-Warehouse verursachte hohen Betriebsaufwand und setzte Grenzen bei Skalierbarkeit, Kostensteuerung und der Anbindung neuer Quellen. Die neue Plattform musste deshalb bestehende Reporting-Strecken schrittweise ablösen und gleichzeitig eine tragfähige Grundlage für weitere Datenprodukte schaffen.

Für den Aufbau brauchte es zusätzlich ein realistisches Betriebsmodell. Das interne Team verfügte über starkes Fach- und Prozesswissen, hatte aber erst wenig praktische Erfahrung mit Databricks, Delta-basierten Pipelines und dem Betrieb einer modernen Cloud-Datenplattform. Architektur, Umsetzung und Enablement mussten deshalb von Beginn an zusammengedacht werden.

Eine gezielte Punktlösung hätte den ersten Reporting-Bedarf schnell abdecken können: ein Data Warehouse, ein BI-Tool und wenige Schnittstellen. Für das Unternehmen ging es jedoch um eine größere Aufgabe. Die gewachsene Excel- und Reporting-Landschaft sollte durch eine zentrale, automatisierte Datenbasis ersetzt werden, die weitere Quellen und Fachbereiche aufnehmen kann.

SAP S/4HANA liefert strukturierte Geschäftsdaten, SharePoint enthält fachlich gepflegte Excel-Dateien mit wechselnden Layouts und die interne Anwendung bildet zusätzliche Prozesse in PostgreSQL ab. Zwischen diesen Systemen entstanden manuelle Exporte, Dateiübergaben, Mapping-Tabellen und wiederkehrende Abstimmungen. Versionen mussten geprüft, Dubletten bereinigt und Kennzahlen über mehrere Arbeitsstände hinweg abgeglichen werden.

Damit fehlte eine verlässliche Single Source of Truth. Fachbereiche arbeiteten mit unterschiedlichen Dateiständen, lokalen Berechnungslogiken und individuell gepflegten Excel-Modellen. Fachwissen war dadurch eng an einzelne Dateien und Personen gebunden. Jede Anpassung an einer Quelle oder Kennzahl erzeugte zusätzlichen Abstimmungs-, Test- und Pflegeaufwand.

Gemeinsam mit ruhrdot bewertete das Unternehmen die Plattformoptionen entlang klarer Anforderungen: heterogene Quellen zentral integrieren, Excel-basierte Konsolidierungsstrecken automatisieren, fachliche Definitionen vereinheitlichen und Datenqualität sowie Governance dauerhaft verankern. Die neue Architektur sollte aus manuellen Reporting-Prozessen wiederverwendbare Datenprodukte machen.

Databricks überzeugte als gemeinsamer Plattformansatz für Ingestion, Storage, Transformation, Datenqualität und Governance. Daten aus SAP S/4HANA, SharePoint und PostgreSQL werden automatisiert verarbeitet und in kuratierten Gold-Datensätzen zusammengeführt. Tableau greift auf diese zentralen Datenprodukte zu. So entsteht eine Single Source of Truth für Reporting und Analyse, während Excel weiterhin als Konsumwerkzeug genutzt werden kann, wo es fachlich sinnvoll ist.

Vor der technischen Umsetzung entstand gemeinsam mit ruhrdot eine schlanke Daten- und Architekturstrategie. Sie definierte, welche Datenprodukte das Business zuerst benötigt, welche Quellen in Bronze aufgenommen werden, welche Harmonisierung in Silver erfolgt und welche konsolidierten Datensätze in Gold als Single Source of Truth für Tableau bereitstehen.

Der Blueprint regelte zugleich das spätere Betriebsmodell: klare Rollen für Plattform und Datenprodukte, verbindliche Standards für Namensgebung, Metadaten, Datenqualität und Zugriffe sowie ein einheitliches Muster für die Anbindung weiterer Quellen. Damit wurden fachliche Definitionen und technische Umsetzung von Beginn an gemeinsam strukturiert.

Die Architektur basiert auf etablierten Databricks-Standards: Medallion-Layering, Delta Lake als Storage-Fundament und Lakeflow Jobs für Ingestion, Transformation und Orchestrierung. Wiederverwendbare Plattformbausteine reduzieren den individuellen Entwicklungs- und Wartungsaufwand und schaffen ein Fundament, das ein wachsendes internes Data-Team zuverlässig betreiben kann.

Enablement war fester Bestandteil der Umsetzung. Das interne Team arbeitete im Pair Engineering an den ersten Pipelines mit, reviewte Delta-Tabellen und Datenmodelle und erhielt Runbooks für Deployment, Monitoring und wiederkehrende Betriebstätigkeiten. Regelmäßiges Architektur-Sparring unterstützte den schrittweisen Kompetenzaufbau.

So übernimmt das Kundenteam die Plattform dauerhaft selbst: neue Quellen anbinden, Pipelines weiterentwickeln, Datenqualität überwachen und kuratierte Datenprodukte für Reporting und Analyse bereitstellen. ruhrdot begleitet den Ausbau als Consulting- und Sparringspartner.