Der beste Weg zu SAP BW/4HANA

Wichtige Überlegungen zur Auswahl der Strategie für ein Migrationsverfahren: Auf welcher Ebene setzt man an?

1. Bei Migration von BW 7.x auf BW/4HANA:
   Prüfung der Migrationsverfahren, die SAP bietet – welches Verfahren passt? Wie können AddOns wie SEM in BW/4HANA künftig abgebildet werden?
2. Generelle Prüfung des Business Warehouse:
   – Definition der funktionalen betriebswirtschaftlichen Anforderungen im Unternehmen
   – Betrachtung des gesamten Lösungsportfolios der SAP (mit BW/4HANA, SAP HANA for SQL Data Warehousing, Data Warehouse Cloud und Hybrid-Modelle), sowie Lösungen von Drittanbietern
3. Geplante Migration des ERP auf S/4HANA:
   Wenn im Unternehmen auch eine Überlegung zur Migration des ERP auf S/4HANA stattfindet:
   – Gemeinsame Migration: Start mit der Konvertierung des ERP auf S/4HANA und etwas zeitversetzt die Konvertierung auf SAP BW/4HANA – dafür gibt es ein bis zwei Konvertierungsmöglichkeiten
   – Separate Systemkonvertierung: Beginnt man mit der Systemkonvertierung auf SAP BW/4HANA und folgt nach ein bis zwei Jahren mit der Migration des ERP ist der Migrationsaufwand höher, als wenn man mit dem ERP beginnt und zeitversetzt mit BW/4HANA folgt.
   Auch bei separater Migration gibt es zwei Migrationsverfahren zur Auswahl.
4. Rein technische Migration von BW 7.x auf BW/4HANA:
   Unverändertes Reporting, um den Aufwand gering zu halten
5. Zeit- und Kostenbetrachtung bei Entscheidung, auf BW/4HANA zu migrieren. Was bedeutet es, sich für das eine oder andere Verfahren zu entscheiden?
6. Remodellierung von Datenmodellen und Löschung von Altlasten
   Will man Datenmodelle remodellieren und Altlasten löschen?
   Bei manchen Migrationsverfahren ist dies schwieriger, bei anderen einfacher.

Tipp: Bei einem Release-Stand von BW 7.4 oder älter, kann BW 7.5 on HANA als Zwischenziel eingeschoben werden. Über ein DMO-Verfahren kann mit einem Schritt auf BW 7.5 migriert werden.
Vorteil: Mit der Migration auf BW 7.5 on HANA kann man alte Datenmodelle nutzen und gleichzeitig neue Funktionalitäten kennenlernen, die fast identisch mit BW/4HANA sind (u.a. der Eclipse-basierte Querydesigner). Es kann in Ruhe Know-how aufgebaut werden, da kein zeitlicher Druck besteht von 7.x auf BW/4HANA zu gehen (Maintenance von BW 7.5 bis 2027).

Abb. 3,4: Projektziele bei Systemkonvertierung zu BW/4HANA

• Installation eines neuen Systems in Abhängigkeit der neuen betriebswirtschaftlichen Anforderungen (neue SID, d.h. SAP System Identifier) mit neuem Quellsystem (z.B. S/4 HANA oder klassischem ERP). Dort werden die Datenmodelle aufgebaut.
• Daten werden aus dem angeschlossenen Quellsystem neu geladen.

• SAP bietet verschiedene Migrations-Tools an. Man bleibt im BW-System und migriert die Datenmodelle in die neue SAP BW-Welt
• Danach folgt der Release-Wechsel auf SAP BW/4HANA. Schritt für Schritt erfolgt die Übertragung von Objekten in HANA optimierte Pendants.
• Vollständige Systemumwandlung einer bestehenden SAP BW-Installation (gleiche SID). Es erfolgt keine Neuinstallation, es ist keine zusätzliche Hardware erforderlich.

