Zum Inhalt springen
Databricks Lakehouse für Reporting: PoC bei europäischem Schuhhersteller

Databricks Lakehouse für Reporting: PoC bei europäischem Schuhhersteller

Wie ein europäischer Schuhhersteller mit Databricks, Unity Catalog und Power BI einen Lakehouse-PoC für zentrale KPIs, Governance und Reporting umsetzt.

Lesedauer4 Min.
VeröffentlichtJuli 2026

Die wichtigsten Ergebnisse

  • Nutzen produktiv nachgewiesen

    Planned vs. Actual Sales lief als erster Use Case nah genug am Tagesgeschäft, um den Wert direkt zu bewerten.

  • 0 Toolwechsel für Endnutzer

    Power BI und Excel bleiben — die Plattform ändert das Fundament, nicht die Arbeitsweise der Fachbereiche.

  • Qualität früh im Datenfluss

    Fehlende Werte und Formatabweichungen werden in der Pipeline sichtbar statt am Monatsende manuell korrigiert.

Zusammenfassung

Der Kunde ist ein etablierter europäischer Schuhhersteller mit rund 20.000 Mitarbeitenden weltweit. Produktion, Design, Vertrieb und Logistik sind international verteilt, die Datenlandschaft ist über Jahre mitgewachsen: ERP-Systeme, Cloud-Dienste, On-Premise-Anwendungen und fachbereichsnahe Reporting-Lösungen existierten parallel.

Die Fachbereiche arbeiteten intensiv mit Power BI und Excel. Das machte Reporting schnell verfügbar, führte aber zu vielen lokalen Datenwegen. ERP, Vertrieb, Logistik und Finance lieferten jeweils eigene Extrakte, die in den Bereichen weiterverarbeitet wurden. Kennzahlen waren dadurch nutzbar, aber nicht durchgängig zentral definiert, governance-geführt oder wiederverwendbar.

Für ein Unternehmen dieser Größe wurde das zum Skalierungsthema. Mit jeder Region, jedem Vertriebsland und jedem Logistikzentrum nahm die Zahl der Datenquellen, Abstimmungen und Reporting-Varianten zu. Was fehlte, war ein gemeinsames Fundament, das dezentrale Auswertungen weiter ermöglicht, aber Datenqualität, Governance und KPI-Definitionen zentral absichert.

Übersicht

Kunde
Schuhhersteller
Anonymisierte Referenz

Verwendete Technologien & Systeme

Apache Spark
Apache Spark
Azure Cloud
Azure Cloud
Power BI
Power BI
Databricks Unity Catalog
Databricks Unity Catalog
SQL Warehouse
SQL Warehouse
Databricks Delta Lake
Databricks Delta Lake
Die Transformation

Von der dezentralen Excel-Analyse zur zentralen Datenplattform.

01Ausgangssituation

Wenn jeder Bereich seine eigene Wahrheit rechnet.

Die IT-Landschaft war gewachsen, stabil und funktional. ERP, Vertriebssysteme, Logistiksteuerung und Finance liefen zuverlässig, teils On-Premise, teils in der Cloud. Was fehlte, war die verbindende Ebene: eine zentrale Datenplattform, auf der Fachbereiche mit denselben Datenständen, Definitionen und Zugriffsregeln arbeiten.

Ohne diese gemeinsame Basis entstanden Kennzahlen dezentral. Controlling, Vertrieb und Logistik zogen eigene Extrakte, wendeten eigene Transformationen an und bereiteten Reports für ihre jeweiligen Anforderungen auf. Die Ergebnisse waren fachlich nachvollziehbar, aber nicht immer deckungsgleich. Umsatz, Absatz, Bestandsreichweite oder Lieferperformance konnten je nach Quelle, Filter und Berechnungslogik unterschiedlich ausfallen.

