Mai 2026
Data Products, Databricks und Seamless Planning
Prognosen sind immer nur so verlässlich wie ihre Datengrundlage. Doch genau hier stehen viele Unternehmen vor einer Herausforderung: Die passenden Daten zur richtigen Zeit am richtigen Ort bereitzustellen, ist oft extrem schwierig. Während die realen Verkaufsdaten im On-Premise-BW liegen, läuft das Machine Learning in Databricks und die eigentliche Planung in SAC. Um diese Welten zu vereinen, müssen Daten meist aufwendig zwischen Systemen hin- und her kopiert sowie komplexe Pipelines gepflegt werden.
Mit der SAP Business Data Cloud lassen sich vollständig integrierte Prognose-Workflows realisieren – ohne eine einzige überflüssige Datenkopie. In diesem Artikel zeige ich Ihnen genau das: ein durchgängiges End-to-End-Szenario, bei dem Planer eine KI-generierte Absatzprognose per Knopfdruck direkt in SAC auslösen und nahtlos damit weiterarbeiten können.
Das Business-Szenario dreht sich um die Absatzprognose für Speiseeis. Diese basiert auf den realen Verkaufszahlen aus dem BW sowie auf Wetterdaten eines externen Dienstleisters. Ein Machine-Learning-Modell in Databricks – trainiert mit historischen Absätzen und Wetterparametern – nutzt die Wettervorhersage für den kommenden Monat, um die genaue Absatzprognose zu berechnen.
Der Endnutzer arbeitet innerhalb einer SAC-Geschichte, startet die Prognoseberechnung mit einem einzigen Knopf und analysiert die Ergebnisse direkt.
Technisch gesehen verläuft das Szenario in fünf Schritten:
- Einrichtung von Datenprodukten: Verkaufsdaten in Datasphere, Verkaufsprognosen in Databricks.
- Modellierung in Datasphere.
- Berechnung der Verkaufsprognose in Databricks.
- Aufbau eines nahtlosen Planungsmodells in SAC.
- Automatisierung des Prozessablaufs mit Multi-Actions und Task Chains.
Die End-to-End-Architektur ist im folgenden Schema dargestellt:
Datasphere erfasst die realen Verkaufsdaten aus dem BW, stellt sie als Datenprodukt bereit und teilt sie mit Databricks. Dort werden sie mit historischen Wetterdaten eines externen Dienstleisters kombiniert, um den finalen Datensatz für das ML-Modelltraining zu erstellen. Auf Basis der aktuellen Wettervorhersage generiert das vortrainierte Modell schließlich die Absatzprognose, verpackt diese wiederum als Datenprodukt und spielt sie an Datasphere zurück.
Ein nahtloses Planungsmodell, das auf einer Datasphere-Ansicht aufsetzt, liest die prognostizierten Werte in Echtzeit aus. So können Planer direkt neue Planungsversionen erstellen und die erforderlichen Anpassungen vornehmen.
Schauen wir uns die Details genauer an.
Data Product-Aufbau
Der erste Schritt ist die Einrichtung der Data Products. Falls Sie mit diesem Konzept noch nicht vertraut sind, bietet dieses aktuelle Video einen idealen Einstieg. iHier ist jedoch schon einmal eine kurze Zusammenfassung: Ein Datenprodukt ist eine klar definierte, leicht auffindbare und direkt nutzbare Sammlung von Datensätzen.
Zu den Artefakten können Stammdaten-, Text- und Hierarchietabellen oder transaktionale Datensätze gehören. Datenprodukte ermöglichen den Datenaustausch zwischen Anwendungen über das Delta-Sharing-Protokoll, was bedeutet, dass die Daten von einem Objektspeicher auf einen anderen referenziert werden, anstatt physisch kopiert zu werden.
Erstellung eines Datenprodukts in der Datasphere
Wichtiger Hinweis: Für diesen Artikel erstelle ich die Datenprodukte im Data Sharing Cockpit von Datasphere. Diese Funktionalität soll künftig in das Data Product Studio integriert werden, war jedoch zum Zeitpunkt der Texterstellung dort noch nicht verfügbar.
Bevor ein Data Product in Datasphere erstellt werden kann, muss ein Data-Provider-Profil eingerichtet werden. Darin werden beschreibende Metadaten wie Kontakt- und Adressdaten, Branche, regionale Abdeckung und vor allem die Sichtbarkeit des Datenprodukts hinterlegt. Durch das Aktivieren von „Formations“ lässt sich das Data Product anschließend mit Systemen innerhalb der eigenen BDC-Formation teilen – in diesem Fall mit Databricks.
Nachdem der Datenanbieter eingerichtet ist, kann das Data Product erstellt werden. Ähnlich wie beim Data Provider müssen auch hier Produktmetadaten hinzugefügt und die Artefakte – also die enthaltenen Datensätze – definiert werden. Dabei können ausschließlich Datensätze aus einem Space vom Typ „SAP HANA Data Lake Files“ ausgewählt werden. Da dieses Data Product innerhalb der gesamten Formation sichtbar ist, steht es kostenlos zur Verfügung.
Für diese Demo dient eine lokale Tabelle mit den Speiseeis-Verkaufsdaten der letzten zehn Jahre als Artefakt. Da es sich hierbei um einen Space vom Typ „Files“ handelt, ist es nicht möglich, eine CSV-Datei direkt für die Erstellung einer lokalen Tabelle zu importieren (siehe Dokumentation).
Ich habe einen Replication Flow verwendet, um eine erste Ladung von einer BW-aDSO-Tabelle in eine lokale Tabelle durchzuführen.
Sobald das Data Product erstellt und gelistet ist, ist es im Katalog und Marktplatz verfügbar, von wo aus es durch Auswahl der entsprechenden Verbindungsdetails mit Databricks geteilt werden kann.
Steig in Databricks ein
Um das geteilte Objekt in Databricks zu verwenden, muss ich es in den Katalog einbinden – entweder indem ich einen neuen Katalog erstelle oder einen bestehenden verwende.
Databricks fügt am Ende des Schemas eine Versionsnummer an – ‚:v1‘ – hinzu, um die Versionsführung im Falle zukünftiger Änderungen am Data Product aufrechtzuerhalten.
Sobald das Share gekoppelt ist, wird das Schema automatisch erstellt und die tatsächliche Sales-Datentabelle wird darin verfügbar. Von dort aus kann ich direkt in einem Notizbuch auf die geteilte Tabelle zugreifen.
Erstellung eines Data Products in Databricks
Um ein Data Product in Databricks zu erstellen, muss ich zuerst ein Share erstellen – was ich entweder über die Delta Sharing-Einstellungen im Katalog machen kann:
Oder direkt aus der Tabelle, die Teil des Share wird:
Da ein einzelner Share mehrere Tabellen enthalten kann, habe ich die Möglichkeit, die Tabelle entweder zu einer bestehenden Share hinzuzufügen oder eine neue zu erstellen:
Um Share as a Data Product zu veröffentlichen, führe ich ein Python-Skript aus, bei dem ich die Zieltabelle für die Prognose definiere und die Share in CSN-Notation beschreibe, wobei ich die Primärschlüssel setze. Primärschlüssel sind für die Installation von Data Products in Datasphere erforderlich.
Springen Sie zurück in Datasphere
Sobald das Databricks Data Product in Datasphere verfügbar ist, installiere ich es in einem als HANA-Datenbankbereich konfigurierten Space – da mein Ziel ist, eine Ansicht auf der Tabelle zu erstellen und sie für die Planung in SAC zu verwenden.
Es gibt zwei Installationsoptionen: als Remote-Tabelle für den Live-Datenzugriff oder als Replication Flow, wobei die Daten physisch in den Objektspeicher in Datasphere kopiert werden.
Da ein Live-Zugriff gewünscht ist, binde ich die Tabelle als Remote Table ein:
Und setze darauf eine grafische Ansicht vom Typ Fact auf:
Prognoseberechnung
Sobald die Data Products eingerichtet und die realen Verkaufsdaten in Databricks verfügbar sind, erstelle ich ein Notebook, um die Absatzprognose zu berechnen.
Der Ansatz kombiniert Verkaufs- und Wetterdaten, um ein lineares Regressionsmodell zu trainieren. Dafür importiere ich die Wetterdaten *https://zenodo.org/records/4770937 direkt von einem externen Server nach Databricks, wähle die relevanten Features aus dem Wetterdatensatz aus und führe sie mit den realen Verkaufsdaten zusammen:
Klein Tank, A.M.G. und Co-Autoren, 2002. Täglicher Datensatz der Oberflächentemperatur- und Niederschlagsserien des 20. Jahrhunderts für das europäische Klima Assessment. Int. J. of Climatol., 22, 1441-1453. Daten und Metadaten verfügbar unter http://www.ecad.eu
Mithilfe der „scikit-learn“-Bibliothek (sklearn) erstelle und trainiere ich das lineare Regressionsmodell:
Nach dem Training berechnet das Modell die Absatzprognose für Rom im Juni 2026 auf Basis der Wettervorhersage. Die Ergebnisse speichere ich anschließend in meiner Katalogtabelle:
Die Umsatzprognose wird dann sofort als Remote-Tabelle in Datasphere angezeigt:
Nahtloses Planungsdatenmodell
Das Konzept der nahtlosen Planung speichert Planungsdaten und öffentliche Dimensionen physisch direkt in Datasphere neben den Ist-Daten.
Seit dem SAC-Release QRC4 2025 können Live-Versionen genutzt und Referenzdaten ohne Replikation eingebunden werden, was die Verwendung von in Databricks generierten Prognosen als Basis für die finale SAC-Planungsversion in einer grafischen Ansicht ermöglicht.
In diesem Szenario setze ich ein nahtloses Planungsmodell auf der grafischen Ansicht auf, die ich über der Remote-Tabelle erstellt habe. Dadurch kann ich die in Databricks generierte Prognose als Referenz für die finale SAC-Prognoseversion nutzen.
Der Modellaufbau erfolgt in folgenden Schritten:
Erstellen Sie ein neues Modell:
Beginnen Sie mit Daten:
Wählen Sie Datasphere als Datenspeicher aus:
Anschließend definiere ich die Modellstruktur und kann die Daten in der Vorschau überprüfen.
Für einen tieferen Einblick in Seamless Planning empfehle ich diesen BiX-Blog.
Prozessflussautomatisierung
Multi-Action löst Datasphere-Task-Chain aus
Der letzte Schritt ist die Automatisierung der gesamten Prognoseerstellung über SAC Multi-Actions und eine Task-Chain in Datasphere. So können Anwender die Berechnung mit nur einem Klick direkt aus einer SAC Story heraus auslösen.
Der Modellaufbau folgt folgenden Schritten:
Erstellen Sie ein neues Modell:
Das Auslösen von Task-Chains über Multi-Actions ist ein brandneues Feature. Wie genau Sie das einrichten, wird in diesem Blogbeitrag Schritt für Schritt erklärt.
Für detaillierte Informationen darüber, wie sich ein Databricks Notebook direkt aus Datasphere heraus triggern lässt, empfehle ich Ihnen diesen Blogartikel.
Sobald alles eingerichtet ist, erstelle ich eine Story, füge mein nahtloses Planungsmodell hinzu und binde die Multi-Action ein:
Das Ausführen der Multiaktion löst die Task Chain aus, die wiederum das Databricks Notebook auslöst.
Ich kann die Ausführungsdetails in Datasphere überwachen:
und in Databricks:
Sobald die Berechnung abgeschlossen ist, erscheint die aktualisierte Prognose in der Story:
Die End-to-End-Berechnung dauerte insgesamt 2 Minuten und 45 Sekunden. Während die Task-Chain in Datasphere durch die Multi-Action nahezu verzögerungsfrei ausgelöst wird, nahm die eigentliche Ausführung des Databricks-Notebooks 1 Minute und 29 Sekunden in Anspruch. Die restliche Zeit entfällt auf den Start des Serverless-Clusters.
Von hier aus kann ich die berechnete Prognose in eine neue private Version kopieren:
die Nummern nach Bedarf anpassen und es als neue öffentliche Version in Datasphere veröffentlichen:
