Warum BW-Modernisierung mit SAP Datasphere kein Migrationsprojekt ist

Die SAP Business Data Cloud verfolgt einen anderen Ansatz. Sie ist bewusst entkoppelt. Operative Systeme, semantische Modellierung und analytische Nutzung sind getrennte Schichten mit klaren Verantwortlichkeiten.

• Fachliche Regeln gehören ins Quellsystem oder in eine dedizierte Transformationsschicht.
• Die semantische Modellierung findet in SAP Datasphere statt.
• Die Auswertung und Planung erfolgt in der SAP Analytics Cloud.

Ein zentrales Query-Objekt, das zur Laufzeit fachliche Logik bündelt, gibt es in diesem Modell nicht. Die fachliche Aussage entsteht aus dem Zusammenspiel von Datenmodell und Story, nicht aus einem eigenständigen Objekt, das beides vereint.

Das ist kein technischer Mangel. Es ist eine bewusste Architekturentscheidung. Und genau darin liegt der Kern des Missverständnisses.

Um das greifbar zu machen, hilft ein Blick auf typische BW-Nutzungsmuster (dies soll keine allumfassende Liste sein) und darauf, was sie im BDC-Kontext bedeuten.

In vielen BW-Systemen werden innerhalb von Transformationen remote-fähige Funktionsbausteine aufgerufen, um Informationen direkt aus dem S/4-System zu ermitteln. Das BW übernimmt also eine aktive Rolle bei der Datenanreicherung zur Laufzeit.

Die SAP Business Data Cloud ist nicht dafür ausgelegt, operative Logik aus Fremdsystemen synchron zur Laufzeit einzubinden. Das widerspricht dem Zielbild einer klaren Trennung zwischen operativer Verarbeitung und analytischer Nutzung. Technisch lösbar? Ja, aber nur durch eine bewusste Neuverteilung der fachlichen Verantwortung: Die Logik muss ins Quellsystem, oder die Daten müssen vorgelagert bereitgestellt werden.

Viele BW-Systeme haben im Laufe der Zeit eigene Steuerungsapplikationen entwickelt: ABAP-Transaktionen, über die Prozessketten ausgelöst, Planungsparameter gesetzt und Zustände in Datenbanktabellen gepflegt werden. Diese Cockpits bündeln Steuerung, Parametrisierung und Ausführung in einer integrierten Oberfläche.

Ein vergleichbares Konzept existiert in der BDC nicht. Was SAC an Steuerungsmöglichkeiten bietet, ist funktional entkoppelt – nicht als durchgängiger, zustandsbehafteter Prozess aufgebaut. Eine 1:1-Ablösung ist nicht möglich. Die Funktionen müssen neu verteilt werden, teilweise auch auf externe Komponenten.

In Finance-Anwendungen wird häufig eine hierarchieabhängige Eliminierung interner Verrechnungen genutzt: Abhängig vom ausgewählten Knoten einer Kostenstellenhierarchie werden Binnenumsätze entsprechend eliminiert oder dargestellt. Im BW gibt es dafür etablierte Konzepte, die Auswertungslogik kontextabhängig zur Laufzeit anwenden.

In der SAP Business Data Cloud existiert kein direktes Standardpendant. Dynamische, kontextabhängige Eliminierungen zur Laufzeit sind nicht vorgesehen. Umsetzbar ist das Szenario, aber nur indem es fachlich neu gedacht und modelliert wird.

In einigen BW-IP-Umgebungen werden im Rahmen von Planungsfunktionen Stammdaten regelbasiert erzeugt und erweitert. Neue Planungsobjekte entstehen nicht durch manuelle Pflege, sondern als Ergebnis definierter fachlicher Regeln.

Die SAC bietet zwar Möglichkeiten zur Stammdatenpflege, aber über explizite Benutzerinteraktionen, nicht über generische Planungsfunktionen. Eine backendseitige, wiederverwendbare Ableitungslogik ist nicht vorgesehen. Die Umsetzung wäre auch in der BDC möglich, erfordert aber eine bewusste Spezialimplementierung und ist damit architektonisch weniger sauber als im BW.

Nicht alles ist schwierig. Manche BW-Konzepte lassen sich in der BDC nicht nur umsetzen, sondern sogar sauberer modellieren als bisher.

• 0BALANCE und Ausnahmeaggregation
  Die BW-Kennzahl 0BALANCE wird genutzt, um Salden und Bestände fachlich korrekt über Zeitdimensionen auszuweisen – ohne dass Werte ungewollt aufsummiert werden. In SAP Datasphere lässt sich dieses Konzept über nicht-kumulative Kennzahlen mit entsprechender Ausnahmeaggregation sauber modellieren. Die fachliche Wirkung ist dieselbe, die Umsetzung ist expliziter im Datenmodell verankert. Das ist kein Nachteil – es ist eine Verbesserung.
