Planning process in the SAP Analytics Cloud

Planning has more components than the collection of planning figures. A core component is the planning process, in which the prerequisites for the inputs must be created. This can be as large and complex as desired. Multiple plan versions, user groups and revisions must be harmonised to ultimately be available for reporting. The SAP Analytics Cloud provides the calendar as a standard planning process control. Tasks and processes can be created, managed, and monitored in this calendar. Since Q2 2022, dependencies between tasks and processes are possible. This change increases the possibilities to model more complex planning processes. This blog is intended to illustrate the structure, possibilities, and limitations of the current version (Q1 2023) using a simple example.

 

Starting Point

The following example serves to illustrate the features of the calendar. A bicycle manufacturer, where the sales managers of the individual bicycle divisions (mountain bike, road bike, etc.) must make a sales forecast. The process should look as follows:
Planungsprozess

The starting point for planning is a model that is ready for planning.

SAP Modell

The sales managers are assigned to individual product groups and plan these accordingly as part of a team. The individual planning tasks are restricted via the product group. Responsible persons can be defined in the master data behind the product group. Since this information is copied when the calendar is created, we recommend that you do not define individual users here, but groups. The person responsible is needed in the further process.

The planning should first take place in a story. This contains only the planning model with an input-ready table.

This should be the starting point of the planning process.

 

Modelling the planning process in the Analytics Cloud

The planning calendar offers various building blocks, so-called tasks, from which the process can be modelled. Working files, i.e., stories or analytical applications, as well as descriptions and personal notes can be stored in all tasks. A task needs a starting point, which can always be set in terms of time. Some tasks can also be started via the parent process or in dependence on others. The parent process, under which all other tasks lie, is defined by the start conditions of the tasks.

An overview of the individual tasks:

  • General Task: This task transfers stories or analytical applications directly to persons or teams with a set filter area, responsible viewer or reviewer, a time frame and other files that could help with planning. Reporting masks with the last planning round or similar are plausible here.

  • Review Task: These transfer the results of a planning round for approval. The review task is always dependent on another task or a parent process.

  • Composite Task: A combination of General Task and Review Task. If the process is not to be too granular, the Composite Task can be used instead of the General Task and Review Task. These start either at a specific time, depending on another task or a parent process.

  • Process: Serves as an organising element for the process. Has the same capabilities as a General Task.
  • Data Locking Task: For automatic or manual setting of data locks.
  • Data Action Task and Multi Action Task: For executing data actions.
  • Input Task: An old task that is no longer used.

An initial structure of the process could look as follows.

The first process serves as a sorting process and has no tasks. It is the parent process for all underlying tasks.

The Revenue_Forecast_Planning Task is where the planning and review rounds are to take place. The second task is a data action that copies the actuals from the previous year into the forecast as a basis for this year's forecast. This task starts after the parent process has started.

The Revenue_Forecast_Locking Task sets a data lock on the data areas that are not to be changed after planning. The execution of this task does not depend on the Parent Task, but on the Revenue Forecast_Planning Task. As soon as this task is successfully completed, the data lock is executed.

 

 

With these four objects, we have a basis of events that build on each other and replicate the planning process.

  1. start the overlying process.
  2. automatic execution of the data action and copying of the actuals into the forecast version
  3. start of the actual planning.
  4. data lock

Now the Revenue_Forecast_Planning process must be filled with content. The Event Wizard generates all the necessary input tasks. Our planning story is the basis of planning for all tasks in the process.

 

 

Planning is subdivided into product groups, which is why we choose this as the Driving Dimension.

 

 

The "Person Responsible" defined in the product group dimension are the processors of the tasks. The Reviewer is not necessary, the Review Task takes over this task.

 

 

The exact event name can be defined in the fourth step. The description is sufficient for our example.

 

 

After a preview, the tasks are created automatically.

 

These tasks are time-dependent, the Event Wizard does not allow any other setting. However, the individual tasks can be changed for dependent start with the parent process.

Individual reviewers can be added directly in the tasks. This is useful when each schedule reviews a different group of people. For this process, we use a Review Task that should start as soon as all planning is completed, as all results should be reviewed by the same group.

 

 

The Review Task depends directly on the Plan Tasks. As soon as these are completed, the review begins.

The whole process looks like this:

 

 

In order for planning to start, the process must still be activated.

 

 

After activation, the data action for copying the data is executed and the tasks for planning begin. The success of a task is directly visible in the calendar, as is the progress of individual tasks. The target achievement can be defined by the user. For a task with several review rounds, the actual planning could fill the progress by 50%, the first review round by 25% and the second round also by 25%.

 

 