Für das Management wurde damit nicht der Report selbst zum Problem, sondern die Abstimmung davor. Bevor Zahlen als Entscheidungsgrundlage dienten, musste geklärt werden, aus welchem System sie stammen, welche Logik angewendet wurde und welche Version gerade maßgeblich ist. Das kostete Zeit und schwächte das Vertrauen in Daten als gemeinsame Steuerungsgrundlage.

Der nächste Schritt war deshalb kein weiteres Reporting-Projekt, sondern ein gemeinsames Datenfundament: dezentrale Analysen sollten möglich bleiben, aber KPI-Definitionen, Governance und Datenqualität zentral abgesichert werden.

Wenn dieselbe Kennzahl je Fachbereich anders entsteht, wird Reporting zur Abstimmungsschleife statt zur Entscheidungsgrundlage.
Schuhhersteller: Kapitel 01
02Herausforderung

Proof of Concept mit strategischem Rahmen

Ein globaler Data-Warehouse-Rollout in einer gewachsenen Konzernlandschaft wäre ein mehrjähriges Programm gewesen. Der Kunde brauchte zuerst eine belastbare Entscheidungsgrundlage: Passt ein Lakehouse-Ansatz zur vorhandenen Datenlandschaft, zum Reporting-Bedarf und zur bestehenden Power-BI- und Excel-Nutzung?

Gemeinsam mit ruhrdot wurde der Proof of Concept deshalb bewusst klar begrenzt, aber strategisch gedacht. Databricks wurde anhand konkreter Anforderungen bewertet: heterogene Datenquellen auf Azure integrieren, zentrale Reporting-Tabellen governance-geführt bereitstellen, Row-Level Security auf der Plattform abbilden und Power BI ohne zusätzlichen Umweg anbinden.

Der PoC war damit der erste Baustein einer Data Strategy: Reporting und Governance als Startpunkt, spätere Self-Service-, Analytics- und Machine-Learning-Use-Cases als anschlussfähige Ausbaustufen.

Der PoC beantwortete nicht nur eine Technologiefrage, sondern die Frage nach dem richtigen Plattformpfad.
Schuhhersteller: Kapitel 02
03Strategie

Erst der relevante Use Case, dann die Plattform

Vor der ersten Pipeline wurde gemeinsam mit ruhrdot festgelegt, welcher Use Case den Proof of Concept tragen soll. Die Wahl fiel auf Planned vs. Actual Sales: ein Bericht, der im Controlling regelmäßig benötigt wird, mehrere Quellsysteme verbindet und heute manuelle Abstimmung erfordert. Damit war der PoC nah genug am Tagesgeschäft, um seinen Nutzen direkt bewerten zu können.

Die Architektur wurde bewusst schlank gehalten. Daten aus nativen ERP-Systemen und weiteren Fachquellen laufen in eine Medallion-Architektur mit Bronze, Silver, Gold und Reporting-Layer. Unity Catalog übernimmt Governance und Zugriffssteuerung, Delta Lake bildet das Datenfundament. Im Gold-Layer entsteht ein dimensionales Modell mit Star Schema, auf dem Power BI zentral konsumieren kann.

Wichtig war nicht nur der technische Nachweis, sondern das spätere Betriebsmodell. Row-Level Security stellt sicher, dass unterschiedliche Rollen denselben zentralen Report nutzen können, aber nur die jeweils freigegebenen Daten sehen. Interne Data-Rollen wurden von Beginn an eingebunden, damit der PoC verstanden, erweitert und in eine größere Data Strategy überführt werden kann.

Leitprinzip: Ein konkreter Business-Use-Case liefert den Nachweis, ob der Plattformansatz trägt.
Schuhhersteller: Kapitel 03
04Lösung

Ein Lakehouse-PoC, ein Reporting-Layer, ein Power-BI-Dashboard

