Databricks und Planung oder einfache Eingabe

Juli 2025

Motivation

Databricks hat sich zu einer wichtigen Datenplattform für Unternehmen entwickelt. Diese Plattform wird durch die Ankündigung der Zusammenarbeit von SAP mit Databricks gestärkt. 

Dank der guten KI-Möglichkeiten in Databricks kann man sich viele Daten z.B. für eine Planung vorschlagen lassen.  

Doch, was macht man, wenn man feststellt, dass einzelne Daten fehlen, die man nicht aus einer vorhanden Datenquelle generiert oder manuell korrigieren muss? Welche Möglichkeiten hat man dazu in Databricks? 

In dieser Blog-Serie möchten wir genau diese Möglichkeiten für eine Planung in Databricks untersuchen und darstellen, was möglich ist. 

Dazu fangen wir in diesem ersten Blog mit der Frage an, was Planung eigentlich ist, bzw. was genau die technischen Anforderungen für eine Erfassung von Zahlen sind. Die möglichen Szenarien beginnen bei einer einfachen Dateneingabe und reichen bis hin zur komplexen Planungsanwendung. 

Nicht jedes Anwendungsszenario benötigt alle Anforderungen. Daher hilft die erste Analyse bei der Überprüfung des eigenen konkreten Anwendungsfalls. 

In den folgenden Blogs werden wir beschreiben, wie und welche der Anforderungen wir davon schon in Databricks umsetzen konnten. 

Was ist Planung?

Wenn wir untersuchen wollen, ob eine Planung mit Databricks möglich ist, müssen wir zunächst definieren, was Planung ist, bzw. welche Anforderungen für eine Planung an das Tool zu stellen sind. Dabei werden wir feststellen, dass es nicht den einen Planungsprozess gibt und, je nach fachlicher Anforderung, unterschiedliche technische Anforderungen nötig sind. Wir werden dann einzelne Punkte analysieren und unsere Ergebnisse in den folgenden Blogs beschreiben. 

Hier ein paar Beispiele von Funktionen, die für verschieden Anforderungen an eine Planung nötig sind.  

Einfache Erfassung von Daten

Beginnen wir mit der Erfassung von Daten, auch wenn dies eigentlich keine richtige Planung ist, sondern eher als „Eingabemaske“ zu bezeichnen ist. Die Erfassung von Texten und Zahlen, die nicht aus einer vorhandenen Quelle kommen, sind schon erste einfache Varianten einer Planung. Dies kann z.B. schon für einfache Steuerungen in der Beladung von Daten verwendet werden. 

Kombinieren von Anzeige- und Erfassungsspalten

Die Erfassung von Planzahlen neben vorhandenen Ist-Zahlen kommt dem Begriff der Planung schon näher, z.B. wenn die Verkaufszahlen für verschiedene Produkte des vergangenen Jahres vorliegen und die Zahlen für das folgende Jahr geplant werden sollen. Hierfür müssen vorhandene Daten in eine tabelle angezeigt und in einer zusätzlichen Spalte Planzahlen erfasst werden. Dabei ist sicherzustellen, dass der Planer nur in der Planspalte die zahlen erfasst und die anderen Spalten nicht ändern kann. Im Beispiel in Abblidung 1 sind die zu ändernden Zellen farblich hervorgehoben und eindeutig zu erkennen.

Abbildung 1: Beispiel einer einfachen Budgetplanung von Produkten in der SAC mit folgenden Funktionen 

1: Kopieren von Ist-Zahlen
2: Erfassung auf einem Hierarchie-Knoten und Verteilung auf Produkte
3: Einfügen einer neuen Zeile, die noch nicht in den Ist-Daten existiert

Verteilung von Planzahlen bei Erfassung von aggregierter Ebene

In großen Planungen werden die Werte häufig auf sehr detaillierter Ebene benötigt (z.B. Produkt, Monat), aber die eigentliche Erfassung erfolgt auf einer viel höhere Ebene (z.B. Jahr und Produktgruppe). Eine initiale Verteilung soll nach bestimmten Regeln erfolgen, z.B. analog vorhandener Ist-Daten und, wenn diese fehlen, gleichverteilt. Diese initiale Verteilung kann dann von einem Planer angepasst werden. (s. Abb. 1 – Punkt 1) 

