SAP Analytics Cloud data modeling: Use 1 single model or 2 or more data models?

[#1]

Dear SAC experts,

We're currently developing a prototype for utilizing SAC in planning, and we're eager to seek your insights and expertise on a critical matter.

The scenario involves a company with Actuals and Planning data pertaining to two distinct organizational units or sectors within one company. The data varies in granularity, with Actuals being the most detailed. Additionally, the Planning granularity differs between sectors; for example, one operates at a product level while the other functions at a company level.

In terms of constructing the data model, we're exploring two hypotheses:

1) Creating three separate models (akin to BPC's aDSO's), each tailored for a specific type of data. The dimensions would remain public and shared across these models. This approach, though not uncommon in SAC, might be beneficial if dealing with sizable data sets for actuals and plan data. Keeping them separate could potentially enhance performance, especially in scenarios involving large data volumes or when sourcing actuals and plan data from distinct systems with differing data structures or governance practices.

We came across a similar use case in a SAC blog post (https://blogs.sap.com/2023/04/28/sap-analytics-cloud-planning-managing-data-granularity-when-planning-and-avoiding-performances-issues/), but it seems to focus on applications with varying data frequencies (monthly vs. daily), which might not directly align with our specific use case.

2) Alternatively, maintaining a single model encompassing all data and utilizing restricted measures. This approach allows accommodating different granularities within the same dashboard or story. Based on my experience, a unified data model typically delivers better performance and faster data processing compared to managing multiple models. While a related SAP link I found isn't accessible anymore (https://help.sap.com/viewer/product/SAP_ANALYTICS_CLOUD/2105/en-US/a1d2524931194f4fb71109af05359ba3.html), it highlighted that a single data model offers better performance and less delays for data processing compared to having multiple data models.

Moreover, managing a single model typically delivers better performance and avoids running data actions to transfer data between models; also for reporting purposes it is usually easier to have all data in a single model.

In my view, opting for a single model for these case seems advantageous, aligning with the practices followed by many companies and streamlining the analysis experience. It allows for easier comparison, aggregation, and analysis across different scenarios and timeframes. However, we are still reluctant to make a final decision.

What should be the best approach in this case? One single model for Actuals and Planning data, or separate models for Actuals and Plan?

Many thanks for the support!

[mholiveira]

Hi Diogo,

This topic is an interesting topic, that usually does not have a simple answer.

Several factors will lead to the decision of how to organise the planning modules/processes in one company.

First, before even deciding the number of models, understanding adequately which processes and the organisation's maturity is crucial. From what you describe the same process has different granularity according to the business departments. This complicates the process but does not mean it needs to be two separate models.

Another subject is how the Actuals will be used. Typically, they are used to support the Planning process and there are many organisations following the approach suggested by Oleksandr. Normally, the issue that follows afterwards is the maintenance (and how pragmatic) associated with this "merge datasets approach". A common example is if you want to make a simple report, you need always to merge (via union) both datasets to simply show actuals versus plan. Another example is if you make Calculated Measures you need to duplicate the formulas and merge them on the report (as you can guess, IT does not appreciate this). Lastly, the management of page and story filters can become a nightmare when you have multiple models (linking dimensions can bring performance issues).

As such, what commonly leads to the decision is not related to versions/categories but should be how the processes are defined and stable in the organisation. Hence, this might result in different models. For example, if you look at the FP&A business content you will understand that SAP is divided into models to make it easier to manage and handle different granularities. But in the end, is nothing related to categories, but to the processes itself.

Now, the SAC performance is closely tied to the data volume, and, of course, granularity has some impact. But, unless you are planning at the SKU/WBS 3-level element level (something that is odd by nature) having up to 12-15 dimensions should be okay in the same model.

Lastly, the other topic is data governance/data preparation for the plan. As you mentioned it is cumbersome to manage different sources of data. As such, what makes sense is to have a single source of truth (for example, BW or Datasphere) that is responsible for the standardisation and harmonisation of data. With this, you can have KPIs that drastically the complexity.

As an extra topic, it is not a good idea to think about BW-IP / BPC Standard versus SAC. There are completely different tools that have different solutions. Therefore, trying to replicate the previous way simple reveals lack of experience.

[Oleks_Master]

Hi Diogo,

If granularity is different then I would go with different models. Full stop for me.

In your scenario with different departments, different planning levels, and probably different processes, it will let you make other settings also different: Data locks, Calendar (Process flow), Security, etc.

When you read that performance of one model is better, it means performance of reports (data reading) is better. But performance of planning (data writing and reading) will better with two models. And input forms will be easier.

If you like, more granular data might be loaded into another model, or even into a third model (read only) for performance purpose of final reports on both data sets.

In short, planning part is more important here then reporting.

I hope it will help you.

Best regards,

Oleksandr