The planners can be made aware of their new task by e-mail or within the SAC. In both cases, a link leads to the planning story in which the defined planning tasks are waiting with the corresponding filters. When this story or analytic application is called up from the calendar, a new toolbar is visible that makes it possible to submit or delete one's own entries.

 

 

Submit completes the task and marks it accordingly in the calendar. Decline sets the task to "on hold" for the time being. A new agent can then be selected in the calendar or the task can be sent to the same person again. Submit always applies to all agents of this task, decline can only be executed for one or all.

 

 

After the last task has been submitted, the review task begins. The layout of this task is similar to that of the input tasks.

 

 

Approve corresponds to Submit, Reject returns the task to the planners from before and the status is reset. Since we have a review task for all three plannings, they would all be open again. With Approve, this part of the planning is also completed. The parent process Revenue_Forecast_Planning can be Submitted in the calendar and thus declared complete. The submit takes place in the task in the calendar itself. Data locking automatically locks the defined data area after the planning process is completed. Thus, the entire planning is finished and ready to be checked in reporting.

 

Difficulties in using the calendar

Manual rework for each generated single step
Many manual steps are necessary to set up the process. In the example, only three product categories are split up; with a much higher number, the adjustment effort increases accordingly. The wizard for creating the tasks does not allow for setting the dependencies, which requires manual corrections in all individual tasks. There is a lack of convenience features that allow for easy modelling. The process modelled here could be used for January in this way, but it would first have to be copied for February and adapted if necessary. Again, this shows the increased manual effort.

Time-dependent representation, not process-dependent
The layout and the mandatory time dependency of all processes take a lot of getting used to. The view is always designed for the time period and not for the individual processes. When entering the monthly view, processes for the next month are not displayed, and when entering the annual view, performance suffers greatly as soon as many individual tasks are used.

No interlocking with the loading possible
Basically, a task for loading the planning model would be desirable. The import and export jobs can currently be set via the data management in the model without coding and are only time-dependent here. Event-based import and export based on calendar tasks would be desirable.

Analytic Applications expand the calendar possibilities
Some handling issues can be worked around within an analytic application using the Calendar API. Primarily, the approvals and submits that appear automatically when the calendar tasks are called can be integrated with the API itself. In addition, composite tasks can be created directly. However, this does not allow processes to be modelled and the tasks can only be switched depending on time.

 

Conclusion

In summary, the calendar is well suited for modelling simple planning processes. The collaboration options are a strength in the Analytics Cloud and come into their own here. However, changes in the planning or individual tasks must always be accompanied by experts. It is therefore questionable whether the calendar can be managed by the business user alone or whether it must also be supported by IT.

 

Contact Person

Dominik Dussa

Consultant

Data Products Setup

I’ll start with Data Products setup. If you’re new to the concept, this recent video is a great starting point, but here’s a short summary. A data product is a well-described, easily discoverable, and consumable collection of data sets.

Creating a Data Product in Datasphere

Note that in this article I create Data Products in the Data Sharing Cockpit in Datasphere. This functionality is expected to move into the Data Product Studio, but that had not taken place at the time writing.

Before creating a Data Product in Datasphere, I need to set up a Data Provider profile, collecting descriptive metadata like contact and address details, industry, regional coverage, and importantly define Data Product Visibility. Enabling Formations allows me to share the Data Product with systems across your BDC Formation – Databricks, in this case.

With the Data Provider set up, I can go ahead and create a Data Product. As with the Data Provider, I’ll need to add metadata about the product and define its artifacts – the datasets it contains. Only datasets from a space of SAP HANA Data Lake Files type can be selected. Since this Data Product is visible across the Formation, it is available free of charge.

For this demo, the artifact is a local table containing ten years of Ice Cream sales data. Since this is a File type space, importing a CSV file directly to create a local table isn’t an option (see documentation).

I used a Replication Flow to perform an initial load from a BW aDSO table into a local table.

Once Data Product is created and listed, it becomes available in the Catalog & Marketplace, from where it can be shared with Databricks by selecting the appropriate connection details.

Jump into Databricks

To use the shared object In Databricks, I need to mount it to the Catalog – either by creating a new Catalog or using an existing one.

Databricks appends a version number to the end of the schema – ‘:v1’ – to maintain versioning in case of any future changes to the Data Product.

Once the share is mounted, the schema is created automatically, and the Sales actual data table becomes available within it. From there, I can access the shared table directly in a Notebook.

Creating a Data Product in Databricks

