Konzeptkarte

SAP BW/4HANA

Stand 10. Oktober 2026

Redaktion: Cédric Mary, 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?

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.

Größenordnung, als Untergrenze formuliert. Das Register führt ~2.500 BW/4HANA-Kunden gegenüber den 20.000-30.000 klassischen BW-7.5-Kunden, die SAP auf der Sapphire 2025 nannte (D. K., berichtet von SAPinsider). Beides sind Untergrenzen aus öffentlicher Offenlegung und keine Zählungen aus einem Register, und die robustere Lesart ist das Verhältnis: Die modernisierte Kohorte ist eine klare Minderheit des BW-Bestands. Diese Asymmetrie, nicht die eine oder andere Zahl für sich, treibt das Argument der Migrationsnachfrage.

Wo es gegenüber Datasphere und BDC steht. BW/4HANA ist der Nachfolger innerhalb der BW-Linie. SAP Datasphere ist ein Cloud-Data-Warehousing-Dienst mit einem anderen Modellierungsmodell, und SAP Business Data Cloud ist die verpackte Datenprodukt-Schicht darüber. Sie sind keine konkurrierenden Antworten auf dieselbe Frage. Ein Kunde kann BW/4HANA und Datasphere gemeinsam betreiben, und BW Bridge existiert genau deshalb, damit BW-Inhalte in Datasphere landen können. Die Wahl als Entweder-oder zu behandeln, ist der häufigste Rahmungsfehler in diesem Teil des Stacks.

Die Konversionspfade, und was jeder tatsächlich kostet

SAP liefert drei dokumentierte Pfade, und keiner davon ist frei von dem oben beschriebenen Modellierungsrest.

In-place-Konversion läuft innerhalb des bestehenden Systems: Objekte werden dort konvertiert, wo sie stehen, in kontrollierter Reihenfolge, und das System endet mit derselben technischen Identität wie zuvor, nur ausschließlich auf HANA. Sie passt zu einem einzelnen System mit einem akzeptablen Ausfallfenster und einer technischen Schuldenlast, die das Team unverändert weitertragen will — denn die In-place-Konversion erzwingt kein Redesign, sie führt nur die Objekttyp-Zuordnung aus (DSO/InfoCube zu aDSO, MultiProvider/InfoSet zu CompositeProvider), die das reduzierte Objektmodell verlangt.

Remote-Konversion stellt ein neues BW/4HANA-System auf und zieht Inhalte objektweise aus dem Quellsystem herüber, was auch der natürliche Zeitpunkt ist, um mehrere Quellsysteme zu konsolidieren oder ungenutzte Inhalte auszumustern. Sie kostet mehr Kalenderzeit als in-place, kauft aber einen echten Architektur-Neuanfang.

Shell-Konversion behält nur die technische Hülle des Zielsystems und baut Inhalte neu auf oder transportiert sie selektiv hinein. Das ist die richtige Wahl, wenn der Quellbestand genug undokumentierte technische Schulden trägt, dass eine mechanische Konversion das Problem nur verlagern würde — aber es ist auch der Pfad mit dem größten Beurteilungsrest, weil hier nichts allein durch Werkzeuge übertragen wird.

Ein BW/4HANA-Projekt ehrlich dimensionieren

Die drei obigen Pfade ersetzen kein Scoping; sie sind unterschiedliche Verteilungen dessen, wo die Beurteilungsarbeit landet. Ein Angebot, das nur den Pfad nennt und nicht das Objektinventar — wie viele InfoCubes, wie viele MultiProviders, wie viele kundeneigene Transformationsroutinen —, hat das Projekt noch nicht wirklich gescoped, denn die Zuordnungsentscheidungen für aDSO und CompositeProvider sind genau die Positionen, die weder Werkzeuge noch die Pfadwahl entfernen.

Die Entscheidung, die das erzwingt

