Zum Inhalt springen
Vom Monatsreport zur Data-&-AI-Plattform: Immobilien-Daten auf Databricks

Vom Monatsreport zur Data-&-AI-Plattform: Immobilien-Daten auf Databricks

Wie ein Immobiliendienstleister mit ruhrdot eine Data-&-AI-Strategie umsetzt, Fachsysteme konsolidiert und KI-Use-Cases wie Self-Service und RAG vorbereitet.

Lesedauer4 Min.
VeröffentlichtJuli 2026

Die wichtigsten Ergebnisse

  • Monatsreport ohne Handarbeit

    Das Reporting läuft automatisiert auf einer verlässlichen Datenbasis — statt jeden Monat neu zusammengesetzt zu werden.

  • 6+ Quellsysteme konsolidiert

    In rund sechs Monaten entstand ein zentrales Databricks Lakehouse auf AWS mit vereinheitlichten KPI-Definitionen.

  • Datenqualität sichtbar gemacht

    Dubletten, fehlende Werte und Inkonsistenzen erscheinen in der Pipeline — nicht erst am Monatsende in Tabellen.

  • KI auf derselben Basis

    Self-Service per Genie und eine KI-Wissensbank nutzen dieselben Datenobjekte und dieselbe Governance wie das Reporting.

Zusammenfassung

Der Kunde ist ein mittelständischer Immobiliendienstleister mit schlankem Team und breiter Datenlandschaft. Immobilienverwaltung, Finanzbuchhaltung, Dokumentenmanagement, Energie- und Verbrauchsdaten sowie externe Quellen lieferten wichtige Informationen für Management, Controlling und Portfoliosteuerung.

Die Systeme funktionierten im jeweiligen Fachkontext, aber nicht als gemeinsame Datenbasis. Kennzahlen mussten monatlich manuell zusammengeführt, geprüft und abgestimmt werden. Dadurch entstand hoher Aufwand genau dort, wo eigentlich schnelle Transparenz gefragt war.

Gemeinsam mit ruhrdot wurde ein zentrales Databricks Lakehouse auf AWS aufgebaut. Ziel war kein großes Plattformprogramm, sondern ein pragmatischer Einstieg: 6+ relevante Quellsysteme konsolidieren, KPI-Definitionen vereinheitlichen, Reporting automatisieren und auf derselben Datenbasis Self-Service per Genie sowie eine KI-Wissensbank über den gesamten Bestand bereitstellen. Das interne Team wurde befähigt, die Plattform selbst weiterzuentwickeln.

Übersicht

Kunde
Immobiliendienstleister
Anonymisierte Referenz

Verwendete Technologien & Systeme

Apache Spark
Apache Spark
AWS Cloud
AWS Cloud
Databricks Unity Catalog
Databricks Unity Catalog
SQL Warehouse
SQL Warehouse
Databricks Delta Lake
Databricks Delta Lake
Mosaic AI
Mosaic AI
Die Transformation

Von manueller Report-Erstellung zur einheitlichen Datenplattform

01Ausgangssituation

Wenn Reporting jeden Monat neu zusammengesetzt wird

Vor dem Projekt funktionierten die einzelnen Fachsysteme im jeweiligen Kontext: Immobilienverwaltung, Finanzbuchhaltung, Dokumentenmanagement sowie Energie- und Verbrauchsdaten lieferten die benötigten Informationen. Was fehlte, war eine gemeinsame Datenbasis für Management, Controlling und Portfoliosteuerung.

Jeden Monat mussten Daten exportiert, Tabellen zusammengeführt, Dubletten bereinigt und Kennzahlen abgeglichen werden. Die Reports waren am Ende verfügbar, aber der Weg dorthin war aufwendig, fehleranfällig und schwer skalierbar.

Für die Geschäftsführung bedeutete das: Zahlen mussten zunächst geprüft und erklärt werden, bevor sie als Entscheidungsgrundlage dienen konnten. Unterschiedliche Quellen erzeugten unterschiedliche Sichtweisen auf dieselben Sachverhalte. Mit jeder neuen Datenquelle wuchs der manuelle Aufwand, nicht die Transparenz.

Der eigentliche Bedarf betraf deshalb nicht einzelne Reports, sondern das Fundament darunter: eine verlässliche Datenbasis, die jeden Monat trägt und mit neuen Quellen mitwächst, statt monatlich neu zusammengesetzt zu werden.

Solange Reporting aus Einzelexporten entsteht, bleibt jede Management-Sicht erklärungsbedürftig.
Immobiliendienstleister: Kapitel 01
02Herausforderung

Reporting-Fundament statt weiterer Einzellösung

Ein klassisches Data Warehouse mit BI-Tool wäre der vertraute Weg gewesen. Für die vorhandene Datenlandschaft reichte ein reiner Reporting-Ansatz jedoch nicht aus. Die Quellen lieferten strukturierte Datenbanken, semi-strukturierte API-Antworten, Flatfiles und historische Auszüge. Diese Daten sollten nicht nur in Reports landen, sondern sauber integriert, nachvollziehbar verarbeitet und auch für Self-Service und KI-Use-Cases nutzbar sein.