Neben der reinen Verteilungsfunktionalität stellt sich hier schnell die Frage, was manuell erfasst werden und was von einer KI vorgeschlagen werden soll. Aber auch ein KI-Vorschlag sollte sicher (noch) ein Mensch überarbeiten, da die KI evtl. nicht alle Rahmenbedingungen berücksichtigt (z.B. geplante Neuerscheinungen, neue Geschäfte, …). Auch bei der Überarbeitung der KI-erzeugten Daten wird solch eine Verteilungsfunktion benötigt. 

Stammdaten in der Planung und neue Zeilen

Sollen in einer Planung neue Kombinationen / Zeilen erfasst werden, ist für eine konsistente Planung entscheidend, dass nur gültige Stammdaten verwendet werden. Es ist wichtig, dass bei der Erfassung neuer Zeilen eine Verprobung gegen die Stammdatentabellen möglich ist. Diese kann auch als Eingabehilfe verwendet werden. So vermeidet man Schreibfehler in der Planung, die die Qualität der Planung reduzieren. 

Diese Stammdatentabellen können dann auch weitere Merkmale enthalten, nach denen das Reporting bzw. die Planung zusammengefasst werden können, z.B. Produktgruppen als Eigenschaften der Produkte. 

In einigen Fällen ist es nötig, während der Planung neue Stammdaten anzulegen. Hier ist sicherzustellen, dass diese konsistent angelegt werden und zu den späteren Ist-Zahlen zugeordnet werden können. 

Audit-Merkmale und Eingaben rückgängig machen

Häufig soll in einer Planung nachvollziehbar sein, wer welche Zahlen wann und wie geändert hat. Dazu sind die Änderungen mit User und Zeitstempel zu hinterlegen. Dies setzt voraus, dass alle Änderungen nur als Delta gespeichert werden (s. Tabelle 1). 

Wenn Daten so gespeichert werden, ist es möglich, eine Funktion zu implementieren, die Datenänderungen rückgängig macht. 

Tabelle 1: Delta – Erfassung mit Zeitstempel 

Parallele Planung / Eingaben von mehreren Anwendern 

Bei größeren Planungsanlässen werden sicher mehrere Anwender gleichzeitig Daten erfassen wollen. Damit diese nicht die Zahlen des jeweils anderen löschen, kann man mit folgenden einfachen Prüfungen arbeiten (s. Abb. 2.): 

  • Gar keine Prüfung, alles speichern 
    Werden die Daten nur selten oder von einem User geändert, sind sicher keine Einschränkungen nötig. Je häufiger mehrere Anwender Zahlen erfassen, desto höher ist die Wahrscheinlichkeit, dass sie gegenseitig Zahlen überschreiben. Werden immer alle angezeigten Daten beim Sichern weggeschrieben, überschreibt ein User 1 dabei Zahlen, die er eigentlich gar nicht geändert hat mit seinen alten Werten, die User 2 inzwischen geändert hat. Je länger er mit der Erfassung beschäftigt sind, desto größer dieses Risiko. 
  • Nur geänderte Daten speichern, sonst keine Prüfung 
    Um das Risiko des versehentlichen Überschreibens zu reduzieren, hilft es schon, nur die geänderten Daten zu sichern, evtl. sogar mit einem Zeitstempel. Dann können mehrere User an unterschiedlichen Werten gleichzeitig Änderungen vornehmen. Außerdem kann man Änderungen nachverfolgen (s. Abb. 2). Hier gewinnt dann immer der Letzte, der die Zahlen ändert. 
  • Warnung, wenn Zahlen gleichzeitig geändert werden 
    Als gleichzeitig gilt, wenn die Änderung zwischen dem Lesen der Werte in den Cache der einzelnen User und dem Sichern erfolgt (s. Abb. 3). Hier muss entschieden werden, wie zu verfahren ist. Andernfalls kann es passieren, falls nur das Delta der Änderung gespeichert wird, dass der Endwert nicht der Wert eines Users ist, sondern die Summe aller Änderungen. 
  • Sperren 
    Der sicherste, aber aufwendigste Ansatz ist, die Werte zu sperren, sobald ein Anwender einen bestimmten Bereich zur Planung öffnet. Dann erhalten andere Anwender eine Warnung, dass die Planzahlen und die Daten für die Änderung derzeit durch einen User gesperrt sind. Von diesem klassischen löst man sich aber in modernen Anwendungen. Sperren erhöhen den Implementierungsaufwand und werden manchmal gelöscht, wenn die Anwendung nicht korrekt beendet wird. Dadurch kommt es immer wieder zu fehlerhaften Sperrmeldungen, die den Planungsprozess behindern. In der älteren Planung von SAP im BW (SAP BPC) erfolgt die Planung mit einem Sperrkonzept. In der neueren Planung in SAC hat SAP auf die Sperren verzichtet. Auch bei Microsoft sperrt man inzwischen ein Dokument auf einem zentralen Laufwerk nicht mehr exklusiv, wenn es geändert wird. 