• Es wird ein neues SAP BW/4HANA System parallel installiert mit einer neuen SID.
• Über sogenannte Transporte (SLT SAP Landscape Transformation) werden die Daten inkl. der Datenmodelle in das BW-System transportiert und beim Einspielen konvertiert.
  Vorteil/Nachteil: Hat man einen Datenfluss aufgebaut, in dem aufgrund betriebswirtschaftlicher Anforderungen zwei bis drei DSOs hintereinander geschaltet werden, werden diese genauso in ADSOS transformiert. In der neuen Welt benötigt man diese eventuell nicht mehr und muss dies manuell anpassen, um die Datenbank klein zu halten.

• Es wird ein neues SAP BW/4HANA System parallel installiert mit einer neuen SID.
• Übertragung der Datenmodelle ohne Datenübertragung
• In BW/4HANA hat man die Möglichkeit, die Datenmodelle anzupassen, da sie keine Daten beinhalten. Die Daten werden aus Quellsystem und /oder BW übernommen.

Abb. 5: Vier Ansätze zur Systemkonvertierung auf SAP BW/4HANA

• Start mit der Implementierung eines neuen SAP BW/4HANA-Systems
• Altes BW System läuft parallel
• Aufbau der neuen Datenmodelle im neuen System, ausgehend von den betriebswirtschaftlichen Anforderungen
• Datenübertragung nach der Implementierung aus dem angeschlossenen Quellsystem
• Keine Voraussetzung im Hinblick auf das Originalsystem, man kann von jedem beliebigen Release-System aus starten

• Während der Implementierung kann das bestehendes BW weiter genutzt werden
• Einheitliche Namenskonvention, man kann neue Namenskonventionen für neue Objekte vergeben
• Beste Möglichkeit für Re-engineering und Prozessoptimierung, da das Altsystem unangetastet bleibt
• Keine Störung bestehender Prozesse
• Nachteil oder Vorteil: das Berichtswesen/Reporting muss neu aufgebaut werden.

Abb. 6: Greenfield Ansatz

Abb. 7: Ablauf der Greenfield Konvertierung, Quelle: Conversion Guide for SAP BW/4HANA 2021, Ausschnitt S.20

• Kein Aufbau eines neuen Systems
• Schritt für Schritt Umwandlung der klassischen Objekte zu HANA optimierten Objekten (z.B. DSO zu ADSO) mit Migrations-Tools der SAP
• System wird nach SAP BW/4HANA konvertiert, wenn alle Datenmodelle konvertiert sind und alle Objekte dem Stand des neuen Systems entsprechen
• System Voraussetzung ist mindestens: SAP BW on HANA 7.5 SP 5

• Umwandlung ohne Anpassung der Datenmodelle, es findet eine rein technische Migration statt
• z.T. kurze Ausfallzeiten des Berichtswesens
• System-ID bleibt in Systemlandschaft erhalten
• Geringere Betriebskosten, da nur ein System existiert, keine zusätzliche Hardware und Lizenzkosten notwendig sind.

Abb. 8: In-Place Konvertierung

• Ausgehend von SAP BW 7.5 on HANA wird das Starter AddOn installiert (Transfer Tool)
• Im Starter AddOn gibt es verschiedene Modi zur Auswahl (BW Bode, Compatibility Mode, B4H Mode, Ready4Conversion)
• Man migriert alle Datenmodelle und löscht Altlasten
• Dann erfolgt zum Schluss die Konvertierung auf BW/4HANA in einfachem Schritt

Abb. 9: Ablauf der In-Place Konvertierung

Abb. 10: In-Place Konvertierungsmodi

• Start mit SAP BW/4HANA als Parallel-System, am besten als Entwicklungsumgebung (ähnlich wie bei Shell Conversion)
• Unterstützung von Carve-out- und Konsolidierungsszenarien. Es müssen nicht alle Datenmodelle überführt werden, ungenutzte Datenmodelle werden nicht überführt
• Transport von Datenmodellen und Datentransfer mit SLT (SAP Landscape Transformation)
• Systemvoraussetzung ist mindestens SAP BW 7.3 oder höher auf jeder DB oder SAP HANA

