Migration von SAP BW 7.01 zu SAP BW/4HANA – ein Sprung in die Virtu­ali­sierung!

Eine SAP BW/4HANA Migra­tion ist sicher kein einfa­ches Unter­fangen. Eine beson­dere Wür­ze bekommt diese jedoch, wenn sie 3.x Daten­flüsse ein­schließt. In diesem Blogbei­trag werden wir die wich­tigen Er­folgs­faktoren eines SAP BW/4HANA Migra­tions­pro­jektes dar­stellen. Dabei be­deutet erfolg­reich in diesem Zu­sammen­hang nicht aus­schließlich die tech­ni­sche Migra­tion des SAP BW-Con­tents. Es bedeu­tet, dass unter Berück­sich­tigung der An­forde­rungen des Kun­den, der tech­no­logischen Möglich­kei­ten von SAP BW/4HANA und der sys­te­mischen Restrik­tionen der Ziel­archi­tektur eine neue Lösung unter SAP BW/4HANA er­schaffen wird. In unserem Projekt migrie­ren wir ein über Jahr­zehnte ge­wachsenes SAP BW7.01 System. Dieses bein­haltet ein Daten­volumen, welches das der SAP BW/4HANA-Ziel­architektur um Faktor acht über­steigt.

SAP BW/4HANA Migration

In-Place und Remote-Conver­sion schlie­ßen wir auf Grund der erläu­terten Gege­ben­hei­ten aus. Zudem haben wir fest­gestellt, dass wir nicht alle Daten aus dem Alt­system nach SAP BW/4HANA über­nehmen kö­nnen, was wir aber auch nicht mü­ssen. Bei ge­nau­e­rer Ana­lyse wurde er­kannt, dass ältere Daten auch nicht in­Memory benö­tigt werden. Also ver­stän­digten wir uns im Projekt darauf, die Da­ten der vergang­enen drei Jahre nach SAP BW/4HANA zu über­nehmen. Zudem haben wir im Projekt be­schlossen, alle älteren Daten im Alt­­system zu be­lassen, dieses aber als eine Art Cold-Store via SDI an das SAP BW/4HANA an­zu­bin­den. Das soll aber nicht The­ma dieses Blogs sein. Viel­mehr geht es darum, wie wir die Shell Conver­sion ge­zielt für unserer Sze­­nario genutzt haben. Zudem erläutern wir, welche Objek­te wir konver­tiert haben, welche nicht und warum diese nicht konvertiert wurden.

Step by Step vs. BigBang

In einem der­­artig gewach­­senen System wie in un­se­rem Anwen­­dungs­­fall finden wir nicht nur viele Daten, son­dern eben auch histo­risch gewach­sene Struk­turen. Darüber hinaus ergeben sich viele verschie­dene Lösungs­an­sätze für unter­­schied­lich schwie­rige Problem­stellungen. Um nicht in der Komple­xität der Migra­tion zu ver­sinken, haben wir uns ent­­schieden, das Ganze Step by Step anzu­gehen. Wir haben gar nicht erst ver­sucht, den gan­zen Content mit einem Mal oder sogar noch mit Daten (Remote Conver­sion) zu migrie­ren. Anfäng­liche Ana­lysen des Alt­systems zeig­ten große Opti­mierungs­poten­tiale hin­sicht­lich des Designs, der Perfor­mance und der Möglich­keiten der Vir­tua­lisie­rung (welche sich durch den techno­logischen Fort­schritt unter SAP BW/4HANA erge­ben). Aus diesem Grund und weil jede noch so steile Lern­kurve bei 0 ihren Ur­sprung hat, haben wir mit den Low Hanging Fruits be­gonnen.

Geziel­ter Ein­satz der Shell Con­ver­sion

Begi­nnend mit den Con­version Guides, der Ein­richtung der System­land­schaft (Sys­tem­­ver­bin­dun­gen, Trans­port­schiene, ODP-Frei­gabe der Data­Sourcen, etc.) und der Defi­nition des Scopes für unsere erste Itera­tion, haben wir zu­nächst alle rele­vanten Info-Objekte, inkl. aller ab­hängigen Info-Objekte und Attr­ibute mi­griert. Das funktio­nierte problem­los, weil keine Konver­tierung not­wendig war. Nicht migriert haben wir Daten­flüsse und Info­Provider trans­aktionaler Da­ten. An dieser Stelle besteht unserer Ansicht nach das größ­te Poten­tial mit SAP BW/­4HANA-Techno­logie zu opti­mieren, bzw. zu virtua­lisieren. Unse­rer Meinung nach werden wir nur auf diese Weise den Projekt­anfor­derungen hin­sicht­lich Per­formance, Wart­bar­keit und Daten­menge gerecht. Eine Über­sicht dessen, was wir letzt­lich mit dem Pro­gramm der Shell Con­version migriert haben, und was nicht, sehen Sie in den nach­folgenden Ab­bildungen.
Was haben wir konvertiert?
Was haben wir nicht konvertiert?