Abbildung 2: Parallele Planung – User 1 und User 2 können ohne Sperre gleichzeitig unterschiedliche Werte ändern und sichern. Beide Änderungen werden berücksichtigt. 

Abbildung 3: Parallele Planung – User 1 und User 2 wollen gleichzeitig den selben Wert ändern. Hier muss geklärt werden, wie der Konflikt gelöst wird. 

Administration und Steuerung der Planung

Eine Planung muss gesteuert werden. Bei regelmäßigen Planungen, z.B. einem Forecast, muss ein Administrator festlegen, welches der aktuelle erste Planmonat für diese Runde sein soll. Alle Layouts sollten sich dann entsprechend anpassen. 

Außerdem muss eine Planung geöffnet und geschlossen werden können. Nach Planungsende sollen die Zahlen nicht mehr verändert werden, bzw. die Zahlen sollen nach einer Prüfung nur für bestimmte Länder gesperrt werden. Andere Länder müssen evtl. noch nacharbeiten. 

Versionierung

Während einer Planung können unterschiedliche Versionen nötig sein. Z.B. beginnt die Budgetplanung mit einer ersten Planung durch die Fachbereiche. Im anschluss wird das gesamtergebnis geprüft, bestimmte Bereiche müssen dann ihre Planung anpassen. Alternativ kann ein optimistisches und ein pessimistisches Szenario erfasst werden. All dies ist in unterschiedlichen Versionen festzuhalten. Diest ist durch ein geeignetes versionskonzept zu unterstützen.

Funktionen für die Initialisierung / Planungsvorbereitung

Planungen beginnen häuftig nicht mit einem leeren Blatt, sondern werden initial aus den Ist-Daten mit einer einfachen %-Anpassung erstellt. Für diese Planungsvorbereitung sind diverse Funktionen, beispielsweise Kopierfunktionen, nötig (s. Abb. 1 – Punkt 2). Eventuell kann dies bereits auch schon mit einem KI-Tool über die einfachen Vorgaben hinaus verbessert werden.

Überblick der Funktionaltitäten

Hier geben wir über alle vorgestellten Funktionalitäten einen Überblick: 

Tabelle 2: Überblick der Funktionalitäten

Weiteres Vorgehen

Wie beschrieben, sind für eine Planung unterschiedlichste Anforderungen nötig, wobei nicht für jede Planungsanwendung alle Anforderungen nötig sind. 

Daher werden wir die Anforderungen getrennt analysieren und prüfen, was sich mit welchem Aufwand in Databricks umsetzen lässt. Unsere Ergebnisse werden wir in den nächsten Blogs veröffentlichen.  

Wir sind ebenso gespannt wie Sie, wie weit mir bei diesen Anforderungen mit Databricks kommen. 

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.

Ansprech­partner

Ilya Kirzner
Consultant
biX Consulting
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.