Cognos Analytics hat in den letzten Jahren viel “Gegenwind” von Power BI bekommen, jetzt geht sieht es bei Planning Analytics genau so aus. Wo stehen wir heute? Hierzu ein paar Gedanken: Microsoft hat Fabric um eine Funktion erweitert, die den Markt für Unternehmensplanung interessant verändern könnte: Microsoft Fabric Plan.
Plan ist nicht einfach eine weitere Power-BI-Funktion. Microsoft positioniert Planning in Fabric ausdrücklich als Enterprise and Corporate Performance Management (EPM & CPM) für Budgetierung, Forecasting und Szenarioplanung. Planning Sheets, PowerTable Sheets, Intelligence Sheets und Infobridge machen deutlich, wohin die Reise geht: Microsoft möchte Unternehmensplanung zu einem nativen Bestandteil von Fabric machen. Quelle: Microsoft – What is Planning in Microsoft Fabric?
Für IBM-Kunden stellt sich damit zwangsläufig die Frage: Ist Fabric Plan eine Alternative zu IBM Planning Analytics?
Die kurze Antwort lautet: Microsoft betritt damit eindeutig das Terrain von Planning Analytics. Ein Vergleich nur mit Planning Analytics Workspace (PAW) greift aber zu kurz.
Denn Microsoft argumentiert nicht nur mit Plan, sondern mit der gesamten Fabric-Plattform einschließlich Semantic Models, Power BI, Datenplattform und AI. Fairerweise muss man deshalb auf IBM-Seite ebenfalls das gesamte Zusammenspiel betrachten:
IBM Planning Analytics / TM1 + Planning Analytics Workspace + PAfE + Cognos Analytics.
Was ist Microsoft Fabric Planning?
Microsoft unterscheidet mehrere zentrale Komponenten: Planning Sheets für Budgetierung, Forecasting und Szenariomodellierung, PowerTable Sheets für strukturierte Planung und Datenanwendungen, Intelligence Sheets für Reporting und Analyse sowie Infobridge für Datenintegration und Synchronisation.
Planning Sheets besitzen eine Excel-artige Benutzeroberfläche. Microsoft nennt unter anderem What-if-Analysen, Forecasts, Writeback und die Integration mit Fabric Semantic Models als Bestandteile des Konzepts. Planungsergebnisse können wiederum in Fabric-Datenstrukturen zurückgeschrieben und für Analytics verwendet werden. Quelle: Microsoft – Planning in Fabric Overview
Damit ist der Anspruch klar: Microsoft will nicht nur historische Daten analysieren, sondern den Kreislauf aus Actual ? Analyse ? Planung ? Forecast ? Szenario ? Reporting stärker innerhalb von Fabric abbilden.
Microsoft hat jetzt multidimensionale Planung – aber ist das ein TM1-Cube?
Einer der interessantesten Punkte ist Microsofts neuer Cube-Ansatz. Dabei handelt es sich ausdrücklich nicht nur um tabellarische Parent-Child-Hierarchien.
Microsoft beschreibt den Cube als eine Struktur, die Planungsdaten multidimensional organisiert. Sie unterstützt mehrere Dimensionen, Hierarchieebenen und Aggregationen. Microsoft verwendet in seiner Dokumentation ausdrücklich den Begriff „multidimensional cube planning“. Quelle: Microsoft – Allocate Plans with a Cube
Damit können Planungen mit unterschiedlichen Granularitäten miteinander verbunden werden.
Ein Finance-Bereich könnte beispielsweise auf GL Account × Region × Time planen, während Sales mit Product × City × Channel × Time arbeitet. Microsoft beschreibt genau dieses Szenario: Der Cube kann Werte über zusätzliche Dimensionen verteilen und anschließend wieder auf die übergeordnete Planungsebene aggregieren.
Als Allocation Driver können dabei DAX-Measures aus dem Semantic Model verwendet werden, beispielsweise Vorjahresumsatz, aktueller Umsatz, verkaufte Einheiten, Headcount oder Produktionsvolumen. Quelle: Microsoft – Multidimensional Cube Planning
Das ist multidimensionale Planung und erheblich mehr als „Power BI plus Eingabefelder“.
Trotzdem ist ein Fabric Cube nicht automatisch ein TM1-Cube
Hier sollte man mit dem Begriff „Cube“ vorsichtig umgehen. Microsofts Cube Measures lösen insbesondere das Problem, einen Planungswert über zusätzliche Dimensionen aufzubrechen und diesen Zusammenhang zwischen unterschiedlichen Planungsebenen zu erhalten.
Bei IBM Planning Analytics ist der Cube dagegen das fundamentale Datenmodell der TM1-Engine. Auf dieser multidimensionalen Engine basieren Berechnungs-, Konsolidierungs- und Planning-Logik sowie Funktionen wie Rules, Feeders, Spreading, Sandboxes und Security.
Deshalb wäre es verfrüht, aus dem gemeinsamen Begriff „Cube“ eine technische Gleichwertigkeit abzuleiten.
Die interessante Frage lautet nicht mehr: „Hat Microsoft Cubes?“
Die Antwort darauf lautet inzwischen: Fabric Planning unterstützt multidimensionale Planning Cubes.
Die wesentlich interessantere Frage lautet: Wie weit reicht dieses Cube-Konzept bei komplexen Unternehmensmodellen im Vergleich zur multidimensionalen TM1-Engine?
Das muss sich bei komplexen Berechnungsmodellen, Allokationen, Konsolidierungen, großen Dimensionen, Security, Parallelität und Performance zeigen.
Planning Engine: Hier besitzt IBM viel Erfahrung
IBM Planning Analytics basiert auf TM1. Diese Engine wurde speziell für multidimensionale Unternehmensplanung entwickelt und über Jahrzehnte erweitert.
Typische TM1-Anwendungen gehen weit über eine einfache Umsatzplanung hinaus. Dazu gehören Finanz- und P&L-Planung, Personalplanung, Kostenstellenplanung, Investitionsplanung, Treiberrechnungen, Währungsumrechnungen, komplexe Allokationen, Bottom-up- und Top-down-Planung, Rules und Feeders, Sandboxes sowie umfangreiche TurboIntegrator-Prozesse. Quelle: IBM – Planning Analytics
Genau deshalb sollte Fabric Planning nicht nur danach bewertet werden, ob sich ein Budgetwert eingeben und verteilen lässt. Interessant wird der Vergleich bei realen Unternehmensmodellen mit komplexen Regeln, vielen Dimensionen und zahlreichen gleichzeitig arbeitenden Planern.
Ein großer Microsoft-Vorteil: „Extend, Don’t Rebuild“
Einer der interessantesten Punkte in der Microsoft-Dokumentation ist das Measure Model.
Microsoft formuliert hier ein bemerkenswert klares Architekturprinzip: „Extend, Don’t Rebuild“.
Ein Unternehmen, das bereits erhebliche Arbeit in sein zentrales Fabric-/Power-BI-Semantic-Model investiert hat, soll diese Arbeit für die Planung nicht erneut durchführen müssen. Vorhandene zentrale DAX-Measures können übernommen und um Planning Measures erweitert werden. Quelle: Microsoft – Measure Model for Planning
Microsoft nennt beispielsweise ein zentral definiertes Measure für Revenue Actual. Innerhalb der Planung kann darauf ein Revenue Forecast aufbauen.
Actual und Forecast werden damit nicht vollständig unabhängig voneinander modelliert, sondern können auf derselben vorhandenen Business-Semantik aufsetzen.
Genau hier hat IBM eine unnötige Lücke
IBM besitzt eigentlich alle technischen Bausteine, um eine ähnlich überzeugende Geschichte zu erzählen.
In Cognos Analytics kann ein Data Module als zentrale semantische Schicht dienen. Dort befinden sich Datenquellen, Joins und Beziehungen, berechnete Kennzahlen, Hierarchien, fachliche Bezeichnungen, Filter, Business-Logik und je nach Modellierung auch relevante Berechtigungslogik.
Planning Analytics besitzt mit TM1 wiederum eine ausgesprochen leistungsfähige Planning Engine.
Das Problem ist die Richtung der Integration.
TM1 ? Cognos funktioniert
Cognos Analytics kann auf Planning-Analytics-/TM1-Cubes zugreifen.
Seit Cognos Analytics 12.0.3 können unterstützte OLAP-Cubes außerdem als Grundlage eines Data Modules verwendet werden. IBM nennt dabei Planning Analytics als unterstützte OLAP-Quelle. Quelle: IBM – Creating data modules from OLAP cubes
Damit funktioniert grundsätzlich die Richtung:
TM1 ? Cognos Data Module ? Cognos Analytics.
Die wichtigere Richtung fehlt: Cognos Data Module ? Planning Analytics
Für eine wirklich gemeinsame Plattform wäre jedoch die umgekehrte Richtung mindestens genauso interessant:
Cognos Data Module ? TM1 / Planning Analytics.
Für diesen Weg gibt es derzeit keinen vergleichbaren dokumentierten nativen Mechanismus, mit dem ein bestehendes Cognos Data Module direkt zur semantischen Grundlage eines neuen TM1-Planungsmodells wird.
Das ist aus meiner Sicht eine der größten unnötigen Integrationslücken zwischen Cognos Analytics und Planning Analytics.
Angenommen, ein Unternehmen hat in Cognos bereits ein Data Module aufgebaut:
SAP + DWH + CRM + externe Daten ? Cognos Data Module
Darin befinden sich bereits Business-Logik, Beziehungen, Kennzahlen, Hierarchien und Berechtigungen. Nun soll auf genau diesen Unternehmensdaten geplant werden.
Warum sollte diese fachliche Logik in Planning Analytics erneut aufgebaut werden?
In der Praxis entsteht sonst schnell:
DWH ? Cognos Data Module ? Cognos Analytics
und parallel:
DWH ? Datenintegration / TurboIntegrator ? TM1 ? PAW
Damit entstehen zwei semantische Welten, die gepflegt und synchron gehalten werden müssen.
Wie eine echte IBM Analytics-&-Planning-Plattform aussehen könnte
Eigentlich müsste die Architektur stärker in diese Richtung gehen:
Datenquellen / DWH / Dateien / APIs
?
Cognos Data Module – gemeinsame semantische Schicht
?
Cognos Reporting | Cognos Dashboards | Planning | AI
?
TM1 – multidimensionale Planning- und Calculation-Engine
TM1 müsste dafür keineswegs ersetzt werden. Im Gegenteil: Gerade die TM1-Engine wäre ein wesentlicher Vorteil.
Das Cognos Data Module würde Business-Semantik und Datenzugriff liefern. TM1 würde das ergänzen, was eine spezialisierte Planning Engine benötigt: Writeback, Spreading, Rules, Feeders, Sandboxes, Szenarien, Allokationen und multidimensionale Berechnung.
Eine Funktion wie „Create Planning Model from Data Module“ wäre deshalb ein logischer nächster Schritt.
Dimensionen, Hierarchien, Measures und möglichst auch Security könnten aus einem bestehenden Data Module übernommen werden. Anschließend müsste definiert werden, welche Measures planbar sind, welche Versionen – etwa Actual, Budget und Forecast – benötigt werden und welche zusätzlichen TM1-Regeln gelten.
Security macht diesen Punkt besonders wichtig
Business-Logik doppelt zu pflegen ist lästig. Security doppelt zu pflegen ist problematischer.
Wenn bereits definiert wurde, dass ein Regionalleiter nur seine Region und ein Kostenstellenverantwortlicher nur seine Kostenstellen sehen darf, sollte diese fachliche Zugriffslogik für die Planung möglichst nicht vollständig neu implementiert werden müssen.
Genau hier ist Microsofts Wiederverwendung vorhandener Semantic Models konzeptionell attraktiv.
Allerdings sollte man Microsoft an dieser Stelle ebenfalls nicht mehr zuschreiben, als heute tatsächlich funktioniert.
Fabric Planning hat bei Security noch Einschränkungen
Microsofts eigene Dokumentation führt derzeit eine Reihe bekannter Einschränkungen auf. Dazu gehören unter anderem Einschränkungen bei bestimmten Semantic-Model-Konstellationen und bei Row-Level Security in einzelnen Planning-Komponenten. Quelle: Microsoft – Known limitations in Planning
Das ist für die Bewertung wichtig: Microsoft besitzt konzeptionell eine attraktive gemeinsame semantische Basis. Daraus folgt aber noch nicht, dass sämtliche Security- und Governance-Regeln heute bereits lückenlos durch alle Planning-Komponenten durchgereicht werden.
Auch bei der Größe gibt es derzeit Grenzen
Fabric Planning ist noch jung und Microsoft dokumentiert konkrete technische Limits. Dazu gehören beispielsweise Begrenzungen für die Anzahl von Sheets und Visuals innerhalb eines Plan Items sowie Grenzen für bestimmte Abfragen und Writeback-Operationen. Die aktuellen Werte und Einschränkungen führt Microsoft auf einer eigenen Seite, die aufgrund der schnellen Weiterentwicklung vor einer konkreten Projektentscheidung geprüft werden sollte. Quelle: Microsoft – Planning limitations
Diese Grenzen bedeuten nicht automatisch, dass Fabric Planning für große Unternehmensplanung ungeeignet ist. Sie zeigen aber, dass man beim Vergleich mit langjährig gewachsenen TM1-Anwendungen vorsichtig sein sollte.
Workflow: Microsoft holt auf
Unternehmensplanung besteht nicht nur aus Zahlen. Planwerte müssen erfasst, eingereicht, geprüft, gegebenenfalls korrigiert und schließlich freigegeben werden.
Fabric Planning besitzt dafür Approval Workflows. Microsoft dokumentiert strukturierte Freigabeprozesse einschließlich mehrstufiger Genehmigungsszenarien. Quelle: Microsoft – Approval Workflows
IBM Planning Analytics Workspace besitzt ebenfalls umfangreiche Planungsprozesse mit Aufgaben, Verantwortlichkeiten, Status und Freigaben.
Hier sollte Fabric Planning deshalb nicht mehr als reine Eingabeergänzung zu Power BI betrachtet werden. Microsoft entwickelt das Produkt eindeutig in Richtung einer umfassenderen CPM-/EPM-Lösung.
Excel bleibt ein wichtiger Unterschied
Für viele Planning-Analytics-Kunden ist PAW nur ein Teil der Plattform. Ein zweiter wesentlicher Client ist Planning Analytics for Microsoft Excel – PAfE.
Damit ist tatsächlich Microsoft Excel die Benutzeroberfläche auf der TM1-Engine. Anwender können ihre Excel-Arbeitsweise mit zentral verwalteten TM1-Daten und Planning-Funktionen verbinden.
Fabric Planning setzt mit Planning Sheets dagegen auf eine Excel-artige Oberfläche innerhalb von Fabric. Quelle: Microsoft – Planning in Fabric
Gerade für Controller, die komplexe bestehende Excel-Arbeitsmappen mit einer Planning Engine verbinden, ist dieser Unterschied relevant.
Cognos Analytics gehört in den Vergleich
Ein Vergleich Fabric Planning vs. PAW wäre aus einem weiteren Grund zu kurz gegriffen.
Microsoft Planning befindet sich innerhalb einer Umgebung mit Power BI. Dann darf auf IBM-Seite Cognos Analytics nicht aus dem Vergleich entfernt werden.
Die IBM-Landschaft lautet vielmehr:
TM1 – Planning Engine
Planning Analytics Workspace – Web Planning, Analyse und Workflow
Planning Analytics for Excel – Excel Planning
Cognos Analytics – Dashboards, Analyse und Enterprise Reporting
Damit besitzt IBM durchaus eine Analytics-&-Planning-Landschaft. Sie wird allerdings stärker als Zusammenspiel eigenständiger Produkte wahrgenommen.
Microsoft verkauft die Plattform – IBM verkauft Produkte
Hier liegt ein wesentlicher Unterschied in der Wahrnehmung.
Microsoft sagt: Fabric. Darunter befinden sich Datenplattform, Semantic Models, Power BI, Planning und AI.
IBM sagt: Cognos Analytics und Planning Analytics.
Technisch bedeutet das nicht, dass IBM keine integrierte Lösung besitzt. Aber Microsofts Geschichte ist einfacher zu vermitteln:
Data + Semantic Model + BI + Planning + AI unter einem gemeinsamen Fabric-Dach.
IBM besitzt viele entsprechende Komponenten, aber die Produktgrenzen sind für Anwender und Administratoren deutlicher sichtbar. Die fehlende native Verbindung Cognos Data Module ? TM1 Planning Model zeigt, dass es sich dabei nicht nur um unterschiedliche Produktnamen handelt, sondern auch um eine technische Integrationslücke.
AI: Zwei unterschiedliche Strategien
Auch AI wird für Unternehmensplanung zunehmend relevant.
Microsoft beschreibt Fabric Planning als Grundlage für AI-assisted Decision Making. Intelligence Sheets und das größere Fabric-AI-Ökosystem sollen Analyse und Planung enger miteinander verbinden. Quelle: Microsoft – Planning in Fabric
IBM verfolgt mit Planning Analytics inzwischen einen stärker planungsspezifischen Ansatz. Planning Analytics verfügt über AI-Funktionen, die unmittelbar auf Planning-Daten und TM1-Modelle bezogen sind.
Dazu gehören unter anderem Explain Cell, Variance Analysis, Forecasting und der Planning Analytics Agent. IBM dokumentiert die laufende Erweiterung dieser AI-Funktionen in den aktuellen Planning-Analytics-Releases. Quelle: IBM – Planning Analytics Workspace New Feature Summary
Gerade Explain Cell zeigt den Unterschied zu einem allgemeinen Chat-Assistenten: Die AI kann bei der Erklärung eines Wertes auch dessen Entstehung innerhalb des Planning-Modells berücksichtigen.
Damit entstehen zwei unterschiedliche Strategien:
Microsoft: AI als Bestandteil einer umfassenden Daten-, BI- und Analytics-Plattform.
IBM: AI mit tiefer Integration in eine spezialisierte multidimensionale Planning Engine.
Die eigentlich interessante AI-Frage
Ein Benutzer sollte künftig nicht mehr wissen müssen, welches Produkt seine Frage beantwortet.
Warum liegt Deutschland im dritten Quartal acht Prozent unter Plan, und wie verändert sich das Jahresergebnis, wenn wir für Q4 drei Prozent mehr Absatz annehmen?
Der erste Teil ist klassische Analytics. Der zweite Teil ist Planning und Simulation.
Technisch könnten dafür unterschiedliche Engines zuständig sein. Für den Anwender sollte diese Grenze perspektivisch aber möglichst verschwinden.
Das ungewöhnliche Pay-per-Use-Modell von Microsoft
Eine der interessantesten Neuerungen von Fabric Planning ist das Abrechnungsmodell.
Microsoft verwendet ein active-session, capacity-based pricing model mit unterschiedlichen Rollen wie Planner, Stakeholder und Viewer. Quelle: Microsoft – Planning Billing and Pricing Model
Entscheidend ist das Session-Konzept. Eine Session beginnt, wenn ein Benutzer aktiv mit Planning interagiert, und bleibt anschließend für den von Microsoft definierten Abrechnungszeitraum aktiv.
Das bedeutet: „Pay per Use“ ist nicht mit „Pay per Minute“ gleichzusetzen.
Treffender lässt sich das Prinzip als Pay per active user per 30-day period beschreiben. Die jeweils aktuellen Verbrauchswerte und Rollen sollten direkt in der Microsoft-Dokumentation geprüft werden, da sich das Modell während der Preview noch ändern kann. Quelle: Microsoft – Billing
Gerade für gelegentliche Planer kann das attraktiv sein
Unternehmensplanung besitzt häufig eine sehr ungleiche Benutzerstruktur.
Beispielsweise arbeiten 15 zentrale Controller ständig im System. Dazu kommen vielleicht 500 Kostenstellenverantwortliche, die nur während Budget und Forecast Werte eingeben oder freigeben.
Ein nutzungsabhängiges Modell kann gerade für solche gelegentlichen Benutzer wirtschaftlich interessant sein.
Allerdings entstehen neben den Planning Sessions weitere Fabric-Verbräuche. Ein Kostenvergleich mit IBM Planning Analytics muss deshalb das Gesamtsystem und nicht nur die nominellen Planning-Verbrauchswerte betrachten.
Wichtig: Fabric Planning ist noch jung
Bei all diesen Funktionen darf die Produktreife nicht aus dem Blick geraten. Microsoft dokumentiert für Planning noch bekannte Einschränkungen und entwickelt Funktionen, Limits und Abrechnungsmodell kontinuierlich weiter. Quelle: Microsoft – Known Limitations
Breite Verfügbarkeit bedeutet deshalb nicht automatisch, dass jede Funktion bereits die Reife einer über Jahrzehnte entwickelten Planning-Plattform besitzt.
Fabric Planning ist trotzdem ernst zu nehmen
Die noch junge Produktphase sollte umgekehrt nicht dazu führen, Fabric Planning als Spielzeug abzutun.
Microsoft demonstriert bereits umfangreiche Planungsszenarien mit Umsatzplanung, Bottom-up Sales Planning, Rolling Forecasts, statistischem Forecasting, P&L-Strukturen und Szenarien. Quelle: Microsoft – Planning Tutorial
Das Produkt ist klar als Unternehmensplanung positioniert.
Ist „alles auf einer Plattform“ wirklich automatisch besser?
Microsofts stärkstes Argument lautet: Planning befindet sich direkt in Fabric.
Das ist ein realer Vorteil, wenn ein Unternehmen Fabric bereits als zentrale Daten- und Analytics-Plattform verwendet. Dann können vorhandene Semantic Models, DAX-Measures, Actuals und Business-Logik für Planning weiterverwendet werden.
Aber daraus folgt nicht automatisch, dass Fabric Planning die leistungsfähigere Planning Engine besitzt. Und es folgt auch nicht daraus, dass jedes Unternehmen Fabric als zentrale Datenplattform benötigt.
IBM Planning Analytics kann in heterogene Datenlandschaften integriert werden und besitzt mit TM1 eine spezialisierte Planning Engine. Gerade für Unternehmen mit SAP, Oracle, DB2, Snowflake, bestehenden Data Warehouses oder On-Premises-Anforderungen kann eine solche Unabhängigkeit relevant sein.
Die beiden Strategien unterscheiden sich damit:
Microsoft: Planning als Bestandteil einer umfassenden Daten- und Analytics-Plattform.
IBM: Eine spezialisierte Planning Engine, die in unterschiedliche Daten- und Analytics-Landschaften integriert werden kann.
Wo steht Fabric Planning heute gegenüber IBM?
Eine einfache Gewinner-Verlierer-Betrachtung wäre wenig sinnvoll.
Microsoft besitzt bemerkenswerte Stärken: eine gemeinsame Fabric-Plattform, die Wiederverwendung bestehender Semantic Models, die Übernahme zentraler DAX-Business-Logik, multidimensionale Planning Cubes, treiberbasierte Allokationen, die Nähe zu Power BI und ein interessantes nutzungsabhängiges Abrechnungsmodell.
IBM besitzt dagegen eine über Jahrzehnte entwickelte multidimensionale TM1-Engine, komplexe Rules und Feeders, leistungsfähiges Spreading und Allokationen, Sandboxes, umfangreiche Prozessautomatisierung, PAW, eine tiefe Excel-Integration über PAfE und mit Cognos Analytics eine eigenständige Enterprise-BI- und Reporting-Plattform.
Die große Chance für IBM
Aus meiner Sicht müsste IBM deshalb nicht versuchen, Microsoft Fabric Planning Funktion für Funktion nachzubauen.
Viele der schwierigsten Funktionen besitzt IBM längst.
TM1 muss nicht neu erfunden werden.
Cognos Reporting muss nicht neu erfunden werden.
PAW muss nicht neu erfunden werden.
PAfE muss nicht neu erfunden werden.
Und auch AI ist inzwischen in beiden Produktwelten angekommen.
Die strategisch wichtigere Aufgabe wäre aus meiner Sicht:
Cognos Analytics und Planning Analytics konsequenter zusammenführen.
Nicht zwingend zu einer einzigen technischen Engine, sondern zu einer Plattform, bei der die Produktgrenzen für Anwender zunehmend verschwinden.
Was dafür aus meiner Sicht fehlt
Ganz oben auf der Liste steht: Cognos Data Modules als native semantische Grundlage für Planning Analytics.
Ein bestehendes Data Module sollte inklusive möglichst vieler Business-Regeln, Hierarchien und Security-Definitionen als Ausgangspunkt für ein Planning Model verwendet werden können.
Dazu kämen eine gemeinsame Business-Semantik, gemeinsame beziehungsweise wiederverwendbare Security, gemeinsame AI und Agents, durchgängige Navigation, eine engere Administration und langfristig eine einheitlichere Benutzererfahrung.
Dann könnte die IBM-Architektur lauten:
Cognos Data Modules als gemeinsame semantische Schicht,
TM1 als multidimensionale Planning- und Calculation-Engine,
PAW für Planning,
PAfE für Excel,
Cognos Reporting und Dashboards für BI und Enterprise Reporting,
und AI/Agents über die gesamte Plattform.
Fazit: Microsoft Fabric Planning verändert den Wettbewerb
Fabric Planning verändert die Diskussion.
Die alte Gegenüberstellung Power BI vs. Cognos Analytics reicht nicht mehr.
Ebenso wenig reicht Fabric Planning vs. PAW.
Der interessantere Vergleich lautet künftig:
Microsoft: Fabric + Semantic Models + Fabric Planning + Power BI + AI
gegen
IBM: Planning Analytics/TM1 + PAW + PAfE + Cognos Analytics + AI.
Microsoft besitzt dabei einen überzeugenden architektonischen Ansatz: Bereits vorhandene Semantic Models und zentrale DAX-Business-Logik können für Planning wiederverwendet und erweitert werden.
Der von Microsoft verwendete Grundsatz „Extend, Don’t Rebuild“ trifft einen entscheidenden Punkt. Quelle: Microsoft – Measure Model
Genau hier sollte IBM reagieren.
Denn IBM besitzt mit Cognos Data Modules bereits eine leistungsfähige semantische Schicht und mit TM1 eine ausgesprochen leistungsfähige multidimensionale Planning Engine.
Was fehlt, ist die direkte Verbindung:
Cognos Data Module ? Planning Analytics.
Heute kann Cognos einen TM1-Cube konsumieren und daraus ein Data Module erstellen. Quelle: IBM – Data Modules from OLAP Cubes
Aber der wesentlich interessantere umgekehrte Weg – ein bereits vorhandenes Cognos Data Module mit seiner Business-Logik als Grundlage eines TM1-Planungsmodells zu verwenden – ist derzeit nicht als vergleichbare native Integration dokumentiert.
Genau dort liegt eine große Chance.
Microsoft muss in den kommenden Versionen zeigen, wie weit seine noch junge Planning Engine bei wirklich komplexen Unternehmensmodellen an TM1 herankommt.
IBM muss dagegen nicht erst beweisen, dass es komplexe Unternehmensplanung kann. IBM muss vor allem zeigen, dass aus Cognos Analytics und Planning Analytics künftig mehr werden kann als zwei leistungsfähige Produkte mit Integrationsmöglichkeiten.
Wenn IBM diese Grenze konsequent beseitigt, wäre die Antwort auf Microsoft Fabric Planning möglicherweise längst vorhanden: Cognos Analytics und Planning Analytics als gemeinsame Analytics-, Planning- und AI-Plattform.
