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

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

DSAG Jahresrückblick 22

Rückblick zum DSAG Jahreskongress 2022

Diese Themen wurden auf dem DSAG Jahreskongress 2022 diskutiert.

Mehr lesen

Augmented Analytics Funktionen in der SAP Analytics Cloud (SAC)

Mit der SAC durch Augmented Analytics und Predictive Analytics Funk­tionen...

Mehr lesen
In wenigen Schritten im BW/4HANA Stories die auf einem Live Daten­modell zu SAP BW/4HANA auf­bauen.

Geod­aten­modell in SAC Live Ver­bin­dung

Wir zeigen ihnen in wenigen Schritten, wie sie im BW/4HANA...

Mehr lesen