Noch nicht auf BW/4 – Was tun? – Überlegungen und Erfahrungen unserer Kunden

In Kundengesprächen stellt sich oft die Frage, wie mit einem BW 7.5 und kleiner zu verfahren ist. Wann sollte die Migration auf ein BW/4 durchgeführt werden oder sollte gar ein ganz neuer Weg einschlagen werden? Deshalb möchten wir einige Aspekte zusammentragen, die bei der Entscheidung unterstützen können. 

Folgende Aspekte werden wir betrachten: 

  • Richtlinien für die Neu-Entwicklung im BW 7.5 on HANA
    Wie sollen neue BW-Projekte umgesetzt werden: Lohnt sich schon jetzt die Verwendung der neuen Objekte (aDSO, Composite) oder sogar von AMDPs für die Entwicklung komplexer Transformationen?
  • Planung in Drittanbieter-Tools
    Tools von Drittanbietern haben den Schrecken verloren. Die ersten Tools sind heute schon erfolgreich im Einsatz. Wieso werden diese Tools nicht auch für die Planung genutzt, die im BW/4 zusätlich lizensiert werden muss?
  • Weiterhin SAP-BW oder doch ein ganz anderes Tool?
    Der Aufwand für die Migration auf ein BW/4 ist sehr hoch. Wieso dann nicht auf ein anderes Tool wechseln?
  • Wieso wechseln auf BW/4 HANA?

Richtlinien für die Neu-Entwicklung im BW 7.5 on HANA

Sobald Ihr BW-Release auf BW 7.5 on HANA angekommen ist, stellt sich die Frage, welche neuen Techniken verwendet werden sollen. Auf diesem Stand bestehen die „alte“ und die „neue“ Welt mit Multicubes und Composite Providern gleichberechtigt nebeneinander. In beiden Welten kann entwickelt werden. Erst bei einer Migration auf BW/4 muss zwingend eine Migration aller alten Datenmodelle erfolgen. 

Heute sind die Funktionalität ebenso wie die Stabilität der neuen Datenmodelle (Composite / aDSO etc.) so ausgereift, dass sich die Frage nicht mehr stellt, in welchem Modell entwickelt werden sollte. Alle neuen Projekte sollten nur noch in dem neuen Datenmodell entwickelt werden, da der Lernaufwand gering und der gleichzeitige Nutzen durch neue Funktionalität hoch ist. Bestehende Datenmodelle müssen allerdings nicht zwangsweise umgestellt werden, diese laufen auch weiterhin. 

Anders ist die Frage zu beleuchten, ob denn in Transformationen nur noch AMDP-Prozesse verwendet werden dürfen. Dies ist bei einigen Kunden so gewünscht, aber nicht zwingend notwendig. Auch eine Transformation in ein aDSO mit ABAP-Routinen ist noch in einem BW/4 lauffähig. Vor dem Hintergrund der Performance wird die Transformation mit ABAP jedoch nicht auf die HANA gepusht und läuft daher langsamer. Bevor Eigenentwicklungen eingesetzt werden, könnten alternativ Formeln oder neuen Funktionalitäten (z.B. Nachlesen aus einem aDSO) das Problem lösen. Diese werden auf die HANA gepusht und sind leichter zu warten als ein verschlungenes Coding. Für die Entwicklung einer AMDP-Routine muss eine neue Entwicklungssprache gelernt werden. Diese bedarf bei komplexeren Anforderungen entsprechende Übung. Dann ist individuell zu betrachten, ob ein so hohes Datenvolumen zu erwarten ist und welche Skills im Entwicklungsteam sowie bei dem Support der Anwendung vorhanden sind. 

Planung in Drittanbieter-Tools

Inzwischen ist auch auf einem BW 7.5 die SAP-Welt schon lange kein abgeschottetes Universum mehr. Viele Unternehmen haben Drittanbieter-Tools im Einsatz, wie beispielsweise Tableau oder Power BI für eine schicke Reporting-Oberfläche. Damit ist die Hemmschwelle gesunken, Fremdsysteme in die BW–Welt zu integrieren. Für die Verwendung der Planung sind im BW/4 zusätzliche Lizenzen nötig. Bei BW 7.5 waren lediglich zusätzliche Lizenzen nötig, wenn Performance-seitig die Planung auf die HANA gepusht werden sollte. Daher wird sich die BW–Planung gegen die Kosten eines Drittanbieter–Tools behaupten müssen. Bei der Einführung von externen Planungstools sind ein paar Stolpersteine zu beachten, die in einer Toolauswahl gerne vergessen werden und kurz vor Abschluss das Projekt gefährden und die Kosten treiben können. 

Datenreplikation für die Ist- und Plan-Zahlen in und aus dem externen Planungstool