• Datenmodelle können bereinigt werden – mit Zusatzaufwand. Beim Import wird das Datenmodell konvertiert.
• Keine Störung bestehender Geschäftsprozesse, da das alte BW-System weiterläuft
• Komplette Datenflüsse inklusive der Daten werden übernommen
• durch das parallel laufende System wird das Risiko eines Datenverlustes verringert
• Nachteil: paralleler Betrieb von zwei Systemlandschaften erforderlich über eine gewisse Zeit

Abb. 11: Remote Konvertierung

• Aufbau eines parallelen BW/4HANA Systems
• Carve Out der Applikationen, die man ins neue System übernehmen möchte
• Übertragung von Datenmodellen inklusive der Daten (bei Import werden die Modelle migriert)

Abb. 12: Ablauf der Remote Konvertierung, Quelle: Conversion Guide for SAP BW/4HANA 2021, S. 23

Die Shell Konvertierung wurde von SAP später entwickelt, nachdem festgestellt wurde, dass bei der Remote Konvertierung Daten mitübertragen werden und Datenmodelländerungen daher nur schwer durchzuführen sind.

• Ähnlich wie bei der Remote Conversion wird eine parallele SAP BW4/HANA Umgebung aufgebaut
• Es werden jedoch im Gegensatz zur Remote Conversion lediglich Metadaten übertragen, eine Datenübertragung findet nicht statt
• Daten werden aus dem Quellsystem und/oder aus dem Alt-BW geladen
• Systemvoraussetzung ist mindestens SAP BW 7.0 oder höher auf jeder DB oder SAP HANA

• Gezielte Auswahl von Datenmodellen zur Übertragung möglich
• Möglichkeit zu Anpassungen der Datenmodelle (nach der Migration)
• Datenübertragung aus Quell- oder BW-System
• Nachteil: paralleler Betrieb zweier System-Landschaften erforderlich
  .

Abb. 13: Shell Konvertierung

• Aufbau eines parallelen BW/4HANA Systems, vergleichbar mit Remote Conversion
• Auswahl der Datenmodelle, die man ins neue System übernehmen möchte mit Metadaten
• Gegebenenfalls Anpassung der Datenmodelle
• Datenübertragung aus Quell- oder BW-System
• Einfachere Remodellierung als bei Remote Conversion

Abb. 14: Ablauf der Shell Konvertierung, Quelle: Quelle: Conversion Guide for SAP BW/4HANA 2021, S.23

1. Greenfield Ansatz: Neuinstallation des BW/4HANA Systems
2. In-Place Conversion: man bleibt im bestehenden System, Installation des Starter AddOns, Konvertierung des kompletten Systems mit Hilfe der SAP Migrationstools, Voraussetzung SAP BW7.5 on SAP HANA
3. Remote Conversion: System Carve-Out wie bei Shell Conversion, allerdings Übertragung mit Daten,
   Voraussetzung: SAP BW 7.3 oder höher auf jeder Datenbank
4. Shell Conversion: Übertragung der Datenmodelle ohne Daten, Anpassung der Datenmodelle,
   Voraussetzung: SAP BW 7.0 oder höher auf jeder Datenbank
   Namenskonventionen werden nicht automatisch angepasst.
   Bei Remote oder In-Place Conversion müssen die Datenmodelle innerhalb des BW/4HANA kopiert werden, um die Namenskonventionen anzupassen.

Es muss gut überlegt werden, welcher Pfad am besten geeignet ist.

Abb. 15: BW/4HANA Migrationspfade

