Planungscontent in der SAP Analytics Cloud (SAC)

am Beispiel einer Story im Paket „integrated Financial Planning (4RC)“

Ein von der SAP gerne als großen Vorteil vermarktetes Argument für die Planung in der SAC ist der Planungscontent. Dieser verspricht eine Vorlage für die „klassischen“ Planungsprozesse in den meisten Unternehmen zu sein. Diese braucht man nur zu aktivieren und kann dann sofort mit der Unternehmensplanung beginnen oder zumindest mit geringem Aufwand für die Anpassung an das eigene Unternehmen. Endlich steht ein solcher Content auch für die SAC zur Verfügung.

Mit diesem Blog möchte ich meine ersten Eindrücke teilen und zeigen, was ich gut finden und wo ich noch Anpassungs- / Erweiterungsbedarf vermute. Doch alles der Reihe nach.

Paket “Integrated Financial Planning (‏4RC‏)”

Um zu sehen, ob der Content von SAP die Erwartungen erfüllen kann, habe ich mir das Paket Integrated Financial Planning (‏4RC‏) angeschaut, das den „klassischen“ Prozess der integrierten Finanzplanung bedient.

Den Leitfaden zur Einführung und Testen beschreibt SAP in ihrem „Best Practices Explorer“, die Hilfe findet man in den Hilfeseiten. Hier ist immer nach dem neuesten Release zu schauen, da sich auch die Dokumentation kontinuierlich verbessert!

https://rapid.sap.com/bp/#/browse/categories/sap_s%254hana/areas/cloud/packageversions/BP_CLD_ENTPR/S4CLD/2011/US/22/EN/scopeitems/4RC

https://help.sap.com/viewer/1cbcff7ccd35405ab445b223c1ab1588/2011.500/en-US/a2b35263477b4895a301a8d544dea775.html

https://help.sap.com/viewer/1cbcff7ccd35405ab445b223c1ab1588/2102.500/en-US/c27e528a759346c89e27fec93b037cc9.html

Natürlich bin ich nicht der Erste, der zu diesem Thema ein Blog schreibt:

https://blogs.sap.com/2020/12/01/financial-planning-options-in-s-4hana-2020-release/

https://blogs.sap.com/2021/02/12/simulation-cockpit-for-financial-planning-in-sap-analytics-cloud/

Der Datenfluss, den SAP zu diesem Modell zeigt, enthält eigentlich alles, was im klassischen Budgetprozess so ansteht:

Abbildung 1 Quelle SAP: https://support.sap.com/content/dam/SAAP/Sol_Pack/Library/ProcessDiagrams/4RC_S4CLD2102_Process_Overview_EN_XX.htm

Installation des Planungscontents

Der Planungscontent ist schnell in den eigenen Tenant importiert. Auch Beispieldaten werden zur Verfügung gestellt. Damit kann man sofort mit dem Testen beginnen! Dies ist vorbildlich!

Story „SAP Finance BPL – Sales Planning“ [SAP__FI_BPL_IM_PROFITABILITY_REV_INPUT]

Da ich in meinen letzten Projekten schon einige Vertriebsplanungen bei Kunden implementiert habe, war mein erster Griff zu der Story für die Vertriebsplanung – reine Erlössicht (rot umrandeter Bereich im Datenfluss oben).

Diese Story ist fast identisch mit der Story „SAP Finance BPL – Sales & Profitability Planning“ [SAP__FI_BPL_IM_PROFITABILITY_PROF_INPUT]. In dieser Story wird neben der Erlössicht auch die Kostenseite berechnet und am Ende steht die komplette P&L je Kunde / Produkt. Daher bitte aufpassen, welche Story man öffnet!

Irgendwie habe ich nirgends eine Beschreibung gefunden, wie diese Planung denn bedient werden soll (oder habe ich dies irgendwo in den Tiefen das SAP – Net übersehen?). Daher hier erst einmal eine Zusammenfassung, wie ich mir den Umgang mit dieser Story vorstelle.