Alle Bilder auf dieser Seite © 2022. BIG.Cube GmbH. Alle Rechte vorbehalten.

Expli­zit zu er­wähnen ist die Migra­tion der Query-Ob­jekte. Das stellte uns An­fangs vor Pro­bleme, da das Pro­gramm bei der Aus­wahl der gewün­schten Query den dazu­gehörigen Multi­provider selek­tierte. Dieser muss in einen Compo­site Provider konver­tiert wer­den. Es prüft – egal ob aktiv oder in­aktiv – alle be­tei­­ligten Info-Objek­te, Calcu­lated Key Fi­gures, Varia­blen, InfoCubes, etc. und die davon ab­hängi­gen Objekte, und wiederum die davon ab­hängigen Objek­te usw.. Stellen Sie sich vor, was es bedeu­tet, eine Query, die eine Varia­ble für 0CALYEAR bein­haltet, zu migrie­ren. Unserer Erfah­rung nach ist es – je nach Kom­plexi­tät ein­facher, eine Kopie von zu mi­grie­renden Multi­pro­viders inkl. der Query im Alt­system zu machen. (Achtung: Sie benö­tigen min­des­­tens einen betei­ligten InfoCube, aber nicht die Daten­flüsse!)

Vir­tuali­sierung ist Key!

Wie im Ab­schnitt zuvor erläu­tert, ent­spricht es nicht dem An­spruch des Projek­tes, die Daten­flüsse und Info­Pro­vi­der der transak­tionalen Daten 1:1 zu migrie­ren. Was bringt uns das Chassis eines Ferraris mit dem Motor eines VW Golf’s? Wir haben uns ent­schie­den – dort wo möglich und sinnvoll – be­steh­en­de Lösungsansätze zu virtualisieren. Die fol­gen­de Abbildung zeigt eine schematische Ge­gen­über­stellung der Problematik zur Auflösung der „Bill of Ma­terial“.
Lösung unter SAP BW 7.01
Lösung unter SAP BW4HANA 2.0

Alle Bilder auf dieser Seite © 2022. BIG.Cube GmbH. Alle Rechte vorbehalten.

Die „Bill of Mate­rial“ (kurz BOM) ist aus techni­scher Sicht eine simple 1:n Ver­knüpfung zwischen Ma­teri­a­lien und Kompo­nenten, welche wiederum Materia­lien sind. Diese Kom­ponen­ten können jedoch auch ein­zeln ver­kauft wer­den, d.h. nur ein Bruch­teil der Materia­lien wird durch eine BOM auf­ge­löst. In SAP BW 7.01 wurde die Auf­lösung der BOM mangels Möglich­keiten in einer ABAP-Routine mit zahl­reichen LOOP’s imple­mentiert. Die gesamten Ver­­kaufs­­zahlen, auch die Daten, die nicht in der BOM aufgelöst werden, werden ein zusätzliches Mal per­sis­tiert. Diese zu­sätzliche Persistierung hat nicht nur zur Folge, dass die doppel­te Spei­cher­ka­pazität benötigt wird, son­dern auch zu­sätzliche War­tungs­auf­wän­de. Denn, was passiert, wenn die Bill of Material sich für ein Material än­dert? Die per­sis­tier­ten Daten müssen korrigiert werden. Durch die vollständige Virtualisierung dieser Pro­blem­stellung geben wir nicht nur Spei­cher­ka­pazität frei, wir erhalten darüber hinaus ein stets auf der aktuellen BOM basierendes Reporting, ohne diese manuelle berichtigen zu müssen.

Fazit zur SAP BW/4 HANA Migration

In diesem Bei­trag wurden die Faktoren und Erfahrungs­werte einer erfolg­reichen SAP BW/4HANA Migra­tion aufge­zeigt. Die Ent­schei­dung, die Shell Conversion ge­zielt zu nutzen, anstatt mit der Remote Conversion ganze Daten­flüsse inklu­sive Daten zu mi­grieren, haben wir be­wusst ge­troffen. Dem techno­logischen Fort­schritt von SAP BW/­4HANA zu SAP BW 7.01 wollen wir Rech­nung tragen und die Lösungs­ansätze des Alt­sys­tems neu designen. Dabei ha­ben wir vor allem auf die zahl­reichen Möglich­keiten der Virtua­lisierung gesetzt.

Verfasst von Christian Schultz

Mehr erfahren über SAP Analytics

Weitere spannende Themen aus unserem Newsroom

Innovation zum Nulltarif mit SAP BTP-Credits

Verwenden Sie ungenutzte SAP BTP-Credits sinnvoll – bevor sie verfallen....

Mehr lesen

SAP BTP: Unser Fokus – Unsere Kompetenz

In diesem Artikel erfahren Sie, wie unser ausgewiesener Expertenstatus in...

Mehr lesen

Forbes | Mit BIG.Cube Daten in Wettbewerbsvorteile verwandeln

In diesem Forbes Artikel erfahren Sie, wie BIG.Cube Unternehmen dabei...

Mehr lesen