Im PoC entstand ein klarer Datenpfad von den Quellsystemen bis zum Power-BI-Report. Databricks läuft auf Microsoft Azure, Unity Catalog bildet die Governance-Schicht. Daten aus nativen ERP-Systemen und weiteren Fachquellen werden automatisiert angebunden und entlang der Medallion-Architektur verarbeitet: Bronze nimmt die Rohdaten auf, Silver bereinigt und harmonisiert, Gold modelliert die fachlichen Entitäten. Der Reporting-Layer stellt die Tabellen bereit, aus denen Power BI direkt liest.

Datenqualität ist Teil der Pipeline. Fehlende Werte, Formatabweichungen und Inkonsistenzen werden früh im Datenfluss sichtbar, statt erst am Monatsende manuell korrigiert zu werden. KPI-Definitionen liegen zentral im Reporting-Layer, sodass Planned vs. Actual Sales aus einer gemeinsamen Quelle berechnet wird.

Governance wurde von Anfang an mitgeführt. Unity Catalog regelt Ownership, Zugriffe und Lineage über alle Layer hinweg. Row-Level Security sorgt dafür, dass verschiedene Nutzergruppen denselben zentralen Report verwenden können, aber nur die für sie freigegebenen Daten sehen. Ein Datenmodell, ein Report, mehrere berechtigungsgesteuerte Sichten.

Der PoC zeigt: Ein Lakehouse kann zur Single Source of Truth werden, ohne dass Fachbereiche ihr gewohntes Power-BI-Setup aufgeben müssen.
Schuhhersteller: Kapitel 04
Lakehouse-PoCAuf Microsoft Azure
1 Use Caseproduktiv nachgewiesen
0 ToolwechselPower BI & Excel bleiben

Zielarchitektur

Lakehouse-Grundgerüst auf Azure für ein globales Consumer-Goods-Setup.

Native Konnektoren binden ERP und weitere Fachquellen automatisiert an. Databricks lädt in Bronze, verarbeitet über Silver in einen dimensional modellierten Gold-Layer und stellt einen aggregierten Reporting-Layer für Power BI bereit. Governance und Zugriff laufen zentral über Unity Catalog. Quellsysteme Databricks Data Intelligence Platform (Managed · Azure · Unity Catalog) Workloads Deployment & Betrieb: Pipelines · Jobs · Enablement Lakeflow Jobs · native Quellsystem-Konnektoren · Runbooks.

Bausteine

  • ERP: Auftragsdaten · Stammdaten · Planwerte
  • Vertriebssysteme: Absatz · Umsatz · Kunden
  • Logistiksteuerung: Sendungen · Bestände · Standorte
  • Finance: Ist-Umsatz · Kostenstruktur
  • Flatfiles: historische Auszüge · manuelle Uploads
  • Governance: Unity Catalog · RBAC · Row-Level-Security · Lineage · Audit
  • Data Ingestion: Bronze (Raw) -> Silver (Cleansed) -> Gold (Star Schema) -> Reporting (Pre-Aggregated)
  • Foundation: Delta Lake · PySpark · Apache Spark · native Quellsystem-Konnektoren
Platform Outcomes

Was der PoC strukturell nachgewiesen hat

Gemeinsame Datenbasis für zentrale Kennzahlen

ERP, Vertrieb, Logistik und Finance laufen über automatisierte Pipelines in eine gemeinsame Lakehouse-Architektur. Fachbereiche konsumieren aus denselben Gold- und Reporting-Layern, statt parallele Datenstände in lokalen Reports weiterzuführen.

Reporting-Layer für Power BI und Excel

Power BI liest direkt auf zentral bereitgestellten Reporting-Tabellen. Endnutzer können weiter in ihren gewohnten Werkzeugen arbeiten, während KPI-Definitionen und Datenqualität auf der Plattform abgesichert werden.

Governance und Row-Level Security ab Tag 1

Unity Catalog regelt Ownership, Zugriffe und Lineage über alle Layer. Row-Level Security ermöglicht eine zentrale Reporting-Tabelle mit unterschiedlichen berechtigungsgesteuerten Sichten, ohne Reports je Rolle oder Region zu duplizieren.