Gemeinsam mit ruhrdot bewertete das Unternehmen die Plattformoptionen anhand konkreter Anforderungen: heterogene Quellen integrieren, KPI-Definitionen vereinheitlichen, Governance von Anfang an mitdenken, Reporting auf eine belastbare Datenbasis stellen und dieselbe Basis für natürlichsprachlichen Self-Service und KI-Anwendungen öffnen.

Databricks überzeugte, weil Lakehouse-Architektur, Delta Lake, Unity Catalog, Databricks SQL Warehouse und Mosaic AI in einer Plattform zusammenkommen. Damit entsteht kein separates Nebeneinander aus Data Lake, Warehouse, Reporting- und KI-Schicht, sondern ein gemeinsames Fundament für Datenaufnahme, Aufbereitung, Governance, BI-Konsum und KI-Anwendungen.

Die Entscheidung fiel nicht für ein weiteres Reporting-Werkzeug, sondern für eine Datenplattform, auf der Reporting, Self-Service und KI-Use-Cases gemeinsam aufsetzen.
Immobiliendienstleister: Kapitel 02
03Strategie

Erst das Zielbild, dann die Pipelines

Bevor die ersten Pipelines gebaut wurden, entstand gemeinsam mit ruhrdot eine schlanke Data Strategy. Im Mittelpunkt standen drei Fragen: Welche Datenprodukte braucht das Controlling zuerst? Welche Kennzahlen müssen verbindlich definiert werden? Und welches Betriebsmodell kann ein schlankes internes Team dauerhaft tragen?

Die Architektur wurde bewusst pragmatisch gewählt: Bronze, Silver und Gold als klares Layering, Delta Lake als Datenfundament, Unity Catalog als Governance-Schicht und Lakeflow Declarative Pipelines für automatisierte Pipelines. Ziel war kein überdimensioniertes Plattformprogramm, sondern ein belastbarer Startpunkt für Reporting, Controlling und spätere Analytics-Use-Cases.

Enablement lief von Beginn an mit. Das interne Team sollte nach dem Aufbau neue Quellen anbinden, Reports pflegen und Zugriffe selbst verwalten können. Die Plattform wurde deshalb nicht nur implementiert, sondern gemeinsam übergeben.

Leitprinzip: Die Plattform soll nicht vom Dienstleister abhängig bleiben, sondern beim Kunden betrieben und weiterentwickelt werden.
Immobiliendienstleister: Kapitel 03
04Lösung

Ein Lakehouse, 6+ Quellsysteme, ein Gold-Layer

In rund sechs Monaten entstand ein zentrales Databricks Lakehouse auf AWS. Daten aus Immobilienverwaltung, Finanzbuchhaltung, Dokumentenmanagement, Energie- und Verbrauchssystemen, externen APIs und Flatfiles laufen über automatisierte Pipelines in die Plattform.

Bronze nimmt die Rohdaten auf, Silver bereinigt und harmonisiert, Gold liefert die konsolidierten Datenprodukte für Reporting und Analyse. Management-Reports entstehen damit nicht mehr aus monatlichen Einzelexporten, sondern aus einem definierten, wiederverwendbaren Report-Layer.

Datenqualität ist Teil der Verarbeitung. Dubletten, fehlende Werte und Inkonsistenzen werden in der Pipeline sichtbar, statt erst am Monatsende in Tabellen korrigiert zu werden. KPI-Definitionen liegen zentral vor, sodass Kennzahlen nicht je Report neu interpretiert werden müssen.

Unity Catalog regelt Ownership, Zugriffe und Lineage. Wer welche Daten sehen darf und aus welchen Quellen eine Kennzahl entsteht, ist im Katalog nachvollziehbar.

Auf derselben Grundlage setzen die AI-Use-Cases auf: Über Genie stellen Fachbereiche natürlichsprachliche Fragen gegen die kuratierten Datenobjekte, eine RAG-gestützte Unternehmenswissensbank macht das Wissen über den gesamten Bestand durchsuchbar. Beide nutzen dieselben Datenobjekte und dieselbe Governance wie das Reporting, statt eine eigene Datenhaltung aufzubauen.

Der Gold-Layer wird zur gemeinsamen Grundlage: Reporting ist Konsum, nicht jeden Monat ein neuer Zusammenbau.
Immobiliendienstleister: Kapitel 04
0 HandarbeitMonatsreport läuft automatisch
6 Monatebis zum produktiven Lakehouse
6+ Quellsystemekonsolidiert auf einer Plattform

Zielarchitektur

Immobilien-Datenlandschaft im Lakehouse.

