Microsoft Fabric und Lumel: von Daten zu Planung in einem Stack

Definition

Microsoft Fabric ist eine integrierte Microsoft-Plattform für Datenintegration, Analytics und Data Engineering mit OneLake als einheitlicher Datenbasis. Lumel ist ein ISV im Fabric-Ökosystem für Enterprise Performance Management (EPM) und Planung; es ersetzt keine Datenplattform, sondern ergänzt sie um Planungs- und Write-back-Funktionen.

Einleitung

Wenn Reporting heute in Excel konsolidiert wird und Planung in separaten Dateien lebt, entstehen Fehler, Wartezeiten und Diskussionen über „die richtige Zahl“. Microsoft Fabric und Lumel zielen genau auf diese Lücke: Fabric liefert die saubere, geteilte Datenbasis – Lumel bringt Planung, Forecasts und Szenarien direkt nah ans Reporting, sodass Plan vs. Actual nicht mehr aus zwei Welten kommt.

Was Microsoft Fabric im Alltag leistet

Fabric fasst typische Bausteine einer Datenplattform in einem Stack zusammen: Datenintegration, Speicherung, Aufbereitung und Analytics. Der praktische Nutzen ist weniger Tool-Vielfalt und mehr Wiederverwendung: Daten werden einmal sauber bereitgestellt und dann von mehreren Teams genutzt – ohne Kopieren, ohne Schatten-Excels.

OneLake ist dabei der gemeinsame Daten-Hub: Aus Anwender-Sicht heißt das, dass auch Nicht-IT-affine Nutzer auf definierte „Gold-Daten“ zugreifen können, um in Power BI oder Excel schnell Auswertungen zu bauen, ohne ständig neue Datenextrakte anzufragen.

Kerneigenschaften: Datenintegration, Analytics, Real-Time

In Fabric werden Daten typischerweise über Pipelines integriert und anschließend in Lakehouse- oder Warehouse-Strukturen für SQL-Analysen und BI bereitgestellt. Für viele Organisationen ist das der Weg raus aus fragmentierten Quellsystemen und manueller Datenpflege, weil Aktualisierung, Transformation und Veröffentlichung als reproduzierbarer Prozess laufen.

• Datenintegration: Standardisierte Pipelines statt manuelle Exporte und Zwischenablagen
• Analytics: SQL, Notebooks und semantische Modelle als Grundlage für konsistente KPIs
• Fabric Real-Time Intelligence: Live-/Near-Real-Time-Signale für operative Steuerung (wenn wirklich nötig)

Lumel im Fabric-Ökosystem: Planung ohne Excel-Chaos

Lumel Enterprise Performance Management ergänzt Fabric um Planung, Budgetierung, Forecasting und Szenarien – ideal, wenn Controlling zwar Power BI nutzt, Planung aber noch in Excel-Silos läuft. Der Mehrwert entsteht, wenn Planung direkt auf denselben definierten Datenmodellen basiert wie das Reporting: weniger Abstimmungsschleifen, weniger Versionskonflikte, mehr Transparenz.

Wichtig: Planung ist kein reines Frontend-Thema. Sie wird nur dann verlässlich, wenn der Ist-Datenlayer (Stammdaten, Buchungslogik, Zeitbezüge, Währungen, Kostenstellen) stabil und nachvollziehbar ist. Genau dafür ist Fabric die Basis.

Planning in Fabric IQ: von historischen Daten zu Forecasting

Fabric IQ adressiert den Schritt von reiner Rückschau zu Vorwärtssteuerung: historische Ist-Daten werden zur Grundlage für driver-basierte Planung und Forecasting. Praktisch heißt das: Teams planen nicht mehr „Pi mal Daumen“ in Tabellen, sondern rechnen Szenarien mit definierten Treibern (z. B. Absatz, Preis, Personalaufwand) und sehen die Auswirkungen sofort im gleichen Reporting-Kontext.

Der entscheidende Nutzen ist Geschwindigkeit bei gleichzeitig höherer Konsistenz: Planwerte können kontrolliert zurückgeschrieben werden (Write-back) und stehen unmittelbar für Plan-Ist-Vergleiche, Abweichungsanalysen und Management-Reporting zur Verfügung.

Integrationen: SAP, Power BI und Write-back-Matrizen

Viele Fabric-Projekte starten mit SAP, weil dort die steuerungsrelevanten Daten liegen. Je nach Systemlandschaft (SAP ERP, SAP S/4HANA, SAP BW / BW/4HANA) unterscheiden sich Extraktion, Latenz und Governance-Ansatz. Tools wie Xtract Universal werden häufig genutzt, um SAP-Daten reproduzierbar in moderne Plattformen zu bringen.

Auf der Konsumentenseite ist Power BI der Standard: Die gleichen semantischen Modelle können für Dashboards, Ad-hoc-Analysen und Planungsprozesse genutzt werden. Für spezielle Anforderungen im Finance-Kontext (z. B. Eingaben, Rückschreiben, strukturierte GuV-Layouts) kommen Erweiterungen wie Inforiver Write-Back Matrix ins Spiel, wenn native Möglichkeiten nicht reichen oder zu viel DAX-Workaround erzeugen.