Folgende Tabs gibt es in dieser Story:

Quantity & Revenue
Quantity Parameter Setting
Price
Sales Deductions %
Sales Deductions

Wie soll hier geplant werden

Die Erfassung erfolgt zwar in der Reihenfolge der einzelnen Tabs aus der Story. Aber nicht immer sollte man sofort alle Funktionen und Eingaben nutzen, die zur Verfügung stehen! Diese Reihenfolge erschien mir bei der Erfassung der Planzahlen sinnvoll:

Vorschlag der Mengen und Preise aus dem Ist übernehmen (über eine Funktion auf dem ersten Tab)
Anpassung der Mengen im ersten Tab. Der Umsatz kann mit den alten Preisen über eine Funktion schon einmal berechnet werden.
Unterstützung der Mengenplanung über die Funktionen im Tab 2, die eine Verteilung der Planwerte über verschiedene Parameter erlaubt.
Anpassung der Preise je Produkt im Tab 3
Erfassung der Rabatte je Kunde im Tab 4
Berechnung des Umsatzes inkl. Rabatte je Kunde über die Funktion auf Tab 1 oder Tab 5.
Zum Schluss kann je Kunde / Produkt der Umsatz und absolute Rabatt evtl. noch einmal korrigiert werden.

Und nun noch einmal alle Tabs im Detail der Reihe nach.

Tab 1 – Quantity & Revenue

Im Tab 1 kann man die Mengen und den Umsatz erfassen. Mit dem Button „Quantites – Actual based“ werden erst die vorhandenen Planzahlen inkl. Preise und Rabatte gelöscht und dann die Ist Zahlen monatsgenau aus dem Planjahr – 1 übernommen. Die Durchschnittspreise aus dem Planjahr – 1 werden berechnet. Ebenso werden Rabatte aus dem Planjahr – 1 übernommen.

Der geplante Umsatz wird anhand der Preise und der Mengen berechnet, wenn man den Button „Profitability – Calculate“ drückt.

Nun können Mengen noch manuell angepasst werden. Mit einer Anpassung der Umsätze sollte man warten, bis man die übernommenen Planpreise aktualisiert hat (im Tab 3)! Diese werden immer wieder neu berechnet, wenn der Button „Profitability – Calculate“ gedrückt wird.

Eine Vorbelegung aus dem Ist hilft in der Planung. Aber sicher wird nicht für jede Planperiode eine Vorjahresperiode gefüllt sein. Hier ist sicher eine kundenindividuelle Anpassung nötig.

Neue Kunden / Materialkombinationen können über das Kontextmenü auf einem Merkmal hinzugefügt werden.

Dann in der neuen Zeile alle Merkmale entsprechend ausfüllen.

Beim Konto ist ein Einzelkonto zu wählen. Die Eingabe der Menge wird nun mit einer Fehlermeldung quittiert. Man muss zuerst einen Umsatz eingeben und ihn übertragen. Nun kann man eine Menge erfassen und den Umsatz aus dem Preis berechnen lassen. Aber Achtung, nach der Erfassung der Menge wird automatisch nicht mehr das Konto angezeigt, sondern nur der Hierarchieknoten für die Konten. Wenn man nun auf dem Knoten die Menge erfasst, wird auf alle darunterliegenden Konten verteilt, nicht nur auf das Konto, auf das man den ersten Betrag erfasst hat.

Zu beachten ist, dass Mengen ohne Nachkommastellen angezeigt werden, aber bei der Umsatzberechnung sehr wohl mit Nachkommastellen der Mengen gerechnet wird! Dies fällt insbesondere auf, wenn man die Monate aufklappt oder über mehrere Unterkonten verteilt.

Tab 2 – „Quantity Parameter Setting“

Über Steuerparameter kann man für eine Material Produkt Kombination sich flexibel die Planzahlen vorschlagen lassen. Im Prinzip ist dies eine gute Idee, da für jeden Monat unterschiedliche Regeln angewendet werden können.

