Blog

Viele Wege führen zu SAP BW/4HANA. Genauer gesagt sind es vier. Doch welche ist die beste Conversion, wenn es darum geht, von BW auf BW/4HANA zu wechseln? Anhand eines konkreten Beispiels aus unserem SRB-Kundenalltag wollen wir im Folgenden die Vor- und Nachteile unterschiedlicher Methoden ergründen.

Unsere Ausgangssituation ist eine, die auch in vielen, heimischen Unternehmen bekannt sein dürfte: Über Jahre hinweg ist bei unserem Kunden die BW-Landschaft, basierend auf BW 7.5 und einer SQL-Datenbank (Non HDB), gewachsen und hat sich dort als zentrale Datendrehscheibe im Unternehmen etabliert. Entsprechendes Augenmerk sollte also daraufgelegt werden, diese Plattform in ein neues Zeitalter überzuführen und auf BW/4HANA zu migrieren.

Der einfachste Weg ist nicht immer der beste

Prinzipiell gibt es, wie schon erwähnt, vier Varianten für den Wechsel von BW auf BW/4HANA: Die In-place Conversion, die Remote Conversion, die Shell Conversion und die Green-field-Methode.

Auf den ersten Blick scheint die In-Place Conversion der einfachste Weg zu sein. Der naheliegende Grund: Für den Endanwender ändert sich am wenigsten: Stichwort gleiche SID. Allerdings wird eine In-place Migration aufwendig, wenn noch viele 3.x Datenflüsse im Einsatz sind. Zudem gibt es einen entsprechenden Bedarf an Re-Design bzw. einen Wegfall von Applikationen.

Das alles trägt schwer, wenn man bedenkt, dass ein Unternehmen nicht den Umweg über BW on HANA gehen, sondern sehr rasch den Nutzen von BW/4HANA sehen und entsprechendes Know-how aufbauen will. Daher macht es Sinn, auch einen Blick auf andere Varianten – insbesondere Remote Conversion und Shell Conversion – zu werfen.

Das Beste aus unterschiedlichen Welten

In unserem Beispiel sollte im POC die Variante Remote Conversion analysiert werden. Das führte zu folgenden Arbeitspaketen:

• Installation BW/4HANA 2.07
• Installation DIMS auf BW und Implementierung vieler Hinweise (Z_SAP_BW_NOTE_ANALYZER; Programm zur Analyse, welche SAP Meldungen eingespielt werden müssen)
• System-Architektur Namenskonvention neu
• Durchführung der Konvertierung
• BADI Variablen Exit
• Erstellung Analysis Office Workbooks (Altsystem BEX Analyzer)
• Rollen/Berechtigung
• Endkunden-Präsentation

Soweit der Plan. Schnell hat sich gezeigt, dass die Arbeiten Z_SAP_BW_NOTE_ANALYZER recht aufwendig werden können, wenn das Original-BW-System einen niedrigen Patch-Stand hat. In unserem Beispiel war das BW-System zwar erst vor einem halben Jahr gepatcht worden. Dennoch musste auch hier Zeit investiert werden.

Die ersten Tests wurden dann mittels Shell Conversion durchgeführt – und zu unserer Überraschung sind alle Konvertierungstransporte beim ersten Mal fehlerfrei importiert worden. Dadurch ermutigt haben wir uns langsam gesteigert und uns an Infoobjekte, InfoCube, Multiprovider, Queries und Transformationen gewagt. Erfolgreich.

Anschließend haben wir versucht einen Provider mittels Remote Conversion (wie Shell, jedoch mit Daten) zu migrieren. Allerdings gestaltet sich eine Remote-Konvertierung um einiges komplexer als eine Shell-Konvertierung, besonders im Hinblick auf die gesamte Systemlandschaft (Dev – Qual – Produktion).

So hat uns bei der Konvertierung immer gestört, dass ein Wechsel der technischen Namen nicht möglich ist. Seit wir aber eine Möglichkeit für den Wechsel dieser Namen bei der Shell-Konvertierung gefunden haben, ist diese auch für uns die bevorzugte Lösung. Die Daten werden dann entweder wieder vom ERP über eine ODP-Quellsystem geladen oder über eine direkte ODP-BW-Anbindung aus dem Original-System geladen.

Der alte CMOD Variablen Exit wurde als BADI-Klasse auf BW/4HANA nachgebaut.  SAP empfiehlt an sich den Variablen-Umbau direkt auf dem bestehenden BW-System, aber wir wollten am bestehenden BW-System keine Retests durchführen.

Durch die Flexibilität bezüglich der neuen technischen Namen kann die shell-Konvertierung punktuell auch eine Green-Infield Installation sinnvoll unterstützen.

Lessons Learned – auf Umwegen zum Ziel

Zusammenfassend lässt sich bei diesem Beispiel sagen, dass unser Kunde zwar das eigentliche Projektziel Remote Conversion nicht realisiert hat, trotzdem mit dem Ergebnis mit der Shell Conversion sehr zufrieden ist. Die Gründe liegen vor allem darin, dass eine Shell-Konvertierung wesentlich flexibler als die Remote-Konvertierung ist. Insbesondere, weil auch die technischen Namen angepasst werden können.

Die technische Migration hat einwandfrei funktioniert, und die fehlenden Daten können einfach über ODP-BW-Verbindung vom alten BW-System oder vom ERP nachgeladen werden. Zusätzlicher Nutzen: Für eine Shell-Konvertierung ist auch kein DIMS-Addon notwendig, und es sind weniger Hinweise einzubauen.

Alles in allem lässt sich sagen: Jede Art der Konvertierung hat ihre Vor- und Nachteile. Am Ende des Tages kommt es auf die individuelle Zusammenstellung des BW und die gewünschten Outcomes an, welche Methode oder gar welcher Mix von Methoden sich am effizientesten und einfachsten erweist. Auch wenn man bereits einen Favoriten für sich gefunden hat, so ist die Analyze Phase unumgänglich, um die richtige Konvertierung zu finden.

SRB – Ihr Partner für eine erfolgreiche Conversion zu BW/4HANA

Wollen auch Sie wissen, was für Sie der beste Weg zu SAP BW/4HANA ist? Können wir auch Sie auf Ihrem ganz persönlichen Weg zu einer erfolgreichen Conversion unterstützen? Kontaktieren Sie mich einfach unter l.juen@srb.at.