Im Gegensatz zu einem Reporting–Tool, das „nur“ lesend auf die BW–Daten zugreift, benötigt ein Planungstool eine eigene Datenhaltung für die Planzahlen. Meistens werden auch die Ist-Zahlen dort abgelegt. Damit ist eine Datenreplikation für die Ist-Zahlen aus dem BW und oft auch wieder zurück in das BW nötig. Daraus ergibt sich eine weitere Reporting-Oberfläche. Alternativ stehen die Planzahlen erst dann zur Verfügung, wenn die Planung abgeschlossen und wieder repliziert ist. Nicht zu vergessen ist, dass Erweiterungen am Datenmodell zudem immer durch ein weiteres System geschliffen werden müssen. 

Verständnis für das Datenmodell

Neben dem reinen physischen Replizieren der Daten muss das Datenmodell auch inhaltlich und strukturell an das neue Tool angepasst werden. Jedes Tool hat leicht abweichende Methoden und Daten abzulegen. Dies ist selten ein wirkliches Problem, es kann aber leicht zu Missverständnissen kommen, die die Entwicklung verzögern.  

Berechtigung und Userabgleich

Auch die Benutzerpflege muss in einem zusätzlichen Tool hinterlegt werden. Häufig ist der Aufwand nicht die eigentliche Useranlage, sondern die Aktualisierung der Verantwortlichkeiten. 

BW oder ein ganz neues Tool

Über den Aufwand für die Migration gibt es viele Gerüchte und Ängste. Viele befürchten einen sehr hohen Aufwand, der einer Neueinführung ähnlich ist. Dies ist ein Anlass, die Verwendung des SAP-BW zu hinterfragen und andere Tools zu evaluieren. 

Wie hoch ist der Migrationsaufwand auf BW/4 wirklich?

Wie immer hängt der Aufwand von der eigenen Situation ab. Hat man schon länger auf ein BW 7.5 on HANA migriert und Projekte schon mit den neuen Tools realisiert, fällt hierfür kein Migrationsaufwand mehr an. 

Inzwischen sind die Migrationstools so ausgereift, dass viele Modelle automatisch migriert werden können. Weist ein System viele historische Altlasten auf, ist der Erfahrungsschatz nicht zu unterschätzen, der in die Datenmodelle eingebaut ist. Andererseits kann dies auch eine Gelegenheit sein, „aufzuräumen“ und das System durch neue Techniken schlanker zu realisieren.  

Governance durch BW bei anderen Systemen nicht so vorhanden

In einem anderen Tool ist sicher die eine oder andere Lösung schnell gebaut. Jedoch sollte berücksichtigt werden, dass in einem BW die Tools zur Entwicklung sowie Transporte, Datenbeladung und Steuerung eingespielt und komfortabel sind. Dies ist nicht in allen Systemen so schlank möglich.  

Auch hat man für die BW–Systeme Namenskonventionen und Berechtigungen etabliert, um unterschiedliche Bereiche voneinander abzugrenzen. Dieses umfassende Wissen muss in neuen Systemen neu eingerichtet werden. 

Welche Gründe gibt es für einen Wechsel auf BW/4

Vor einem Upgrade sollte daher vor unterschiedlichen Gesichtspunkten eine klare Entscheidung pro Upgrade getroffen werden. Wie sieht dies beim BW/4 aus? Da das BW 7.5 schon ein recht ausgereiftes Produkt ist, gibt es kaum allgemeine und wichtige neue Funktionen. Im Detail existieren so einige Verbesserungen. Wer mit großen Datenmengen arbeitet und zuweilen sein Datenmodell remodelliert, der wird einige Aspekte nützlich finden, wie das Data Tiering, um ältere Daten aus dem Hauptspeicher auszulagern.  

Bei der Planung kann man nun auch Stammdaten planen und in einem Planungslayout neue Stammdaten erfassen. Dies ermöglicht einige neue Planungsszenarien. Zwingend erforderlich ist allerdings der Kauf zusätzlicher Lizenzen, wenn man die Planung verwenden möchte. 

Fazit

Dass die Migration auf ein BW/4 ein großer Sprung ist, der viele Fragen aufwirft, ist unbestritten. Ob die neuen Funktionen ein schnelleres Upgrade erfordern, muss abgewogen werden. Spätestens bis 2030, dem Ende des extendend Maintenance von BW 7.5, sollte diese Entscheidung getroffen werden. Insbesondere vor dem Hintergrund der SAP Data Warehouse Cloud am Horizont und der allgemeinen Cloud–Strategie von SAP…  

Zu einigen dieser Fragestellungen rund um diesen Themenkomplex hat der Blog hoffentlich ein paar Anregungen gegeben.  

Sollten Sie weitere Fragen haben oder Hilfe benötigen, können Sie sich natürlich gerne an uns wenden. 

Ansprechpartner

Dr. Ulrich Meseth

Senior 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.

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.