Reproduzierbares Architekturmodell statt Einzellösung

Bronze, Silver, Gold und Reporting-Layer bilden ein wiederverwendbares Muster für weitere Datenquellen und Use Cases. Der PoC liefert damit nicht nur ein Dashboard, sondern einen ersten Baustein der Data Strategy.

Anschlussfähig für Self-Service, Analytics und ML

Die Plattform ist so aufgebaut, dass spätere Self-Service-Analytics-, Machine-Learning- und AI-Use-Cases auf derselben Datenbasis entstehen können. Neue Ausbaustufen benötigen keinen Architekturbruch, sondern erweitern das bestehende Lakehouse-Fundament.

Vorher / Nachher

Was sich konkret verändert hat

Vorher

Nachher

Reporting

KPIs wurden in den Fachbereichen aus dezentralen Extrakten aufgebaut
Zentrale Reporting-Tabellen liefern voraggregierte Daten für Power BI

KPI-Konsistenz

Dieselbe Kennzahl konnte je Bereich, Quelle oder Filterlogik unterschiedlich ausfallen
KPI-Definitionen liegen zentral im Reporting-Layer

Datenintegration

Quellsysteme wurden manuell oder über Einzelausleitungen angebunden
Automatisierte Ingestion führt ERP-, Vertriebs-, Logistik- und Finance-Daten in eine Medallion-Architektur

Governance

Zugriffe und Sichtbarkeiten wurden über Berichtskopien oder lokale Logik gelöst
Unity Catalog regelt RBAC, Lineage und Row-Level Security auf zentralen Datenobjekten

Analytics-Werkzeuge

Power BI und Excel arbeiteten auf unterschiedlichen Extrakten
Power BI und Excel konsumieren direkt aus dem Lakehouse-Reporting-Layer

Nächste Schritte

Vom PoC-Fundament zur skalierbaren Data Platform

Der PoC liefert den ersten belastbaren Baustein für die weitere Data Strategy: zusätzliche Quellen, mehr Reporting-Domänen und spätere Advanced-Analytics- und ML-Use-Cases können auf demselben Lakehouse-Fundament entstehen.

1

Weitere Quellsysteme und Reporting-Domänen integrieren

Zusätzliche Vertriebs-, Logistik- und Finance-Daten werden über das bestehende Bronze-, Silver-, Gold- und Reporting-Muster angebunden. Neue Reporting-Layer entstehen als Erweiterung der Plattform, nicht als erneuter Einzelaufbau.

2

Self-Service-Analytics für Fachbereiche ausbauen

Vertrieb, Logistik und Controlling greifen über Power BI, Excel oder SQL-Zugänge direkt auf freigegebene Datenprodukte zu. Standardauswertungen können damit näher am Fachbereich entstehen, während KPI-Definitionen und Governance zentral abgesichert bleiben.

3

Advanced Analytics und ML auf derselben Datenbasis ermöglichen

Absatzprognosen, Bestandsoptimierung und weitere ML-Use-Cases setzen auf denselben Gold-Layern auf wie das Reporting. Dadurch entstehen BI, Self-Service und Machine Learning nicht in getrennten Datenwelten, sondern auf einem gemeinsamen, governance-geführten Fundament.

Steht eure Datenplattform vor einer ähnlichen Skalierungsfrage?

Wenn Daten aus vielen Systemen, Bereichen oder Regionen zusammenkommen, reicht ein einzelner Report oft nicht mehr aus. Entscheidend ist ein gemeinsames Fundament: konsolidierte Daten, klare Governance und ein Betriebsmodell, das mit neuen Quellen und Use Cases mitwächst. Wir prüfen mit euch, ob ein Lakehouse-Ansatz für eure Datenlandschaft sinnvoll ist und welcher erste produktive Schritt realistisch erreichbar ist.

Alexander Rabe
Alexander Rabe
Co-Founder · Head of Data & AI

FAQ

Häufig gestellte Fragen