• Wird bereits SAP BW 7.5 on HANA genutzt? Sind Datenmodelle bereits LSA++ konform? Bei Vertrautheit mit ADSO, Eclipse-basierter Query-Designer, Nutzung von SDI oder SDA, bietet sich die In-Place Konvertierung an – abhängig von betriebswirtschaftlichen Anforderungen
• Besteht hoher Bedarf, die Geschäftsprozesse zu optimieren – gegebenenfalls in Verbindung mit einer ERP-Migration zu SAP S/4HANA – bietet sich der Greenfield-Ansatz an. Auf Basis der betriebswirtschaftlichen Anforderungen können die richtigen Datenmodelle aufgebaut werden.
• Existiert viel redundantes Coding? Das ABAP-Coding sollte überprüft und angepasst werden. Dafür ist man im Greenfield-Verfahren frei, da kein Coding übernommen wird.
• Zukünftiger Wartungsaufwand: Beim Greenfield-Ansatz kann das Modell optimal auf die Bedürfnisse angepasst werden. Bei den anderen Ansätzen hat man Altlasten, die zukünftig ge-wartet werden müssen.
• Namenskonventionen sind mit Greenfield Ansatz sehr viel einfacher umzusetzen
• Gibt es viele Objekte, die bereits kompatibel mit SAP BW/HANA sind? Bei Nutzung von ADSO, Composit-Provider ist es einfacher, alte Datenmodelle zu konvertieren, als einen Greenfield Ansatz durchzuführen.
• Sollen Quellsysteme auch migriert werden (S/4)? Dann ist der Greenfield Ansatz zu empfehlen, weil sich sehr viel ändert, v.a. im Bereich FICO.
• Soll das bestehende Berichtswesen beibehalten werden? Dann ist die In-Place Konvertierung unter Aufwand-Nutzen-Abwägung der bessere Weg.

Abb. 16: Kriterien zur Auswahl eines Migrationsverfahrens

Auschluss von In-Place und Remote-Konversion, Entscheidung für Greenfield oder Shell Conversion (Brownfield)

Gründe:

• Bei System-Konvertierung im BW-Umfeld bleiben die Datenmodelle unverändert,
• bei System-Konvertierung im ERP-Umfeld ändert sich sehr viel, v.a. im FI- und CO- Umfeld.
• Das impliziert Neuaufbau der Datenmodelle im BW oder umfangreiche Anpassungen der Datenmodelle, inklusive des Reportings. Außerdem kann keine Stammdatenbereinigung durchgeführt werden.

Abb. 17: Parallele Migration zu BW/4HANA und S/4HANA

Auschluss von In-Place und Remote-Konversion, Entscheidung für Greenfield oder Shell Conversion (Brownfield)

Gründe:

• Bei System-Konvertierung im BW-Umfeld bleiben die Datenmodelle unverändert,
• bei System-Konvertierung im ERP-Umfeld ändert sich sehr viel, v.a. im FI- und CO- Umfeld.
• Das impliziert Neuaufbau der Datenmodelle im BW oder umfangreiche Anpassungen der Datenmodelle, inklusive des Reportings. Außerdem kann keine Stammdatenbereinigung durchgeführt werden.

Abb. 18: Gegenüberstellung Greenfield und Brownfield-Ansatz

Shell Konvertierung (Brownfield)

• Altdaten können gelöscht werden, Datenmodelle werden erst gar nicht eingestellt
• Datenmodellanpassungen möglich, Daten werden erst später geladen
• Geringerer Aufwand – Datenmodelle die nicht stark tangiert werden, bei Prozessänderungen in S/4HANA können über Transporte eingespielt werden ins BW/4HANA und müssen nicht neu gebaut oder angepasst werden.
• Nachteil: Anpassung der Namenskonventionen für ein stringentes System

Greenfield Konvertierung (Greenfield)

• Freie Entscheidung der Softwarekomponenten. Es kann auch die Plattform in Frage gestellt werden. Evtl. ist SAP Data Warehouse Cloud Ansatz oder SAP SQL on HANA die richtige Lösung. Dazu müssen die Anforderungen betrachtet werden
  • Prozessketten-Neuaufbau einfacher
  • Alle Anwendungen müssen neu implementiert werden
  • Namenskonventionen können auf die neuen Objekten angepasst werden

Fazit: Es gibt keine eindeutige Empfehlung.
Betrachtung der Datenmodelle:

• sind sie überwiegend nutzbar mit S/4HANA, bietet sich die Shell Conversion an,
• wird das ERP komplett neu gestaltet, bietet sich Greenfield Ansatz an.

In Workshops mit Infocient würden diese Anforderungen individuell herausgearbeitet werden, um den besten Ansatz zu finden.

Soll die Migration des ERP nach S/4HANA nicht in nächster Zukunft stattfinden und nur von BW 7.5 oder von 7.3 auf BW/4HANA migriert werden, bieten sich In-Place oder Shell-Konvertierung an.