Da die Steuerparameter an mehreren Stellen vorkommen und nur bedingt selbsterklärend sind, hier die Beschreibung der dahinterliegenden Funktionen. Das Verhalten habe ich mir aus der verwendeten Planungsfunktion abgeleitet. Nach der Übersicht werde ich dies an einem Beispiel im Detail zeigen.

Bedeutung der Steuerparameter:

Nr.	Beschreibung	Bedeutung
1	Rolling Average (Plan)	Neuer Planwert ist der Durchschnitt der letzten drei Monate, allerdings nur der Planwert, Ist – Monate werden mit 0 berücksichtigt! Der erste Monat wird nicht geändert. Also wird im zweiten Plan – Monat 1/3 des Planwertes des ersten Monats verwendet, wenn nicht noch alte Planzahlen vorhanden sind!
2	Previous Month (Plan)	Planwert des Vormonats. In der ersten Planperiode wird nichts geändert
3	Growth Rate (Plan)	Hier wird die Prozentuale Steigerung zwischen den Planwerten der beiden Vormonate fortgeschrieben. Damit macht dieser Parameter erst ab dem 3. Planmonat Sinn. Beispiel Januar 100, Februar 110: Basis für März = 110 / 100 * 110 = 121,0
6	Previous year (Actuals)	Der Ist-Wert vor genau 12 Monate wird verwendet. Dies ist identisch zum Verhalten aus der Funktion auf dem ersten Tab.
7	Rolling Average (Actuals)	Hier wird der Durchschnitt der letzten 3 Monate aus den Ist-Zahlen verwendet. Dieser Parameter macht nur Sinn, wenn man eine rollierende Planung Monat für Monat fortschreibt. Ansonsten sind schon ab der zweiten Planperiode nur Ist-Zahlen aus den letzten 2 Ist-Perioden verfügbar.
8	Previous Month (Actuals)	Ist aus dem Vormonat – auch nur sinnvoll, wenn man rollierend Monat für Monat fortschreibt.
9	Growth Rate (Actuals)	Wie bei der Growth Rate (Plan) wird die prozentuale Steigerung der letzten beiden Ist – Werte fortgeschrieben. Damit ist dies auch nur sinnvoll, wenn schon entsprechende Ist-Werte für die letzten Monate vorliegen.
–	Account specific growth rate	Unabhängig zu diesen Formeln kann man für jeden Monat noch eine prozentuale Steigerung in dieser Zeile eintragen, die dann zusätzlich berücksichtigt wird.
–	Base Value	In dieser Zeile wird der Wert eingetragen, auf die „Account specific growth rate“ angewendet wird. Dieser Wert ist eine Hilfsgröße und wird bei jeder neuen Berechnung überschrieben.

Insgesamt steht damit eigentlich ein flexibles Konstrukt zur Verfügung, um Planzahlen zu berechnen. Leider ist die Performance der Berechnung auch für ein Produkt – Material nicht besonders schnell. Dadurch werden Eingabe und Berechnung mühsam. Eine Wiederverwendung der Parameter für mehrere Produkte / Kunden Kombinationen scheint nicht möglich, somit muss jede Kombination einzeln erfasst werden.

Eine Funktion zur Wiederverwendung bereits gesetzter Parameter zur automatischen Übernahme auf verschiedene Produkt / Kunden wird sicherlich im Kundenprojekt hier nötig sein, um die Erfassung effizient und komfortabel zu gestalten.

Hier noch einmal das Verhalten im Detail für einen Parameter.

Beispiel: 2 – Previous Month (Plan)

Alle Parameter sind in der Datenaktion SAP__FI_BPL_IM_PROFITABILITY_CREATE_CTL_PARAMS umgesetzt. In der graphischen Darstellung dieser Funktion kann man für den entsprechenden Fall gut die Berechnung nachvollziehen:

Es wird einfach der Vormonatswert verwendet. Da die gleiche Version genutzt wird, wird auch immer nur der Planwert genutzt. Auf diesen wird dann zusätzlich die Steigerungsrate angewendet. Damit ergibt sich dann folgendes Bild:

Tab 3 – Price Adjustments

Hier können wir die Preise anpassen oder erfassen, die in Tab 1 und 5 verwendet werden, um den Umsatz aus den Mengen zu berechnen.

Um Preise für unterschiedliche Regionen zu definieren, muss man mit den Konten spielen! Die Umsatzmengen kann ich auf unterschiedlichen Konten erfassen, anhand dieser wird dann der Preis gezogen. In den Beispieldaten gibt es dann Preise für „Domestic-Product“ und „Foreign-Product“. Da dieser Preis unterschiedlich für ein Produkt gepflegt werden kann, bezieht sich diese Kontobezeichnung vermutlich auf den Verkauf im Produktionsland oder außerhalb. Hier ist zu prüfen, ob dies zu dem eigenen Kontenmodell passt.

Eine häufige Forderung in der Vertriebs – Planung ist, die Umsätze und Preise immer in der Transaktionswährung zu planen, um den Effekt von Währungsschwankungen später leichter auszurechnen. Da hier nur vorgesehen ist, die Planung in der lokalen Währung des Buchungskreises zu erfassen, muss dies ggf. erweitert werden.

Tab 4 – Sales Deductions Percentage

Da die Preise je Produkt gepflegt werden, sind kundenindividuelle Preisanpassungen über Preisnachlässe zu pflegen. Hier kann man sogar unterschiedliche Kategorien bedienen. Diese werden aus den Ist–Daten berechnet und vorgeschlagen bei der entsprechenden Funktion in Tab 1.

Trickreicher wird es, wenn man Rabatte z.B. für mehrere Kunden auf einmal pflegen will. Man kann zwar in der Anzeige die Reihenfolge von Konto und Kunde ändern und sich die Summen über die Kunden anzeigen lassen. Dann ist der Rabatt aber eine wirkliche Summe und nicht der Durchschnitt. Aber immerhin kann man dann z.B. in einem Monat den vorhandenen Rabatt verdoppeln oder über die Massendateneingabe mit einem bestimmten Wert füllen.

Will man Preise individuell für eine Produkt / Kunde Kombination anpassen und sollen diese Werte bei der nächsten Umsatzberechnung nicht überschrieben werden, wird man auch das entsprechend erweitern müssen.

Tab 5 – Sales Deductions

Auf diesem Tab werden dann die Umsatzerlöse je Kunde / Material inklusive Rabatte berechnet, wenn man den Button „Profitability – Calculate“ drückt. In dieser Story werden zwar nur die Umsatzerlöse angezeigt, aber mit der Formel werden auch die Produktkosten aktualisiert, man in der Story Sales & Profitability Planning [SAP__FI_BPL_IM_PROFITABILITY_PROF_INPUT] pflegen kann! Wenn dies von unterschiedlichen Usern durchgeführt werden soll, dann sollte man diese Berechnungen trennen.

Auch hier können alle Werte noch manuell angepasst werden. Aber Achtung, diese Änderungen werden wieder überschrieben, wenn die Funktion „Profitability – Calculate“ erneut ausgeführt wird. Daher ist es sinnvoller die Werte über Preise / Mengen / Rabatte zu korrigieren.

Fazit

Diese Story ist ein schönes Beispiel für die Vertriebsplanung an einem kleinen Testbeispiel. Die Planung einer größeren Anzahl Kunden / Produkte ist damit vermutlich nicht effektiv durchzuführen. Hierfür muss das Layout noch angepasst werden, z.b. mit einer Gruppierung je Kunde oder einem zusätzlichen Layout mit Einstieg über ein Produkt.

Autor:

Dr. Ulrich Meseth
Senior Consultant
biX Consulting GmbH & Co. KG

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.