.png){kind=small}
Planung mit Microsoft Fabric
Aktualisiert: 2. Sept.
Wer mit Power BI oder Microsoft Fabric arbeitet, kennt das Muster: Das Reporting steht, die Kennzahlen sind abgestimmt, die Ist-Daten liegen auf der Plattform – und sobald es um Budget, Forecast oder Szenarien geht, macht irgendwo wieder eine Excel-Datei auf. Planung läuft damit oft genau neben der Datenplattform, auf der später wieder über ihre Ergebnisse berichtet wird.
Genau deshalb ist Planung mit Microsoft Fabric so interessant. Microsoft bringt mit Plan in Fabric IQ Budgetierung, Forecasting, Szenarioplanung, Dateneingabe und Reporting näher an die bestehende Fabric-Architektur.
Der entscheidende Unterschied gegenüber dem Stand vom Frühjahr 2026: Plan in Fabric IQ ist inzwischen Generally Available. Damit verändert sich auch die Einordnung. Unternehmen müssen Planning in Fabric nicht mehr grundsätzlich als Preview-Technologie behandeln. Gleichzeitig wäre es falsch, aus GA abzuleiten, dass jeder komplexe Planungsprozess bereits uneingeschränkt auf Fabric verlagert werden sollte.
Die entscheidende Frage lautet heute nicht mehr, ob das Produkt reif genug ist, um es überhaupt zu testen. Sie lautet: Für welche Planungsprozesse passt die aktuelle Architektur – und wo setzen die konkreten Produktgrenzen an?
Das Problem ist nicht Planung. Es ist der Bruch dazwischen.
Meist ist nicht die Planung selbst das größte Problem, sondern der Übergang zwischen Welten:
Historische Ist-Daten in BI oder im DWH
Budget- und Forecast-Logik in Excel oder separaten CPM-Tools
Kommentierung, Freigabe und Anpassung irgendwo dazwischen
Plan/Ist-Vergleiche wieder zurück im Reporting
Das Ergebnis ist bekannt: doppelte Logik, manuelle Abstimmung, unterschiedliche Zahlenstände und endlose Diskussionen darüber, welche Datei jetzt die aktuelle ist. Das klingt banal, kostet in der Praxis aber viel Energie. Vor allem in Finance-nahen Prozessen, bei Vertriebsplanung, Opex-Planung, Headcount-Szenarien oder bereichsübergreifenden Forecasts.
Genau hier setzt Fabric Planning an. Der interessante Gedanke dahinter ist nicht einfach Writeback in Power BI, sondern ein gemeinsamer semantischer Unterbau für Ist, Plan und Forecast. Das ist der entscheidende Punkt. Denn wenn Planung direkt auf demselben semantischen Modell aufsetzt wie das Reporting, sinkt die Zahl der Übersetzungsfehler drastisch.
Und genau deshalb ist das Thema auch kein reines Finance-Thema. Es ist ein Datenstrategie-Thema. Wer Planung sauber in die Plattform holt, entscheidet nicht nur über Eingabemasken, sondern über Kennzahlenlogik, Governance, Rollen, Freigaben und den Umgang mit Versionen.
Was Microsoft in Fabric heute tatsächlich anbietet
Microsoft beschreibt Plan als integrierte EPM- und CPM-Lösung innerhalb von Fabric. Im Kern stehen heute Planning Sheets, PowerTable Sheets, Intelligence Sheets und Infobridge. Cubes, Allokationen, Forecasting und Writeback ergänzen diese Bausteine als zentrale Planungsfähigkeiten.
1. Planning Sheets
Hier entstehen Budgets, Forecasts, Szenarien und Planwerte. Also das, was viele mit Planung zuerst meinen. Die Sheets sind auf Business-Nutzung ausgelegt, eher no-code orientiert und verbinden Eingabe, Versionierung, Allokation und Auswertung in einer Oberfläche.
Wichtig ist dabei: Es geht nicht nur um Jahresbudget. Microsoft adressiert auch Rolling Forecasts, Versionen, Snapshots, What-if-Szenarien und Freigaben. Das ist gut, weil echte Planung selten ein einmaliger Jahresritus ist. Gute Planung ist ein laufender Prozess.
2. Cubes und mehrdimensionale Allokation
In der Praxis werden Pläne oft auf einer Ebene erfasst und auf anderen Ebenen benötigt. Ein Umsatzbudget wird zum Beispiel auf Region oder Produkt verteilt. Oder ein Headcount-Ziel soll auf Funktionen, Teams oder Monate heruntergebrochen werden.
Genau dafür bringt Fabric Cubes und driver-basierte Allokation mit. Das klingt technisch, ist aber im Alltag extrem wertvoll. Denn damit lässt sich ein aggregierter Planwert auf tieferliegende Ebenen verteilen – idealerweise nicht nach Bauchgefühl, sondern anhand sinnvoller Treiber wie Vorjahresumsatz, Mengen, Kostenstrukturen oder vorhandener Kapazitäten.
Der große Vorteil: Wenn dieselbe Logik, die dein Reporting steuert, auch die Verteilung deiner Planwerte steuert, reduziert das Nebenrechnungen und Schattenlogik.
3. Forecasting direkt auf dem semantischen Modell
Auch das ist ein wichtiger Punkt. Forecasts in Fabric bauen nicht einfach auf losgelösten Tabellen auf, sondern auf dem vorhandenen Modell. Historische Werte, Durchschnitte, Formeln oder manuelle Eingaben können als Startpunkt dienen. Danach lässt sich der Forecast fortschreiben, anpassen und mit neuen Ist-Werten aktualisieren.
Das ist genau die Richtung, die in vielen Unternehmen fehlt. Dort wird oft viel Energie in das Erstellen des Budgets gesteckt, aber deutlich zu wenig in die laufende Navigation. Ein gutes Forecast-Setup ist meist wertvoller als Diskussionen über den finalen Planstand vom Vorjahr.
4. Writeback
Einer der wichtigsten Punkte überhaupt. Planung ist erst dann fachlich belastbar, wenn die Eingaben nicht nur in einem Frontend sichtbar sind, sondern kontrolliert in die Datenplattform zurückgeschrieben werden können.
Fabric unterstützt genau dieses Writeback. Budgetwerte, Forecasts, Anpassungen und Szenario-Daten lassen sich in geeignete Ziele zurückschreiben. Damit wird aus einer Planungssicht ein persistenter Datenbestand. Das klingt technisch, ist aber strategisch. Denn nur dann werden Planung und Analytics wirklich Teil derselben Datenlandschaft.
5. InfoBridge
InfoBridge ist einer dieser Bausteine, die auf den ersten Blick unspektakulär wirken und in der Praxis extrem relevant sind. Viele Planungs- und Reporting-Szenarien bestehen aus mehreren Seiten, Perspektiven oder Granularitäten. Genau dort entsteht sonst schnell Wildwuchs: mehrere Tabellen, mehrere Rückschreibelogiken, mehrere Sonderfälle.
InfoBridge hilft dabei, Daten aus mehreren Visuals oder Planungskontexten in einer gemeinsamen Writeback-Struktur zusammenzuführen. Das ist weniger ein Detail-Feature als ein Signal: Microsoft denkt Planung nicht nur als Eingabe, sondern als integrierten Datenfluss.
6. PowerTable und Intelligence Sheets
Mit PowerTable und Intelligence Sheets wird klar, dass Microsoft das Thema breiter denkt als klassische Budgeterfassung.
PowerTable ist im Kern eine governte, Excel-nahe Tabellenanwendung direkt auf Datenbank- und Semantic-Model-Basis. Das ist spannend für Referenzdaten, Treiberdaten, operative Eingaben, Projektlisten, Freigabefelder oder andere strukturierte Business-Daten, die heute oft in halboffiziellen Dateien leben.
Intelligence Sheets schließen die Lücke in Richtung Reporting und Kommunikation. Also genau dort, wo Plan/Ist/Forecast, Kommentare, Management-Sichten und sauber formatierte Berichte zusammenkommen. Für Finance- und Controlling-nahe Anwendungsfälle ist das hochrelevant.
Warum GA die Bewertung deutlich verändert
Im Frühjahr 2026 war ein wesentlicher Vorbehalt noch der Preview-Status. Dieser Punkt ist heute überholt. Plan in Fabric IQ ist seit Juli 2026 Generally Available und weltweit verfügbar. Damit wird Plan für Unternehmen deutlich relevanter für produktive Evaluierungen.
weniger manuelle Abstimmung zwischen Fachbereich, BI und Finance
weniger doppelte Kennzahlenlogik
weniger Schattenlösungen in Excel
bessere Nachvollziehbarkeit von Änderungen
höhere Chance auf konsistente Plan/Ist/Forecast-Vergleiche
mehr Governance ohne sofortigen Tool-Zoo
GA bedeutet aber nicht, dass plötzlich alles leicht oder jede Planungsarchitektur automatisch passend ist. Der Unterschied liegt darin, dass Risiken heute über konkrete Produktgrenzen bewertet werden können – nicht mehr über ein generisches Preview-Label.
Gerade Unternehmen, die Fabric ohnehin strategisch einsetzen, sollten das Thema deshalb ernst nehmen. Die Plattform kann inzwischen den Schritt von Analyse zu Planung produktiv mitgehen – sofern Architektur, Security und Prozess zum aktuellen Funktionsumfang passen.
Wo Planung mit Microsoft Fabric heute schon gut passt
Planung mit Microsoft Fabric sollte aktuell vor allem dort geprüft werden, wo drei Dinge zusammenkommen:
Fabric ist bereits gesetzt.
Wer Lakehouse, Warehouse, semantische Modelle und Power BI schon aktiv nutzt, hat den größten Hebel. Dann ist Planung keine Insellösung, sondern eine Erweiterung des vorhandenen Kerns.
Es gibt einen klaren Planungsprozess mit überschaubarer Komplexität.
Zum Beispiel Vertriebsforecast, regionale Budgetplanung, Opex-Planung, Headcount-Treiber oder Kapazitätsplanung.
Die Organisation leidet sichtbar unter Brüchen zwischen Ist, Plan und Forecast.
Also genau dort, wo heute mehrere Dateien, manuelle Übergaben oder widersprüchliche Zahlenstände den Alltag dominieren.
Besonders plausibel könnten aktuell Use Cases sein wie:
Vertriebsforecast mit monatlicher Aktualisierung
Kostenstellen- und Opex-Planung
Headcount- und Kapazitätsplanung
Regionale Planung mit zentraler Konsolidierung
Plan/Ist/Forecast-Reporting für Finance oder Management
Gerade in solchen klar umrissenen Szenarien zeigt sich am besten, ob Fabric Planning im eigenen Unternehmen wirklich Mehrwert stiftet – fachlich, organisatorisch und technisch.
GA heißt nicht grenzenlos
Die frühere Aussage „Vorsicht, weil Preview“ ist heute nicht mehr richtig. Vorsicht ist weiterhin sinnvoll – aber aus konkreten, dokumentierten Gründen.
B2B-Nutzer werden nicht unterstützt
Microsoft-Entra-B2B-Identitäten können Plan derzeit nicht verwenden. Das ist insbesondere für gruppenübergreifende oder externe Kollaborationsmodelle relevant.
Private Links schließen Plan aktuell aus
Workspaces oder Tenants, die Private Links verwenden, unterstützen derzeit keine Plan Items. Für Organisationen mit besonders restriktiven Netzwerkarchitekturen kann das ein echtes Ausschlusskriterium sein.
Capacity und XMLA müssen passen
Nicht jedes Power-BI-Lizenzmodell reicht für Planning-Szenarien aus. Power BI Pro und Premium Per User sind für Szenarien, die XMLA-Endpunkte und Embed Tokens benötigen, nicht ausreichend. Tenant- und Capacity-Einstellungen müssen passend konfiguriert sein.
Semantic Models brauchen passende Rechte
Für verbundene semantische Modelle werden passende Admin- oder Build-Rechte benötigt. Direct-Lake-Modelle erfordern zusätzliche Konfiguration; Modelle aus My Workspace werden nicht unterstützt. Auch Renames von verbundenen semantischen Modellen oder Workspaces sollten nicht unbedacht erfolgen, weil Verbindungen beziehungsweise Plan Items dadurch unbrauchbar werden können.
PowerTable hat eine wichtige RLS-Grenze
PowerTable unterstützt bei Fabric-SQL-Tabellen derzeit keine benutzerspezifische Datenbank-RLS über die Identität des angemeldeten PowerTable-Nutzers. Abfragen laufen über die für die Datenbankverbindung konfigurierte Identität. Das Security-Modell muss deshalb vor produktiver Nutzung ausdrücklich geprüft werden.
CI/CD besitzt weiterhin Grenzen
Deployment-Prozesse sind noch nicht in jedem Szenario vollständig transparent. Bei CI/CD-Deployments mit Service Principal wird beispielsweise die automatische Erstellung der Application Database nicht unterstützt. Das gehört in eine professionelle Dev/Test/Prod-Strategie.
Konkrete Größenlimits kennen
Microsoft dokumentiert aktuell unter anderem folgende Grenzen:
maximal 1 Million Zeilen bei Bulk-Import aus Excel oder CSV
maximal 25 Sheets pro Plan Item
maximal 50 Visuals pro Plan Item
maximal 1,2 Millionen Zellen pro Infobridge-Abfrage
maximal 1,2 Millionen Zellen pro Writeback-Operation
Das sind für viele Use Cases großzügige Grenzen. Sie zeigen aber, dass GA nicht automatisch beliebige Skalierung für jeden Prozess bedeutet. Bei größeren Planungen sollte früh mit realistischen Datenvolumen getestet werden.
Nicht mit dem kompliziertesten Prozess starten
Auch nach GA bleibt die Empfehlung bestehen, nicht mit dem schwierigsten Planning-Prozess des Unternehmens zu beginnen. Ein sinnvoller erster Use Case besitzt klar definierte Kennzahlen, überschaubare Nutzergruppen, begrenzte Datenmengen, verständliche Allokationslogik, wenige Freigabestufen und einen klaren fachlichen Owner.
Der richtige Einstieg ist kein Demo-Use-Case, aber auch nicht der riskanteste Kernprozess.
Was vor dem Start sauber stehen sollte
Bevor man Planning in Fabric einführt, sollten ein paar Grundlagen geklärt sein. Sonst baut man nur eine neue Oberfläche auf alte Unordnung.
Sauberes semantisches Modell
Wenn du dasselbe Modell für Reporting und Planung nutzen willst, muss dieses Modell tragfähig sein. Genau deshalb passt an dieser Stelle intern sehr gut der Beitrag zur Datenmodellierung in Power BI. Ein wackliges Modell wird durch Planning nicht besser. Es wird nur sichtbarer.
Klare Kennzahlenlogik
Treiber, Measures, Planvarianten und Allokationsregeln müssen sauber definiert sein. Wer hier schwimmt, produziert schnell schöne Oberflächen mit unsauberer Logik. Dazu passt auch Measures vs. Calculated Columns, weil genau diese Logik später nicht nur Reports, sondern auch Verteilungen und Szenarien beeinflusst.
Governance statt Freestyle
Planung ist kein Bereich, in dem jeder macht mal schnell dauerhaft funktioniert. Freigaben, Verantwortlichkeiten, Versionen, Rollen und Veröffentlichungslogik gehören von Anfang an dazu. An der Stelle ist Power BI Governance im Self Service eine sehr passende Ergänzung – nicht als Bürokratie, sondern als Schutz vor dem nächsten Schattenprozess.
Reporting nicht als Nachgedanke behandeln
Planung endet nicht bei der Eingabe. Sie muss erklärt, kommentiert, verglichen und präsentiert werden. Deshalb ist die Brücke zu IBCS in Power BI umsetzen fachlich absolut sinnvoll. Gerade in Plan/Ist/Forecast-Sichten ist Konsistenz wichtiger als Design-Spielerei.
Einordnung von Planung in Fabric: GA, aber nicht magisch
Planung in Microsoft Fabric ist inzwischen mehr als eine interessante Preview-Idee. Mit der GA-Verfügbarkeit ist ein plausibler Weg entstanden, Planung näher an Daten, Governance und Reporting zu holen.
Die Chance ist groß: weniger Toolbrüche, mehr gemeinsame Logik, bessere Nachvollziehbarkeit und eine engere Verbindung von Fachbereich, Finance und BI.
Der Erfolg kommt trotzdem nicht aus dem Produktnamen. Semantisches Fundament, klarer Use Case, Security und disziplinierte Governance bleiben entscheidend.
Fabric Plan ist besonders stark, wenn Integration in die bestehende Fabric-Plattform einen hohen Wert besitzt. Spezialisierte CPM-Lösungen bleiben dagegen sinnvoll, wenn Konsolidierung, Workflow, regulatorische Anforderungen oder sehr individuelle Planungslogik den Prozess dominieren.
Fazit: Planung mit Fabric ist vom Experiment zur echten Option geworden
Planung mit Microsoft Fabric hat in wenigen Monaten einen wichtigen Reifegradschritt gemacht. Plan in Fabric IQ ist nicht mehr Preview, sondern Generally Available.
Damit wird aus einer interessanten Zukunftsidee eine ernsthafte Option für produktive Planning-Szenarien. Der strategische Vorteil bleibt derselbe: Planung, Ist-Daten, Forecast und Reporting können näher auf einer gemeinsamen Daten- und Semantikbasis zusammenwachsen.
Gleichzeitig bleiben konkrete Grenzen bei Security, Netzwerkarchitektur, Capacity, CI/CD und Skalierung. Plan sollte deshalb weder als unreife Preview abgetan noch als universeller Ersatz für jedes bestehende Planning-System verstanden werden.
Für Unternehmen, die Microsoft Fabric bereits strategisch nutzen, ist jetzt aber ein deutlich besserer Zeitpunkt gekommen, reale Use Cases zu evaluieren. Die Frage lautet: Welcher Planungsprozess gehört als erster sinnvoll auf die gemeinsame Fabric-Plattform?
Der nächste sinnvolle Schritt
Wenn ihr heute Budget, Forecast und Reporting über mehrere Werkzeuge verteilt, lohnt sich eine strukturierte Prüfung des Zielbilds.
Im Microsoft Fabric Kick-Start können wir einen konkreten Planning-Use-Case gemeinsam bewerten: bestehende Daten- und Semantic-Model-Basis, Planungsprozess, Writeback, Security, Governance und die aktuellen Produktgrenzen.
Für umfangreichere Architektur- und Umsetzungsthemen lässt sich das anschließend in der Microsoft Fabric Beratung weiterführen.
Ziel sollte nicht sein, Excel um jeden Preis abzuschaffen. Ziel ist eine Planning-Architektur, in der Ist, Plan und Forecast dieselbe vertrauenswürdige Daten- und Kennzahlenlogik verwenden.