Gründe für den Ausschluss von Greenfield und Remote-Konvertierung:

• Beim Greenfield-Ansatz müssten alle Datenmodelle neu aufgebaut werden. Bei einer späteren S/4-Einführung müssen die Datenmodellen ggf. angepasst werden, bezogen auf das neue Datenmodell (neue Datenquellen) – enormer Aufwand beim Greenfield Ansatz
• Bei Remote Konversion muss ebenfalls eine parallele SAP BW/4HANA Systemumgebung aufgebaut werden, das komplette Reporting muss umgezogen werden, die Datenmodelle werden genauso übertragen.
  Datenmodellanpassungen sind schwierig, da Daten mitgeladen werden.

Abb. 19: Technische Migration auf SAP BW/4HANA

In-Place Konvertierung mit geringeren Kosten verbunden, laufender Systembetrieb ist mit gleicher SID sichergestellt.

• Kein Aufbau eines zukünftigen Systems, fast keine Einschränkungen bei der Entwicklung des BW-Systems, weil man im alten System weiterarbeiten kann, alte Datenmodelle können sukzessive umgezogen werden.
• Geringere Kosten ohne zusätzliches System und geringerer Zeitaufwand, da schon heute mit der Umstellung begonnen werden kann.
• Das Reporting wird weiterhin genutzt, daher merken die Benutzer nichts von der Umstellung.

Abb. 20: Gegenüberstellung In-Place und Shell Konvertierung

• Migration 3.x-Objekte (nicht bei Greenfield)
• DB-Quellsysteme (bei allen)
• ABAP-Coding, das angepasst werden muss (Tool „Code Scan“) (nicht bei Greenfield)
• Delta-Queue-Cloning: Deltas müssen einmalig manuell angestartet werden (nicht bei In-Place)
• Aggregationsebenen auf Cubes oder DSOs müssen manuell umgebaut werden (nicht bei Greenfield)
• BEx Workbooks müssen manuell nachgebaut werden (Analysis) (bei allen)
• WebTemplates müssen manuell nachgebaut werden (Lumira) (bei allen)
• Objektlöschungen (nur bei In-Place)
• Reporting-Agent-Einstellungen bzw. BEx Broadcaster (müssen durch eine neue Lösung ersetzt werden) (bei allen)
• Prozesskette: AttribChange und Statistik-Aufbau manuell aus Prozessketten entfernen (nicht bei Greenfield)
• Ggf. je nach Szenario weitere, manuelle Aktivitäten
• Ersatzlösung für nicht mehr unterstützte AddOns finden, z.B. SEM-BW (Hinweis 2189708) und nicht mehr unterstütze Funktionalitäten z.B. APD

• HANA Migration Cockpit (Hinweis 1909597)
  liefert grobe Informationen zum Systemzustand (Schwerpunkt ist eher die Migration nach HANA, weniger die Konvertierung)
• BW/4HANA Transfer Cockpit
  (Transaktion RSB4HCONV) – zentrale Workbench für die System-Conversion (Toolsammlung)

1. Analysephase: wie viele Objekte, Aufwandstreiber identifizieren („Simplification List“), AddOn
2. Entscheidung für eines der vier Verfahren: Abhängigkeit von Analyseergebnissen und Rahmenbedingungen
3. Aufwandsschätzung und Zeitplanung: je nach Verfahren: Paketierung der Datenmodelle, Anpassung Datenmodelle, Datenladen, Ausfallzeiten, Szenerien in Bezug auf Sandbox, Entwicklung, QAS und PRD-System (z.B. Transport bei Shell-Conversion)
4. Umsetzungsphase: Schritt für Schritt Migration der Datenmodelle, manuelle Anpassungen, je nach Verfahren: Datenladen
5. Testphase: Tests der Anwendungen nach der Systemkonvertierung
6. Go Live

Abb. 21: Projektablauf eines Migrationsprojekts auf SAP BW/4HANA

Conversion Guides der SAP als guter Einstieg ins Thema

• Conversion Guide for SAP BW/4HANA 1.0
• Conversion Guide for SAP BW/4HANA 2.0
• Task List Documentation for Conversion to SAP BW/4HANA