Zwei Entscheidungen, in dieser Reihenfolge getroffen, und die zweite trägt die Schätzung. Erstens der Pfad: in-place, remote oder shell — ein Kompromiss zwischen Kalenderzeit und Architektur-Neuanfang, nicht zwischen billig und teuer. Dann, für jedes Objekt ohne Nachfolger im kleineren Modell, eine Einzelentscheidung: mechanisch abbilden, neu gestalten oder ausmustern. Die Werkzeuge tragen die Abbildung; sie tragen nichts vom Redesign und nichts von den Ausmusterungsgesprächen. Den Umzug als Upgrade zu rahmen, verdeckt genau diese zweite Entscheidung — weshalb eine Schätzung, die einen Pfad, aber kein Objektinventar nennt, keine Schätzung ist, sondern eine Präferenz.

Die Joule-Perspektive, September 2026

Das reduzierte Objektmodell von BW/4HANA — aDSO und CompositeProvider ersetzen den älteren Satz aus DSO/InfoCube/MultiProvider/InfoSet — ist für ein KI-Gespräch aus einem Grund relevant, der nichts mit Performance zu tun hat: Ein kleinerer, konsistenterer Satz an Objekttypen lässt sich leichter als governtes BDC-Data-Product veröffentlichen, und ein governtes Data Product ist die einzige Form von BW/4HANA-Inhalt, auf der der SAP Knowledge Graph oder ein Joule-Agent tatsächlich Reasoning verankern kann. Ein sauber modellierter BW/4HANA-CompositeProvider — mit einer bereits getroffenen expliziten Join- oder Union-Entscheidung, statt als mehrdeutige MultiProvider-artige Vereinigung belassen — lässt sich mit deutlich weniger Beurteilungsrest in ein BDC-Data-Product umwandeln als das entsprechende klassische BW-Objekt, weil die Hälfte der Modellierungsentscheidung (welche Felder, welcher Join) auf der Quellseite bereits gelöst ist.

Das ist ein echtes, wenn auch unterbenutztes Argument dafür, den BW/4HANA-Pfad zu wählen statt auf klassischem BW 7.x zu bleiben, wenn Business Data Cloud und Joule das mittelfristige Ziel sind: Der auf dieser Karte beschriebene Konversionspfad-Aufwand (In-place, Remote, Shell) wird einmal investiert und zahlt sich zweimal aus — einmal Richtung BW/4HANA selbst, ein zweites Mal dafür, wie dieser Inhalt später die Data-Product-Schicht von BDC erreicht, weil das reduzierte Objektmodell von BW/4HANA strukturell näher an einem Data Product liegt als das von klassischem BW. Ein Berater, der einen BW/4HANA-Umstieg nur gegen den Wartungshorizont 2027 von BW 7.5 scoped, lässt diesen zweiten Nutzen unausgesprochen.

Was zu entscheiden ist: Wenn ein Kunde zwischen BW/4HANA und dem Verbleib auf klassischem BW wählt, während alles andere auf Datasphere/BDC verweist, fragen, ob der Bestand in den nächsten zwei bis drei Jahren zu Knowledge-Graph-verankertem Inhalt werden soll. Wenn ja, ist die von BW/4HANA erzwungene Vereinfachung des Objektmodells kein verschwendeter Modellierungsaufwand — es ist Aufwand, auf dem der BW Data Product Generator (siehe die begleitende Karte zum BW-Support-Ende) günstiger aufbauen kann als auf einem klassischen BW-Bestand mit InfoCubes und MultiProvidern ohne Nachfolgeobjekt. Worauf zu achten ist: SAP hat keine erklärte Präferenz veröffentlicht, ob über BW/4HANA konvertiert werden soll, bevor BDC-Data-Products generiert werden, oder ob direkt aus klassischem BW generiert werden soll — dies als architektonisches Urteil behandeln, das das eigene Team in der Schätzung explizit macht, nicht als dokumentierte SAP-Empfehlung.

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.

Quellen

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.