SAP Analytics Cloud Planning and SuccessFactor – Building a robust Planning Model – Some best practices examples and tips
This blog is complementary to the blogs of my colleague Manivannan Pachiyappan, SuccessFactor Expert.
His first blog explains in details how to connect both applications SAP Analytics Cloud and SAP SuccessFactors (HCM): Connection and Automatic User Sync, Detailed Illustration | SAP Blogs
And the second SAP Analytics Cloud Planning with SAP SuccessFactors (HCM): Step by Step Illustrations of the Best Practices for Workforce Planning | SAP Blogs
“responds” to mine in illustrating in detail configuration aspects when creating a Planning model based on SuccessFactor application .
With those blogs, we hope to break silos and help administrators configuring end-to-end Workforce Planning scenarios.
TOPIC 1 “Measures” or “Account” Planning model layout? Which Model layout to select?
As referenced in this blog from the Product Management SAP Analytics Cloud for Planning: Leveraging calculated & conversion measures in the New Model | SAP Blogs
The Measure model is better suited to use cases without financial background, especially if you need to calculate movements of the resources within a period.
Plus, calculations have been optimized in the data engine which is a differentiator for HR use cases with dimensions with numerous dimensions members (like Employees).
Before selecting this Model layout, please bear in mind that there are still some restrictions to this type of model which are going to be been lifted in the coming QRC releases and they might be not adapted to your business case.
Please rely on this HELP link Restrictions to the new model and on our Roadmap Explorer SAP Analytics Cloud Roadmap Explorer_New model features to validate your decision.
TOPIC 2 : Public or Private dimension?
When creating a SAP Analytics Cloud Planning model, you can base your model either on Public or on Private dimensions.
What are the differences between both options?
The main advantages of a Public version is the creation and the update of master data triggered from a system which is the single source of truth of the master data.
Master data don’t have to be always directly maintain in the model itself.
Public dimensions can be used in different Planning models. This avoids any duplication and maintenance efforts.
Most large companies use Public dimension, for example, for Company code or Cost center, the master data are already maintain by the administrators in exogenous systems to SAP Analytics Cloud.
The decision to go for Public dimensions is also linked to the other Planning projects of the Company. For example, a Public dimension with Company codes can be valid in HR and Financial Planning projects.
Before making any decision, please try to anticipate the overall use of SAP Analytics Cloud Planning in the context of all coming Planning projects of the company.
See details of creation here: Import master data in a Public dimension
TOPIC 3 Creation of dimensions from SuccessFactor tables: dimension or property/hierarchy of another dimension?
When creating a Planning model by importing master data from Success Factor to SAP Analytics Cloud Planning, beforehand a few considerations need to be taken into account .
Please, analyse first the relationships between Success Factor tables.
Don’t create one dimension for every Success Factor table.
Because dimensions in Planning model are used to collect data not only to retrieval purposes.
To illustrate this approach, let’s take the example of the gender.
When is the gender a dimension or a property/hierarchy of the dimension?
The gender is a dimension if you need to store this information on a dedicated dimension, for example when you explicitly want to plan the recruitment of a specific gender in your budget.
The gender is a property/hierarchy when the gender characterizes the dimension members and is needed for retrieval purposes.
Gender as a dimension
In this example, you plan the number of women headcounts you need to hire to meet the diversity percentage metrics of your company in the coming year.
The dimension “Gender” is used to qualify the data to be collected.
In our example, the end user inputs the number of women to be hired per Job Family and Level.
Detail of the Gender dimension
Gender as a property and part of a level-based hierarchy
In this example, the gender of employees of the company is defined for every dimension member in the Employees ID dimension, this definition is configured as a property and in a level-based hierarchy for retrieval purposes.
No dedicated dimension has been created, the information about the Gender is displayed and totals are automatically calculated by the hierarchy.
In a story, please find below the details of the FTE of the company per gender with Totals associated per level-based hierarchy member and per employee the retrieval of the property Gender in the dimension Employee ID.
Details of the model dimension Employee ID and the property “Gender”
Details of the level-based hierarchy build on the property “Gender”
TOPIC 4 : Use Planning area option and set up Data Access Control and Data Locking
Those options help to reduce any performance issues during the data collection and calculation processes because it restricts the part of the “cube area” in the Private version (before data Publish)
- Toggle on the Planning area option in the preferences of the Planning model
- Toggle on the Data Access Control in the dimensions with the largest number of dimension members (use Teams to define the accesses to the Read and Write columns)
- Configure the Data locking on the Actual data as they are solely used as a reference for data collection and when planning data they shouldn’t be modified