Konzeptkarte

SAP BW/4HANA

Stand 2026-08-29

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP BW/4HANA?

SAPs ausschließlich auf HANA laufendes Data-Warehouse-Produkt und die Nachfolge-Codelinie von SAP BW. Kein Release von BW, sondern ein eigenständiges Produkt mit bewusst kleinerem Objektmodell — weshalb der Umstieg eine Modellierungsübung ist, kein Upgrade.

Worum es geht

SAP BW/4HANA ist SAPs ausschließlich auf HANA laufendes Data-Warehouse-Produkt, generell verfügbar seit 2016. Die Namensgebung lädt zu einem Missverständnis ein, das früh benannt werden sollte: Es ist nicht „BW, Release 4“. Es ist ein eigenständiges Produkt mit eigener Codelinie, und ein Kunde führt eher einen Umzug hinein durch als ein Upgrade.

Was bewusst entfernt wurde. BW hat über achtzehn Jahre hinweg Objekttypen angehäuft, und BW/4HANA hat sie zurückgeschnitten. Der Advanced DSO (aDSO) übernahm die Rollen, die standardmäßige DSOs, schreiboptimierte DSOs und InfoCubes zuvor getrennt spielten — ein Objekt mit Konfigurationsschaltern statt drei Objekten mit unterschiedlicher Semantik. CompositeProviders übernahmen MultiProviders und InfoSets. Klassische InfoCubes, 3.x-Datenflüsse, Transferregeln und die alte extraktorseitige Modellierung sind verschwunden. Was übrig bleibt, ist der Teil, der die analytische Bedeutung trug: InfoObjects, Transformationen, DTPs, Process Chains und die Query-Schicht.

Warum das eine Modellierungsübung macht. Weil das Ziel weniger Objekttypen als die Quelle hat, gibt es für einen gewachsenen BW-Bestand keine originalgetreue Eins-zu-eins-Übersetzung. Jeder InfoCube muss zu einem aDSO mit gewählter Konfiguration werden; jeder MultiProvider muss zu einem CompositeProvider mit expliziter Join- oder Union-Entscheidung werden. Werkzeuge können einen großen Teil davon übernehmen, und SAP liefert Konversionspfade — in-place, remote und shell —, aber der Rest ist Beurteilungssache, und genau dort konzentriert sich der Aufwand. Das ist der Mechanismus hinter der Beobachtung, dass BW/4HANA-Projekte selten wie Upgrades aussehen.

Warum es zählt

BW/4HANA ist der eine Pfad, der das BW-Modellierungsparadigma intakt hält. Ob das ein Vorteil oder eine Verzögerung ist, hängt davon ab, wo der Kunde landen will, sobald BDC und Datasphere die strategischen Ziele sind.

Kernpunkte

Ein eigenständiges Produkt, kein BW-Release: eigene Codelinie, ausschließlich auf HANA, generell verfügbar seit 2016.
Untergrenze der installierten Basis ~2.500 Kunden gegenüber 20.000-30.000 BW-7.5-Kunden (SAP, Sapphire 2025) — die moderne Kohorte ist eine Minderheit des BW-Bestands.
Der aDSO ersetzt die Trennung zwischen DSO und InfoCube; CompositeProviders ersetzen MultiProviders und InfoSets. Weniger Objekttypen, mehr Entscheidungen in die Modellierung verschoben.
🔴 Es ist ein Nachfolger von BW, keine Alternative zu Datasphere oder BDC — sie liegen auf unterschiedlichen Ebenen, und die Wahl des einen klärt das andere nicht.
Konversionspfade existieren (in-place, remote, shell), aber der Rest ist Beurteilungssache, und genau dort konzentriert sich der Aufwand.
Die Pfadentscheidung (in-place · remote · shell) tauscht Kalenderzeit gegen Architektur-Neuanfang; sie ist keine Wahl zwischen billig und teuer.
Die Schätzung steckt in der Einzelentscheidung pro Objekt — abbilden, neu gestalten oder ausmustern — für jedes Objekt ohne Nachfolger im reduzierten Modell.
Eine Schätzung, die einen Pfad, aber kein Objektinventar nennt, ist eine Präferenz, keine Schätzung.

Begriffe auf dieser Seite

aDSO (Advanced DataStore Object): Das einzige BW/4HANA-Persistenzobjekt; Konfigurationsschalter decken ab, was standardmäßige DSOs, schreiboptimierte DSOs und InfoCubes zuvor getrennt leisteten.
CompositeProvider: Das BW/4HANA-Union-/Join-Objekt; ersetzt MultiProviders und InfoSets durch ein einziges explizites Konstrukt.
In-place conversion: Die Konversion eines bestehenden BW-Systems zu BW/4HANA auf demselben System, Objekt für Objekt.
Shell conversion: Der Aufbau einer leeren BW/4HANA-Hülle, die Übertragung des Modells und das anschließende Neuladen der Daten — der Pfad, wenn der Bestand ausgedünnt werden muss.
In-place conversion: Die Konversion von Objekten innerhalb des bestehenden BW-Systems, gefolgt vom Umzug auf ausschließlich HANA. Sie führt die Objekttyp-Zuordnung aus und erzwingt kein Redesign.
Shell conversion: Der Aufbau eines leeren BW/4HANA-Ziels und der Neuaufbau oder selektive Transport von Inhalten hinein. Der Pfad mit dem größten Beurteilungsrest, und der richtige gegen starke undokumentierte Schulden.
No-successor inventory: Die Liste der Quellobjekte ohne Entsprechung im reduzierten Objektmodell. Sie ist die Grundlage einer ehrlichen Schätzung und das Erste, was ein Anbieterangebot meist auslässt.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →