DE
ENOver the past few years, Cognos Analytics has faced considerable competition from Power BI. Now, Planning Analytics appears to be facing a similar challenge. Where do we stand today?
Here are some thoughts on the subject.
Microsoft has expanded Fabric with a capability that could significantly reshape the enterprise planning market: Microsoft Fabric Planning.
Planning is not simply another Power BI feature. Microsoft explicitly positions Planning in Fabric as an Enterprise and Corporate Performance Management (EPM & CPM) solution for budgeting, forecasting, and scenario planning.
Planning Sheets, PowerTable Sheets, Intelligence Sheets, and Infobridge clearly indicate the direction Microsoft is taking: making enterprise planning a native component of Fabric.
Source: Microsoft – What is Planning in Microsoft Fabric?
For IBM customers, this inevitably raises the question: Is Fabric Planning an alternative to IBM Planning Analytics?
The short answer is that Microsoft is clearly entering Planning Analytics territory. However, comparing Fabric Planning solely with Planning Analytics Workspace (PAW) would be too narrow.
Microsoft is not promoting Planning in isolation. Its argument is based on the entire Fabric platform, including Semantic Models, Power BI, the data platform, and AI.
A fair comparison must therefore consider IBM’s entire ecosystem as well:
IBM Planning Analytics / TM1 + Planning Analytics Workspace + PAfE + Cognos Analytics.
What Is Microsoft Fabric Planning?
Microsoft distinguishes between several core components:
- Planning Sheets: Budgeting, forecasting, and scenario modeling.
- PowerTable Sheets: Structured planning and data applications.
- Intelligence Sheets: Reporting and analysis.
- Infobridge: Data integration and synchronization.
Planning Sheets provide an Excel-like user interface.
Microsoft identifies what-if analysis, forecasting, writeback, and integration with Fabric Semantic Models as key capabilities. Planning results can also be written back to Fabric data structures and subsequently used for analytics.
Source: Microsoft – Planning in Fabric Overview
The objective is clear: Microsoft wants to go beyond analyzing historical data and bring the entire cycle of actuals, analysis, planning, forecasting, scenarios, and reporting more closely together within Fabric.
Microsoft Now Has Multidimensional Planning – But Is It a TM1 Cube?
One of the most interesting developments is Microsoft’s new cube approach.
This is explicitly more than just tabular parent-child hierarchies.
Microsoft describes the cube as a structure that organizes planning data multidimensionally. It supports multiple dimensions, hierarchy levels, and aggregations.
Microsoft explicitly uses the term “multidimensional cube planning” in its documentation.
Source: Microsoft – Allocate Plans with a Cube
This makes it possible to connect planning processes operating at different levels of granularity.
For example, a Finance department might plan at the level of:
GL Account × Region × Time
while Sales works with:
Product × City × Channel × Time
Microsoft describes precisely this scenario: a cube can distribute values across additional dimensions and subsequently aggregate them back to the higher-level planning structure.
DAX measures from the Semantic Model can serve as allocation drivers, including previous-year revenue, current revenue, units sold, headcount, or production volume.
Source: Microsoft – Multidimensional Cube Planning
This is multidimensional planning and considerably more than “Power BI plus input fields.”
Nevertheless, a Fabric Cube Is Not Automatically a TM1 Cube
The term “cube” needs to be used carefully here.
Microsoft’s cube measures primarily address the challenge of breaking down planning values across additional dimensions while maintaining the relationship between different planning levels.
In IBM Planning Analytics, however, the cube is the fundamental data model of the TM1 engine.
This multidimensional engine provides the foundation for calculations, consolidations, and planning logic, as well as features such as Rules, Feeders, Spreading, Sandboxes, and Security.
It would therefore be premature to assume technical equivalence simply because both technologies use the term “cube.”
The interesting question is no longer:
Does Microsoft have cubes?
The answer is now yes: Fabric Planning supports multidimensional planning cubes.
The much more relevant question is:
How far does this cube concept go when applied to complex enterprise models compared with the multidimensional TM1 engine?
This will need to be demonstrated in complex calculation models, allocations, consolidations, large dimensions, security, concurrency, and performance.
Planning Engine: IBM Has Decades of Experience
IBM Planning Analytics is based on TM1.
This engine was specifically developed for multidimensional enterprise planning and has been continuously enhanced over several decades.
Typical TM1 applications go far beyond basic revenue planning.
They include financial and P&L planning, workforce planning, cost center planning, capital expenditure planning, driver-based calculations, currency conversions, complex allocations, bottom-up and top-down planning, Rules and Feeders, Sandboxes, and extensive TurboIntegrator processes.
Source: IBM – Planning Analytics
This is precisely why Fabric Planning should not be evaluated merely on whether users can enter and distribute budget figures.
The comparison becomes truly interesting when examining real enterprise models involving complex rules, numerous dimensions, and large numbers of planners working simultaneously.
A Major Microsoft Advantage: “Extend, Don’t Rebuild”
One of the most interesting aspects of Microsoft’s documentation is the Measure Model.
Microsoft expresses a remarkably clear architectural principle:
“Extend, Don’t Rebuild.”
Organizations that have already invested considerable effort in their central Fabric or Power BI Semantic Model should not have to repeat that work for planning.
Existing centrally defined DAX measures can be reused and extended with planning measures.
Source: Microsoft – Measure Model for Planning
For example, Microsoft describes a centrally defined measure for Revenue Actual.
A Revenue Forecast can then be built on top of that measure within the planning environment.
Actuals and forecasts are therefore not modeled as entirely independent structures. Instead, they can share the same existing business semantics.
This Is Exactly Where IBM Has an Unnecessary Gap
IBM actually possesses all the technical components required to present an equally compelling architecture.
In Cognos Analytics, a Data Module can serve as the central semantic layer.
It contains data sources, joins and relationships, calculated measures, hierarchies, business terminology, filters, business logic, and, depending on the modeling approach, relevant security logic.
Planning Analytics, meanwhile, provides TM1, an exceptionally powerful planning engine.
The problem is the direction of integration.
TM1 ? Cognos Works
Cognos Analytics can access Planning Analytics / TM1 cubes.
Since Cognos Analytics 12.0.3, supported OLAP cubes can also serve as the basis for Data Modules.
IBM explicitly identifies Planning Analytics as a supported OLAP source.
Source: IBM – Creating data modules from OLAP cubes
This means that the following integration path is fundamentally supported:
TM1 ? Cognos Data Module ? Cognos Analytics
The More Important Direction Is Missing: Cognos Data Module ? Planning Analytics
For a truly unified platform, however, the reverse direction would be at least as interesting:
Cognos Data Module ? TM1 / Planning Analytics
At present, there is no comparable documented native mechanism that allows an existing Cognos Data Module to become the direct semantic foundation of a new TM1 planning model.
In my view, this is one of the largest unnecessary integration gaps between Cognos Analytics and Planning Analytics.
Consider an organization that has already created a Data Module in Cognos:
SAP + DWH + CRM + External Data ? Cognos Data Module
This model already contains business logic, relationships, measures, hierarchies, and security definitions.
Now the organization wants to plan using exactly the same enterprise data.
Why should this business logic have to be recreated in Planning Analytics?
In practice, the result is often two parallel architectures:
DWH ? Cognos Data Module ? Cognos Analytics
and:
DWH ? Data Integration / TurboIntegrator ? TM1 ? PAW
This creates two separate semantic worlds that must be maintained and synchronized.
What a Truly Integrated IBM Analytics and Planning Platform Could Look Like
Ideally, the architecture would move toward the following model:
Data Sources / DWH / Files / APIs
Cognos Data Module
Shared Semantic Layer
Cognos Reporting
Cognos Dashboards
Planning
AI
TM1
Multidimensional Planning and Calculation Engine
This would by no means require replacing TM1.
On the contrary, the TM1 engine would remain a significant competitive advantage.
The Cognos Data Module would provide business semantics and data access.
TM1 would add the capabilities required by a specialized planning engine: writeback, spreading, Rules, Feeders, Sandboxes, scenarios, allocations, and multidimensional calculations.
A feature such as “Create Planning Model from Data Module” would therefore be a logical next step.
Dimensions, hierarchies, measures, and ideally security definitions could be transferred from an existing Data Module.
The next step would be to define which measures are available for planning, which versions are required — such as Actual, Budget, and Forecast — and which additional TM1 rules should apply.
Security Makes This Especially Important
Maintaining business logic twice is inconvenient.
Maintaining security logic twice is considerably more problematic.
If an organization has already defined that a regional manager may only access their own region, or that a cost center manager may only see their assigned cost centers, this access logic should ideally not have to be implemented from scratch for planning.
This is precisely where Microsoft’s reuse of existing Semantic Models is conceptually attractive.
However, it is equally important not to attribute capabilities to Microsoft that are not yet fully supported.
Fabric Planning Still Has Security Limitations
Microsoft’s own documentation currently lists several known limitations.
These include restrictions affecting certain Semantic Model configurations and Row-Level Security in specific Planning components.
Source: Microsoft – Known limitations in Planning
This matters when evaluating the platform.
Microsoft has an attractive concept for a shared semantic foundation.
However, this does not automatically mean that all security and governance rules are already propagated consistently and completely across every Planning component.
There Are Currently Scalability Limits as Well
Fabric Planning is still a young product, and Microsoft documents specific technical limitations.
These include limits on the number of sheets and visuals within a Plan Item, as well as restrictions on certain queries and writeback operations.
Microsoft maintains a dedicated documentation page for current limits and restrictions. Given the product’s rapid development, these should be reviewed before making a project decision.
Source: Microsoft – Planning limitations
These limitations do not automatically mean that Fabric Planning is unsuitable for large-scale enterprise planning.
They do, however, demonstrate why comparisons with mature TM1 applications need to be approached carefully.
Workflow: Microsoft Is Catching Up
Enterprise planning is not just about numbers.
Planning values must be entered, submitted, reviewed, potentially corrected, and ultimately approved.
Fabric Planning provides Approval Workflows for these processes.
Microsoft documents structured approval processes, including multi-level approval scenarios.
Source: Microsoft – Approval Workflows
IBM Planning Analytics Workspace also provides extensive planning processes involving tasks, responsibilities, statuses, and approvals.
Fabric Planning should therefore no longer be regarded as merely an input extension for Power BI.
Microsoft is clearly developing it toward a more comprehensive CPM/EPM solution.
Excel Remains an Important Differentiator
For many Planning Analytics customers, PAW is only one component of the platform.
Another essential client is Planning Analytics for Microsoft Excel (PAfE).
With PAfE, Microsoft Excel itself becomes the user interface for the TM1 engine.
Users can combine their established Excel workflows with centrally managed TM1 data and planning capabilities.
Fabric Planning, by contrast, uses Planning Sheets to provide an Excel-like interface within Fabric.
Source: Microsoft – Planning in Fabric
This distinction is particularly relevant for financial controllers who use complex existing Excel workbooks connected to a planning engine.
Cognos Analytics Must Be Part of the Comparison
Comparing Fabric Planning with PAW alone would be incomplete for another reason.
Microsoft Planning operates in an environment that includes Power BI.
It would therefore be unfair to exclude Cognos Analytics from the IBM side of the comparison.
The IBM ecosystem consists of:
- TM1: Planning Engine
- Planning Analytics Workspace: Web Planning, Analysis, and Workflow
- Planning Analytics for Excel: Excel-based Planning
- Cognos Analytics: Dashboards, Analysis, and Enterprise Reporting
IBM therefore already has an Analytics and Planning ecosystem.
However, it is perceived more as an integration of separate products than as one unified platform.
Microsoft Sells a Platform – IBM Sells Products
This is a fundamental difference in market perception.
Microsoft says: Fabric.
Under this umbrella are the data platform, Semantic Models, Power BI, Planning, and AI.
IBM says: Cognos Analytics and Planning Analytics.
Technically, this does not mean IBM lacks an integrated solution.
But Microsoft’s narrative is easier to communicate:
Data + Semantic Model + BI + Planning + AI under one Fabric umbrella.
IBM has many equivalent components, but the boundaries between its products are more visible to users and administrators.
The missing native connection between Cognos Data Modules and TM1 Planning Models demonstrates that this is not merely a matter of product naming.
It is also a genuine technical integration gap.
AI: Two Different Strategies
AI is becoming increasingly relevant to enterprise planning.
Microsoft describes Fabric Planning as a foundation for AI-assisted decision-making.
Intelligence Sheets and the broader Fabric AI ecosystem are intended to connect analysis and planning more closely.
Source: Microsoft – Planning in Fabric
IBM, meanwhile, is pursuing a more planning-specific approach within Planning Analytics.
Planning Analytics includes AI capabilities that operate directly on planning data and TM1 models.
These include Explain Cell, Variance Analysis, Forecasting, and the Planning Analytics Agent.
IBM documents the ongoing expansion of these AI capabilities in its current Planning Analytics releases.
Source: IBM – Planning Analytics Workspace New Feature Summary
Explain Cell, in particular, illustrates the difference from a general-purpose chat assistant.
AI can help explain a value by considering how that value was calculated within the planning model.
This creates two distinct strategies:
Microsoft: AI as part of a comprehensive data, BI, and analytics platform.
IBM: AI deeply integrated into a specialized multidimensional planning engine.
The More Interesting AI Question
In the future, users should no longer need to know which product is responsible for answering their questions.
For example:
Why is Germany eight percent below plan in the third quarter, and how would the full-year result change if we assumed three percent higher sales volume in Q4?
The first part is traditional analytics.
The second involves planning and simulation.
Technically, different engines may be responsible for each part.
From the user’s perspective, however, the boundary between these engines should ideally disappear over time.
Microsoft’s Unusual Pay-per-Use Model
One of Fabric Planning’s most interesting innovations is its billing model.
Microsoft uses an active-session, capacity-based pricing model with different roles, such as Planner, Stakeholder, and Viewer.
Source: Microsoft – Planning Billing and Pricing Model
The key element is the session concept.
A session begins when a user actively interacts with Planning and remains active for Microsoft’s defined billing period.
This means that “Pay per Use” should not be confused with “Pay per Minute.”
A more accurate description would be:
Pay per active user per 30-day period.
Current consumption rates and role definitions should be checked directly in Microsoft’s documentation, as the model may still change during the Preview phase.
Source: Microsoft – Billing
This Could Be Particularly Attractive for Occasional Planners
Enterprise planning often involves a highly uneven distribution of users.
For example, 15 central financial controllers may work in the system continuously.
In addition, there may be 500 cost center managers who only enter or approve values during budget and forecast cycles.
A usage-based model can be economically attractive for this type of occasional user.
However, Planning Sessions are not the only source of Fabric consumption.
A cost comparison with IBM Planning Analytics must therefore consider the entire system rather than focusing solely on the nominal Planning consumption figures.
Important: Fabric Planning Is Still a Young Product
Despite all these capabilities, product maturity must not be overlooked.
Microsoft still documents known limitations for Planning and continues to develop features, technical limits, and the billing model.
Source: Microsoft – Known Limitations
Broad availability does not automatically mean that every feature has reached the maturity of a planning platform developed over several decades.
Fabric Planning Must Nevertheless Be Taken Seriously
Conversely, the product’s relative immaturity should not lead anyone to dismiss Fabric Planning as a toy.
Microsoft already demonstrates extensive planning scenarios, including revenue planning, bottom-up sales planning, rolling forecasts, statistical forecasting, P&L structures, and scenario modeling.
Source: Microsoft – Planning Tutorial
The product is clearly positioned for enterprise planning.
Is “Everything on One Platform” Automatically Better?
Microsoft’s strongest argument is that Planning is integrated directly into Fabric.
This is a genuine advantage for organizations already using Fabric as their central data and analytics platform.
Existing Semantic Models, DAX measures, actuals, and business logic can then be reused for planning.
However, this does not automatically mean that Fabric Planning has the more powerful planning engine.
Nor does it mean that every organization needs Fabric as its central data platform.
IBM Planning Analytics can be integrated into heterogeneous data landscapes and provides a specialized planning engine in TM1.
This independence can be particularly relevant to companies working with SAP, Oracle, DB2, Snowflake, existing data warehouses, or on-premises requirements.
The two strategies therefore differ:
Microsoft: Planning as part of a comprehensive data and analytics platform.
IBM: A specialized planning engine that can be integrated into different data and analytics environments.
Where Does Fabric Planning Stand Compared with IBM Today?
A simplistic winner-versus-loser comparison would not be particularly useful.
Microsoft has notable strengths:
- A unified Fabric platform.
- Reuse of existing Semantic Models.
- Reuse of centrally defined DAX business logic.
- Multidimensional planning cubes.
- Driver-based allocations.
- Close integration with Power BI.
- An interesting usage-based billing model.
IBM, on the other hand, offers a multidimensional TM1 engine developed over several decades, complex Rules and Feeders, powerful Spreading and allocation capabilities, Sandboxes, extensive process automation, PAW, deep Excel integration through PAfE, and Cognos Analytics as a dedicated enterprise BI and reporting platform.
IBM’s Major Opportunity
In my view, IBM should not try to replicate Microsoft Fabric Planning feature by feature.
IBM already possesses many of the most difficult capabilities.
TM1 does not need to be reinvented.
Cognos Reporting does not need to be reinvented.
PAW does not need to be reinvented.
PAfE does not need to be reinvented.
And AI has now become part of both product families.
In my opinion, the strategically more important task is:
Bring Cognos Analytics and Planning Analytics much closer together.
Not necessarily by merging them into a single technical engine, but by creating a platform where the boundaries between products increasingly disappear for users.
What I Believe Is Still Missing
At the top of the list is the ability to use Cognos Data Modules as a native semantic foundation for Planning Analytics.
An existing Data Module should be usable as the starting point for a Planning Model, including as many business rules, hierarchies, and security definitions as possible.
Additional requirements would include shared business semantics, shared or reusable security, common AI capabilities and agents, seamless navigation, closer administrative integration, and ultimately a more unified user experience.
The resulting IBM architecture could consist of:
- Cognos Data Modules as the shared semantic layer.
- TM1 as the multidimensional planning and calculation engine.
- PAW for Planning.
- PAfE for Excel.
- Cognos Reporting and Dashboards for BI and Enterprise Reporting.
- AI and Agents spanning the entire platform.
Conclusion: Microsoft Fabric Planning Is Changing the Competitive Landscape
Fabric Planning changes the discussion.
The traditional Power BI versus Cognos Analytics comparison is no longer sufficient.
Neither is Fabric Planning versus PAW.
The more relevant comparison going forward will be:
Microsoft: Fabric + Semantic Models + Fabric Planning + Power BI + AI
versus
IBM: Planning Analytics/TM1 + PAW + PAfE + Cognos Analytics + AI.
Microsoft offers a compelling architectural approach: existing Semantic Models and centrally defined DAX business logic can be reused and extended for planning.
Microsoft’s principle of “Extend, Don’t Rebuild” addresses a critical issue.
Source: Microsoft – Measure Model
This is exactly where IBM should respond.
IBM already has a powerful semantic layer in Cognos Data Modules and an exceptionally capable multidimensional planning engine in TM1.
What is missing is the direct connection:
Cognos Data Module ? Planning Analytics
Today, Cognos can consume a TM1 cube and create a Data Module from it.
Source: IBM – Data Modules from OLAP Cubes
However, the much more interesting reverse direction — using an existing Cognos Data Module and its business logic as the foundation for a TM1 planning model — is currently not documented as a comparable native integration.
That is where a major opportunity lies.
In future releases, Microsoft will need to demonstrate how closely its relatively new planning engine can match TM1 when handling truly complex enterprise models.
IBM, by contrast, does not need to prove that it can support complex enterprise planning.
What IBM primarily needs to demonstrate is that Cognos Analytics and Planning Analytics can evolve into more than two powerful products with integration capabilities.
If IBM systematically eliminates this boundary, the answer to Microsoft Fabric Planning may already be there: Cognos Analytics and Planning Analytics as a unified Analytics, Planning, and AI platform.