To create a Data Product in Databricks, I first need to create a Share – which I can either do via the Delta Sharing settings in the Catalog:

Or directly out of the table which is going to become a part of the Share:

Since a single Share can contain multiple tables, I have the option to either add the table to an existing Share, or create a new one:

To publish the Share as a Data Product, I run a Python script where I define the target table for the forecast and describe the Share in CSN notation, setting the Primary Keys. Primary Keys are required for installing Data Products in Datasphere.

Jump back into Datasphere

Once the Databricks Data Product is available in Datasphere, I install it into a Space configured as a HANA Database space – since my intention is to build a view on top of the table and use it for planning in SAC.

There are two installation options: as a Remote table for live data access, or as a Replication Flow, in which case the data is physically copied into the object store in Datasphere.

Since I want live access, I install it as a Remote Table:

and build a Graphical view of type Fact on top:

Forecast calculation

With my Data Products set up and Sales actual data are available in Databricks, I create a Notebook to calculate the Sales Forecast.

The approach combines Sales and Weather data to train a Linear Regression model. I import the Weather data *https://zenodo.org/records/4770937 from an external server directly into Databricks, select the relevant features from the weather dataset, and combine them with the Sales actual data:

* Klein Tank, A.M.G. and Coauthors, 2002. Daily dataset of 20th-century surface
air temperature and precipitation series for the European Climate Assessment.
Int. J. of Climatol., 22, 1441-1453.
Data and metadata available at http://www.ecad.eu

Using the “sklearn” library, I build and train a Linear regression model:

Once trained, the model predicts the Sales forecast for Rome in June 2026 based on the weather forecast, and I save the results to my Catalog table:

Seamless planning data model

Seamless planning concept is built around physically storing planning data and public dimensions directly in Datasphere, keeping them alongside the actual data.

Since the QRC4 2025 SAC release, it has also been possible to use live versions and bring reference data into planning models without replication.

In this scenario, I build a seamless planning model on top of the Graphical view I created over the Remote table. This lets me use the forecast generated in Databricks as a reference for the final SAC Forecast version.

 

The model setup follows these steps:

Create a new model:

Start with data:

Select Datasphere as the data storage:

From there, I define the model structure and can review the data in the preview.

For a deeper dive into Seamless Planning, I recommend this biX blog.

Process Flow automation

Multi-action triggers Datasphere task chain

The final step is automating the entire forecast generation by using SAC Multi-actions and a Task-Chain in Datasphere – so that my user can trigger the calculation with a single button click from an SAC Story.

The model setup follows these steps:

Create a new model:

Triggering Task Chains from Multi-actions is a recent release. This blog post walks through how to set it up.

For details on how to trigger a Databricks Notebook from Datasphere, I recommend referring to this blog.

With everything in place, I create a Story, add my Seamless planning Model, and attach the Multi-action:

Running the Multi-action triggers the Task Chain, which in turn triggers the Databricks Notebook.

I can monitor the execution details in Datasphere:

and in Databricks:

Once the calculation completes, the updated forecast appears in the Story:

The end-to-end calculation took 2 minutes 45 seconds in total. The Task Chain in Datasphere is triggered almost instantly by the Multi-action, the Databricks Notebook execution itself took 1 minute 29 seconds, with the remaining time spent on Serverless Cluster startup.   

 

From here, I can copy the calculated forecast into a new private version:

adjust the numbers as needed, and publish it as a new public version to Datasphere:

Conclusion

With SAP Business Data Cloud, it is possible to build a forecasting workflow that feels seamless to the end user — even though it spans multiple systems under the hood.

Companies using BW as the main Data Warehouse and Databricks for ML calculations or Data Science tasks can benefit from using the platform, as the data no longer needs to be physically copied out of BW.

What this scenario demonstrates is that once wrapped as a Data Product, BW sales data can be shared with Databricks via the Delta Share protocol. Databricks, in turn, can then create its own Data Products on top of the calculation results and share them back with Datasphere as a Remote Table.

A Seamless Planning model in SAC sits on top of that Remote Table, giving planners live access to the generated forecast. A single Multi-action in an SAC Story ties it all together, triggering a Datasphere Task Chain that kicks off the Databricks Notebook — completing the full cycle in under three minutes.

As SAP Business Data Cloud continues to mature, scenarios like this one are becoming achievable – leaving the complexity in the architecture and not in the workflow.

Contact

Ilya Kirzner
Consultant
biX Consulting
Privacy overview

This website uses cookies so that we can provide you with the best possible user experience. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helps our team to understand which sections of the website are most interesting and useful to you.