
Meet the Authors
Key Takeaways
-
SAP analytics is evolving as organizations face the challenge of adapting their data models to fit platform architectures like SAP Analytics Cloud (SAC) and Microsoft Power BI, emphasizing the need for robust data modeling.
-
The choice between SAC and Power BI matters significantly for SAP users, as SAC's single-dataset approach supports augmented analytics efficiently for ERP environments, while Power BI excels in operational reporting but requires strong DAX expertise.
-
For SAP leaders, disciplined data modeling is now essential to harness analytics as a strategic advantage; teams must develop skills in dimensional design and SQL to manage growing data volumes without creating bottlenecks in reporting.
There’s a pattern in SAP customers’ analytics struggles: the BI tools keep getting better, but the data models behind them often do not. At SAPinsider Las Vegas 2026, Ken Coleman, business intelligence manager for the American Red Cross, argued the real decision facing SAP teams is not SAP Analytics Cloud (SAC) versus Microsoft Power BI, but whether they are prepared to build models that fit each platform’s architecture and ERP landscape.
Coleman framed SAC and Power BI as two different modeling paradigms.
“A lot of organizations are struggling which background to use,” Coleman says. “Many think Power BI is the cheaper option, but it really isn’t. The better choice depends on your environment. For ERP users, SAC has some great advantages.”
Explore related questions
SAC centers on a single, flattened dataset that can be merged with other themed datasets, which allows its augmented analytics capabilities to scan a consistent semantic layer across SAP and non-SAP sources.
Power BI uses an entity relationship model optimized around star schemas, which is powerful for semantic modeling. However, it’s difficult to merge across separate models and offers limited built-in augmented analytics compared to SAC’s smart features. For SAP users who want search-driven questions, automated driver analysis and predictive suggestions directly in stories, that architectural difference becomes a day-to-day workflow issue.
Coleman cautioned against vendor messaging that modern tools make explicit data modeling obsolete. Most analytical datasets are still aggregations of transactional ERP tables, which means BI teams must understand dimensionality, write SQL or dataflows, and decide which measures truly belong in each model.
When a customer dimension grows to hundreds of billions of rows, pointing at a data lake will not work. Teams must reduce grain, prune dimensions and control how much data they import to avoid performance collapse and runaway costs. In SAC, that often means breaking a monolithic model into smaller themed datasets, such as revenue, operations or inventory and then merging them in stories.

What SAC’s Single-Dataset Approach Means for SAP Teams
SAC’s single-dataset architecture changes how BI and functional teams collaborate. Because stories connect to virtually any data source, including SAP S/4HANA, SAP BW/4HANA and SAP Datasphere, SAC can sit directly on top of trusted ERP and warehouse models while still enabling business users to merge subject-area datasets at the story level. That reduces reliance on IT to prebuild every cross-functional view and lets finance, supply chain and HR analysts experiment with blended datasets without breaking core models.
Coleman noted SAC allows massive importing, but each load carries a cost in runtime, system resources and debugging effort when data quality issues arise.
The key, Coleman says, is finding the right story for the data. “The important thing to know when building stories is finding the theme,” Coleman says. “This will help you build your different datasets.”
Users can develop the theme to choose a manageable set of dimensions, and rely on SAC’s in-story merging to support richer dashboards without ballooning row counts. Because augmented analytics features still work on merged datasets, users can ask natural-language questions, generate smart explanations for variances and explore correlations without learning new tools or languages.
Power BI is valuable where live or direct queries against SAP or non-SAP sources are essential, offline reporting is required or highly operational, ad hoc workloads drive requirements.
Coleman’s broader warning is that organizations which assume Power BI’s lower apparent licensing cost will automatically reduce total BI spend often underestimate the ongoing effort to build and maintain robust semantic models.
Power BI Benefits, Challenges for Users
For SAP leaders, the evaluation checklist emerging includes:
- Assess dominant use cases and decide on augmented analytics versus operational reporting
- Current BI team skill sets (SQL, DAX, SAC modeling)
- The volume and grain of ERP data for analysis
- The need to merge datasets across domains without central IT rebuilding models each time.
Regardless of the platform, Coleman argues a disciplined approach to dimensionality, row-count management and model theming will determine whether analytics becomes a strategic differentiator or another bottleneck between SAP data and decision-makers.
Coleman says, “All these tools work better when you import your data and you need to control how much data you bring in.”
What This Means for SAPinsiders
Data modeling discipline is now the key SAP analytics competency. SAP teams must invest in dimensional design, SQL and governance skills so SAC and Power BI models manage exponential row growth while still delivering trusted ERP insights at scale.
Platform choice should reflect SAP landscape and augmented analytics needs. SAC’s single-dataset, mergeable models and smart features favor SAP-centric environments seeking automated insight, while Power BI still fits star-schema–driven, operational or heterogeneous reporting landscapes with strong DAX expertise.
Hybrid analytics strategies demand clear tool boundaries and ownership. SAP customers must define which platform owns curated ERP semantics, how datasets are themed and merged and who governs models to prevent duplication, drift and conflicting KPIs.