Sechs Quellsysteme laufen über automatisierte Pipelines in eine zentrale Lakehouse-Architektur auf Databricks. Medallion-Layer, SQL Warehouse und Reporting-Tools, governance-geführt über Unity Catalog. Quellsysteme Databricks Data Intelligence Platform (Managed · AWS · Unity Catalog) Workloads Deployment & Betrieb: Pipelines · CI/CD · Enablement Lakeflow Declarative Pipelines · Lakeflow Jobs · Runbooks.

Bausteine

  • Immobilienverwaltung: Objekte · Verträge · Mietverhältnisse
  • Finanzbuchhaltung: Buchungen · Zahlungsströme · Controlling
  • Dokumentenmanagement (DMS): Verträge · Rechnungen · Belege
  • Mieter- & Eigentümerportal: Serviceprozesse · Anliegen · Kommunikation
  • Energie- & Verbrauchsdaten: Energiemanagement · Heizkosten · Submetering
  • Externe APIs & Flatfiles: Portal- und Marktdaten · Historie
  • Governance: Unity Catalog · RBAC · Lineage · Audit
  • Data Ingestion: Bronze (Raw) → Silver (Cleansed) → Gold (Business-ready)
Platform Outcomes

Was sich durch die Plattform verändert hat

Eine zentrale Datenbasis für Management und Fachbereiche

Immobilienverwaltung, Finanzbuchhaltung, Dokumentenmanagement, Verbrauchsdaten und externe Quellen laufen in einer gemeinsamen Lakehouse-Architektur zusammen. Fachbereiche greifen auf denselben Gold-Layer zu, statt mit parallelen Zahlenständen zu arbeiten.

Automatisierte Reports statt manueller Zusammenführung

Management-Reports entstehen aus automatisierten Pipelines und definierten Datenprodukten. Der monatliche Aufwand für Exporte, Abgleich und Bereinigung sinkt deutlich.

Datenqualität als Teil des Betriebs

Dubletten, fehlende Werte und Inkonsistenzen werden in der Pipeline sichtbar. Datenqualität wird nicht erst am Monatsende geprüft, sondern laufend im Datenfluss überwacht.

Governance ab Tag 1

Unity Catalog regelt Ownership, Zugriffe, Lineage und Audit. Wer welche Kennzahl sehen darf und aus welchen Quellen sie entsteht, ist zentral nachvollziehbar.

Grundlage für Analytics und KI-Assistenz

Databricks SQL Warehouse, Genie, Vector Search und Mosaic AI setzen auf derselben governance-geführten Datenbasis auf. So entstehen Self-Service-Analytik und RAG-basierte Wissenssuche ohne separates Datenfundament.

Vorher / Nachher

Was sich konkret verändert hat

Vorher

Nachher

Reporting

Reports wurden manuell aus mehreren Fachsystemen zusammengesetzt
Automatisierte Reports entstehen aus dem konsolidierten Gold-Layer

Datenqualität

Dubletten, Lücken und Inkonsistenzen wurden erst am Monatsende bereinigt
Datenqualitätsprüfungen laufen direkt in den Pipelines

Kennzahlen

KPIs unterschieden sich je nach Quelle, Report oder Fachbereich
Einheitliche KPI-Definitionen liegen zentral im Datenmodell

Governance

Ownership, Zugriffe und Herkunft der Daten waren nicht durchgängig dokumentiert
Unity Catalog regelt Rechte, Ownership und Lineage zentral

Neue Datenquellen

Jede neue Quelle erforderte individuelle Integrationsarbeit
Bronze, Silver und Gold bilden ein wiederverwendbares Muster für weitere Quellen

Nächste Schritte

Vom Reporting-Fundament zu Self-Service und KI-Assistenz

Das Lakehouse bildet die Grundlage für die nächsten Ausbaustufen: weitere Quellen, breitere Self-Service-Analytik und zusätzliche KI-gestützte Use Cases auf derselben governance-geführten Datenbasis.

1

Weitere Quellsysteme integrieren

Zusätzliche Fachsysteme, Marktdaten und historische Bestände werden über das bestehende Bronze-, Silver- und Gold-Muster angebunden. Neue Quellen folgen damit einem wiederverwendbaren Integrationsweg statt individueller Sonderlogik.

2

Self-Service-Analytik ausweiten

Genie wird auf weitere Fachbereiche und Datenprodukte erweitert. Fachbereiche können häufiger direkt auf freigegebene Datenobjekte zugreifen und natürlichsprachliche Fragen stellen, ohne für einfache Auswertungen jedes Mal eine neue IT-Anfrage auszulösen.

3

KI-Use-Cases auf dem Lakehouse ausbauen

Die RAG-basierte Wissenssuche wird um weitere Anwendungsfälle ergänzt: Portfoliobewertung, Marktanalysen, Dokumentenprüfung und prädiktive Szenarien. Alle Use Cases nutzen dieselbe Datenbasis, dieselbe Governance und denselben Plattformbetrieb.

Steht eure Datenplattform vor einer ähnlichen Skalierungsfrage?

Wenn Daten aus mehreren Systemen 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