• Transponieren zwischen Kennzahl- und Kontenmodellen
  Viele BW-Systeme enthalten sogenannte „Kipp-Logiken“: Datenmodelle werden von einer kennzahlorientierten Struktur in eine kontenorientierte überführt oder umgekehrt. Das ist historisch gewachsen und erhöht die Komplexität erheblich. In der BDC ist diese Umformung technisch möglich, aber der notwendige konzeptionelle Umbau bietet die Chance, sich von dieser inkonsistenten Modellierung zu verabschieden und ein einheitliches Paradigma zu etablieren.

Die Botschaft lautet in beiden Fällent: Im BW wurde X so gelöst. In der BDC muss Y neu gebaut werden – aber Y ist oft besser als X.

Wer BW-Modernisierung als technisches Migrationsprojekt versteht, stellt die falsche Frage. Die richtige Frage lautet nicht: „Wie bringe ich meine BW-Objekte in die BDC?“

Die richtige Frage lautet: „Wo gehört welche fachliche Logik hin?“

Konkret bedeutet das, für jede Logikschicht im bestehenden BW eine neue Heimat zu definieren:

• Was bleibt im S/4HANA-Quellsystem?
• Was modelliert man in SAP Datasphere als semantische Schicht?
• Was übernimmt SAC in der Auswertungs- und Planungsschicht?
• Und was fällt ersatzlos weg, weil es nie echte fachliche Anforderungen abbildete, sondern nur technische Limitierungen umging?

Diese Fragen klingen einfach. In der Praxis sind sie es nicht. Denn sie erfordern eine tiefe Auseinandersetzung mit dem bestehenden BW-System und mit den fachlichen Prozessen, die dahinterstecken. Viele BW-Landschaften sind über Jahre gewachsen. Die Logik steckt in hunderten Queries, in ABAP-Code, in Transformationsregeln. Niemand hat einen vollständigen Überblick. Und niemand weiß auf Anhieb, welche Teile davon wirklich gebraucht werden.

Ein weiteres systematisches Missverständnis betrifft den Aufwand. Viele Unternehmen schätzen den Migrationsaufwand anhand von Datenmenge, Systemgröße oder Objektanzahl. Das ist die falsche Messgröße.

Der tatsächliche Aufwand hängt von der „fachlichen Komplexität der Applikationen“ ab und nicht nur von der Anzahl der zu implementierenden Objekte.

In einem realen Projekt mit einem mittelständischen Industrieunternehmen wurde die bestehende BW-Landschaft systematisch analysiert: 14 aktiv genutzte Applikationen, objektbezogen bewertet. Das Ergebnis war aufschlussreich: Der Gesamtaufwand für einen vollständigen Neuaufbau in der SAP Business Data Cloud lag bei über 1.000 Personentagen, verteilt auf 16 Bereiche von CRM bis Bilanz- und Ergebnisrechnung.

Aber die Verteilung war alles andere als gleichmäßig. Zwei oder drei fachlich komplexe Applikationen, solche mit starkem Rechenanteil, integrierter Planungslogik oder komplexen hierarchieabhängigen Berechnungen, trieben den Großteil des Aufwands. Einfache Reporting-Applikationen waren dagegen vergleichsweise schnell umsetzbar.

Der praktische Schluss daraus, dass nicht nur die Breite der BW-Landschaft den Aufwand bestimmt, sondern vor allem ihre Tiefe. Und die lässt sich nicht nur durch eine strukturierte Analyse der Applikationen sichtbar machen.

Aus den Erfahrungen aus realen BW-Modernisierungsprojekten lässt sich eine klare Handlungsempfehlung ableiten:

„Starten Sie nicht mit der Tool-Auswahl. Starten Sie mit der Architekturentscheidung.“

Das bedeutet konkret:

1. Bestandsaufnahme der BW-Applikationslandschaft
   Welche Applikationen sind aktiv genutzt? Welche fachliche Funktion erfüllen sie? Welche Logiktypen stecken drin – reines Reporting, integrierte Planung, operative Steuerung, ABAP-Logik?
2. Klassifikation nach Komplexität und strategischem Fit
   Jede Applikation wird entlang zweier Dimensionen bewertet:
   – Abbildbarkeit in der Zielarchitektur: Ist eine saubere Umsetzung mit Standardmitteln möglich? Oder braucht es konzeptionellen Umbau oder Speziallösungen?
   – Strategischer Fit: Entspricht die Lösung dem Zielbild der neuen Plattform – oder steht sie in einem strukturellen Spannungsfeld dazu?
   Diese zweidimensionale Betrachtung macht transparent, wo die eigentlichen Herausforderungen liegen – und welche Applikationen den Transformationsaufwand maßgeblich treiben.
3. Strategische Grundsatzentscheidung
   Erst wenn die bestehende Landschaft und die Implikationen der Zielarchitektur verstanden sind, lässt sich eine fundierte Entscheidung treffen:
   BDC als Zielarchitektur,
   BW/4HANA als konservativer Pfad,
   oder ein evolutionäres Hybridmodell?
   Diese Entscheidung ist keine technische, sondern eine strategische – und sie bestimmt Zeitachse, Investitionsprofil und organisatorische Anforderungen für die nächsten Jahre.