Architektur: typische Komponenten und Onboarding-Strategie

Eine robuste Zielarchitektur ist meist „einfach, aber konsequent“: wenige Datenprodukte, klarer Gold-Layer, klar definierte KPI-Logik. So entsteht ein Fundament, auf dem Planning und Self-Service nicht entgleisen.

• Landing Zone: Quellnaher Import (Bronze) mit klarer Lineage
• Harmonisierung: Bereinigung und Business-Logik (Silver/Gold) für wiederverwendbare Kennzahlen
• Bereitstellung: Warehouse/semantische Modelle für Power BI und Planning-Workloads

Onboarding funktioniert am besten use-case-basiert: erst 1–2 Management-Fragen sauber lösen (z. B. Cashflow-Transparenz, Ergebnis-Drilldown), dann Skalierung auf weitere Bereiche. Dadurch werden Aufwand, Akzeptanz und ROI schneller sichtbar.

Sicherheit, Governance & Compliance in Fabric-Umgebungen

Fabric-Setups scheitern selten an Technik, sondern an fehlender Governance: Wer darf was sehen? Welche KPI-Definition gilt? Welche Daten dürfen geplant und zurückgeschrieben werden? Hier braucht es klare Rollen (Data Owner, Steward, Entwickler, Konsument) und Standards für Arbeitsbereiche, Namenskonventionen, Freigaben und Deployment.

Für Compliance sind vor allem zwei Punkte entscheidend: saubere Berechtigungen (bis hin zu Row-Level-Security im Reporting) und nachvollziehbare Datenherkunft. Microsoft Purview kann dabei helfen, Lineage und Datenkatalogisierung konsistent aufzubauen, statt Wissen in Köpfen zu parken.

Use Case (Mini-Story): Liquiditäts- und Forecasting-Loop

Ein Finance-Team konsolidiert wöchentlich Zahlungsströme aus SAP und Nebenquellen in Excel, baut daraus einen Liquiditätsbericht und leitet manuell einen Forecast ab. Mit Fabric werden Quellen über Pipelines integriert, der Gold-Layer liefert definierte Cash-KPIs in Power BI, und Lumel ergänzt die Planung: Treiber anpassen, Szenario speichern, Planwerte zurückschreiben. Ergebnis: weniger Copy-Paste, ein konsistenter Plan-Ist-Vergleich und schnellere Steuerungsentscheidungen.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn die Plattform schnell verlässlich stehen muss und interne Kapazitäten für Architektur, Integration und Betrieb fehlen. Typische Auslöser sind SAP-Anbindung, Governance-Design (Arbeitsbereiche, Rollen, Dev/Test/Prod) und die Frage, wie Planning/Write-back sauber abgesichert wird, ohne Self-Service zu blockieren.

Auch sinnvoll: wenn die Organisation vom „Reporting bauen“ zum „Datenprodukt betreiben“ kommen muss – inklusive Monitoring, Refresh-Stabilität, Performance und klarer Verantwortlichkeiten.

Fazit

Microsoft Fabric schafft eine gemeinsame Daten- und Analytics-Basis, die den Wildwuchs aus Extrakten und Excel reduziert. Lumel ergänzt das Fabric-Ökosystem um Planung und Forecasting, sodass Controlling nicht mehr zwischen Ist-Welt und Plan-Welt vermittelt, sondern auf einem konsistenten Datenfundament arbeitet. Wer den Einstieg pragmatisch über wenige, messbare Use Cases wählt und Governance von Anfang an mitdenkt, bekommt schneller verlässliche Reportings und eine echte Planungsfähigkeit statt Tabellenpflege.

Häufig gestellte Fragen (FAQ) & Support-Optionen

Ist Microsoft Fabric nur „Power BI plus“?

Nein. Power BI ist das Reporting-Frontend; Fabric ergänzt Datenintegration, Speicherung, Engineering und Governance, damit Power BI auf stabilen, wiederverwendbaren Datenmodellen läuft.

Braucht man Lumel zwingend für Planung?

Nein, aber es ist relevant, wenn Planung, Budgetierung und Write-back strukturiert, rollenbasiert und direkt am Fabric-/Power-BI-Ökosystem erfolgen sollen, statt in Excel-Dateien zu zerfallen.

Wie lässt sich ROI messen, ohne Preise zu diskutieren?

Über messbare Prozesskennzahlen: Stunden für Konsolidierung, Anzahl manueller Korrekturen, Time-to-Insight im Monatsabschluss, Stabilität der Refreshes, sowie Planungszyklen (Dauer und Iterationen).

Welche Support-Optionen sind üblich?

Typisch sind ein klarer Betriebsprozess (Monitoring, Incident, Change), regelmäßige Review-Termine für Performance und Kostenkontrolle der Kapazität sowie Enablement der Key User, damit nicht jede Anpassung extern bleibt.