Skip to content
SRB Consulting Team
Finance & Analytics

Decide: What it really takes to succeed with Datasphere

By Irene Preiner
Bildschirm mit Grafik Icons

SAP Datasphere is coming. And with it, success. At least that's how many companies envision it. Often, disillusionment follows and the realisation that a dashboard and a data model alone do not create business value. But where does it falter?

Many companies today invest in modern data platforms. With SAP Datasphere and the SAP Business Data Cloud, SAP provides central building blocks for this purpose. The goal is to unite data integration, semantic modelling, governance, and data products in a common environment.

This sounds excellent and promises a lot. The disappointment after go-live can sometimes be even greater. Yes, data quality is better, transparency is higher, and dashboards are available more quickly. Nevertheless, discussions in many management meetings do not become shorter. The numbers are on the table, and everyone looks at the same dashboard. But then the discussion begins on the same recurring questions:

“Which number is actually correct?”

“Is this the billed revenue or the order intake?”

“Can we check the data again?”

Instead of making decisions, numbers are interpreted. Instead of taking action, new analysis requests arise. This is where it becomes clear: the problem does not lie in the data platform. More often, it becomes evident that there is an often underestimated gap between the data model and decision-making.

Information is not yet decisions

SAP Datasphere can provide data. And the dashboard usually answers one central question: What has happened? However, it does not automatically ensure that people decide faster, clearer, or more consistently. To be a data-driven company, as McKinsey describes, one must actually embed data into interactions and business processes.

Important questions need to be asked:

  • Why did something happen?
  • Is the deviation even relevant?
  • Which areas are affected?
  • What options for action are there?
  • What happens if no action is taken?

A sales manager can, for example, see within seconds how revenue in Germany developed in the last quarter. The real work begins afterwards: Do prices need to be adjusted? Are there supply bottlenecks? Has a customer segment disappeared, or is it a seasonal effect?

The information is available. The evaluation and decision remain the responsibility of management and specialist departments.

Semantics is not just technology, but communication

With a data platform, everything is actually prepared to achieve success. But why do many companies find it so difficult to move from information to decisions?

One reason surprisingly rarely lies in missing data. More often, a common understanding of what the available data actually means is lacking. This is precisely why semantics plays such a central role in Datasphere.

SAP describes semantic models as the basis for a unified understanding of key figures, hierarchies, and business objects. Functions like “Generate Semantics” assist by suggesting facts, dimensions, attributes, and semantic types. At the same time, SAP points out that important contextual relationships, such as hierarchies, cannot be automatically recognised. Therefore, clarification remains necessary.

Here, the subtleties and nuances can best be illustrated with an example. Let’s take the term “revenue.” Depending on the department, it can mean something completely different:

  • Order intake
  • Billed revenue
  • Net revenue after discounts
  • Revenue after cancellations
  • Revenue by delivery date
  • Revenue by booking date

If sales, controlling, and management use different definitions, no common situational picture emerges. While everyone sees the same key figure, they understand something different by it. Semantics is therefore much more than just the labelling of a column. It is the fundamental agreement on what a number actually means in the company.

Simple questions require clear definitions

WithJust Askusers in SAP Analytics Cloud can ask questions in natural language and receive answers as key figures or charts. Joule also offers a dialogue-oriented approach to analytical information. Both functions rely on prepared analysis models that must be described and structured consistently.

This makes analyses significantly more accessible. However, the requirements for the underlying data model increase. A seemingly simple question like “Show me the margin by product group” immediately raises further questions:

  • Which margin is meant?
  • Contribution margin 1 or 2?
  • With or without freight costs?
  • According to which product group definition?
  • For actual, plan, or forecast?

The simpler the interface becomes, the clearer the key figures, dimensions, and business terms must be defined underneath. Natural language facilitates access to data but does not replace clear definitions.

Data products need accountability

Let’s assume that key figures and terms have been defined. Then success should be within reach, right? It would be nice. But once this hurdle is overcome, the next one arises: Who takes responsibility for it?

With the concept of data products, SAP aims to address exactly this issue. Data should not only be technically available but also provided as reusable, contextually understandable, and 'governed' products. In practice, however, models are built, views developed, and dashboards created. When later asked about the responsible person, it often goes silent.

There is a need for answers to the following questions:

  • Who is the subject matter owner?
  • Who decides on KPI definitions?
  • Who checks data quality?
  • Who documents known limitations?
  • Who officially approves a model?

How significant this issue can become when these matters are not clarified is evident in cross-departmental models. A Customer-360 model, for example, contains data from sales, service, invoicing, and possibly external sources. As long as it is not clearly regulated which customer definition is leading or how duplicates are handled, there remains room for discussion.

A data product only realises its value when it is clear who is responsible for content, quality, and further development.

Decisions must land in the process

However, perhaps the most common reason for the lack of business value lies elsewhere. Many companies create good analyses. However, the decisions derived from them remain outside business processes, as some typical examples from different areas show:

Working capital

A dashboard shows overdue receivables. More important than the analysis would often be the question:

  • Which customers need to be contacted today?
  • Who takes care of that?
  • What escalation rule applies?

Sales

A forecast deviates from the pipeline. The actual question is:

  • Which opportunities are critical?
  • What assumptions have changed?
  • Who decides on countermeasures?

Even at the risk of repeating myself, it becomes clear: A dashboard is not a process. It only becomes effective when a concrete action arises from it.

The last mile is the hardest

On the last mile between data and real decision, five simple questions arise:

  • Does everyone understand the same key figure?
  • Is it clear which data source is leading?
  • Is there a subject matter responsible?
  • Is the insight connected to an action?
  • Is it checked whether the decision actually had an effect?

Those who take this path and can answer the questions are almost where companies with modern data platforms want to be. Investing in this is important and right. Most companies now have access to more data than ever before. However, the business impact does not arise from the platform alone, but from shared definitions, clear responsibilities, and decisions that are consistently integrated into business processes.

SAP Datasphere provides an important foundation for this. Whether better decisions actually arise from it is determined on the last mile. There, where data becomes responsibility and insights lead to concrete action.

Related articles