Erfahrungen mit BW/4HANA Conversions

Die folgenden wesentlichen Schlüsselfragen werden in Kundenprojekten regelmäßig diskutiert in Bezug auf die vier Verfahren – wobei es natürlich noch weitere Gesichtspunkte gibt.

• Greenfield-Ansatz: Es kann zwar weiterentwickelt werden, aber man muss eventuell auf dem neuen System doppelt weiterentwickeln, weil das neue System noch nicht live ist. Hier sollte man sich darauf konzentrieren, überhaupt alles neu zu entwickeln.
• In-Place Conversion: Es kann einfach weiterentwickelt werden. Wenn ein Datenmodell konvertiert ist, muss in der neuen Technik weiterentwickelt werden, nur nicht genau in dem Moment, in dem bestimmte Objekte oder ein bestimmter Scope konvertiert werden. Grundsätzlich sollte bei der Weiterentwicklung darauf geachtet werden, nur neue Objekte zu verwenden.
• Remote Conversion: Hier sollte die Weiterentwicklung gestoppt werden. Transferierte Datenmodelle können nicht nochmals transferiert werden. Wird ein „Big Bang“ Szenario überlegt, bei dem das System an einem Wochenende konvertiert wird, sollte man während der gesamten Projektlaufzeit auf eine Weiterentwicklung verzichten, vom Start auf der Sandbox bis zur Umstellung. Das sind in der Regel mehrere Monate.
• Shell Converson: Da keine Daten enthalten sind, ist man etwas flexibler und könnte eingeschränkt weiterentwickeln. Je nach Szenario kann man auf dem Ziel weiterentwickeln, sofern die Datenmodelle separierbar sind. Gegebenenfalls muss man doppelt entwickeln

Abb. 3: Möglichkeit der parallelen Weiterentwicklung je nach gewähltem Konversionsverfahren

• Greenfield Ansatz: Wenn S/4 mit größeren betriebswirtschaftlichen Änderungen eingeführt wird, dann ist dieser Ansatz zu bevorzugen. Denn es ist zu überlegen, ob die Datenmodelle auf dem Altsystem noch sinnvoll sind oder man nicht analog zum S/4 System größere Änderungen an den Datenmodellen durchführen muss.
• In-Place Conversion: Wird im ERP-Bereich eine rein technische Migration auf S/4 durchgeführt, kann die In-Place Conversion gewählt werden, weil im BW-Umfeld dann keine Änderungen durch die S/4-Umstellung zu erwarten sind.
• Remote Conversion und Shell Conversion: Bei diesen beiden Verfahren spielt die S/4 Einführung keine Rolle bzw. die Bewertung ist analog zur In-Place Conversion.

Abb. 4: Welches Konversionsverfahren eignet sich bei einer Einführung von S/4

• Greenfield Ansatz: Ein doppeltes System führt zu doppelten Betriebskosten während der gesamten Projekt-Laufzeit. Außerdem ist die Projekt-Laufzeit im Regelfall deutlich höher als bei Remote und Shell Conversion. Dieser Ansatz verursacht in der Regel die höchsten Kosten.
• In-Place Conversion: Keine Mehrkosten gegenüber der bisherigen Situation, abgesehen von der Sandbox. Die Betriebskosten für die Landschaft bleiben im Wesentlichen die des Regelbetriebs.
• Remote und Shell Conversion: Weitgehend doppelte Betriebskosten während der gesamten Projekt-Laufzeit. Allerdings müssen nicht alle Systeme von Anfang an zur Verfügung stehen und die Projektlaufzeit ist kürzer als beim Greenfield-Ansatz.

Abb. 5: Betriebskosten je nach Konversionsverfahren

• Greenfield Ansatz: Sehr hoher Zeitaufwand (gegenüber den anderen Verfahren), da alle Datenmodelle neu entwickelt werden müssen. Dafür benötigt man entweder mehr Personal oder mehr Zeit.
• In-Place Conversion: Je nach Systemumfang und Komplexität der Datenmodelle. Man unterliegt aber keinem Zeitdruck und kann Pausen einlegen. Voraussichtlich dauert es mehrere Monate, der Zeitaufwand ist aber in der Regel deutlich geringer als beim Greenfield-Ansatz.
• Remote Conversion: Da Datenmodelle nur per Transport übertragen werden müssen und keine Neuentwicklung stattfindet, ist die Projektlaufzeit wesentlich kürzer als beim Greenfield Ansatz – je nach Systemumfang und Komplexität der Datenmodelle. Die Projekt-Laufzeit nimmt mehrere Monate in Anspruch, aber die Umstellung der Landschaft ist oft in wenigen Wochen durchführbar (oder Tagen bei einem „Big Bang-Szenario“). Eine sehr gute Vorbereitung ist dafür allerdings erforderlich.
• Shell Conversion: Je nach Systemumfang und Komplexität der Datenmodelle unterschiedlich. Die Projekt-Laufzeit dauert mehrere Monate. Hier ist man flexibler als bei der Remote Conversion, allerdings muss der Datenbestand neu aufgebaut werden, was bei einem größeren System zusätzlich einen erheblichen Zeitaufwand bedeuten kann.

Abb. 6: Zeitaufwand je nach Konversionsverfahren

• Greenfield Ansatz: Für die Endanwenderinnen und Endanwender bedeutet es eine komplette Umstellung, weil alles ganz neu ist (neue Berichte, neue Zugangsdaten, Server, URLs, ggf. neue Tools). Unter Umständen müssen sie parallel mit zwei Systemen arbeiten – für neue Anwendungen auf dem Neusystem und für alte Anwendungen auf dem Altsystem.
• In-Place Conversion: Die WAD-Berichte und Bex-Arbeitsmappen können Schritt für Schritt von moderneren Technologien abgelöst werden. Die User müssen sich im Vorfeld umgewöhnen, es gibt aber keinen Zeitdruck. Ansonsten keine Änderungen.
• Remote Conversion: Die User benötigen neue Zugangsdaten (Server, URLs, ggf. neue Tools). Aber die Berichte sind im Wesentlichen so, wie sie vorher waren. Sie müssten unter Umständen einige Tage oder Wochen mit zwei BW-Systemen arbeiten (abhängig vom gewählten Szenario, beim „Big Bang-Szenario“ fällt dies weg).
• Shell Conversion: unterschiedliche Auswirkung je nach Systemumfang und Komplexität der Datenmodelle. Die Projekt-Laufzeit dauert mehrere Monate. Die User müssten unter Umständen länger mit zwei BW-Systemen arbeiten. Die Frage ist, wie der Umgang mit Altlasten erfolgt (alte Datenmodelle, alte ABAPs)?

Abb. 7: Umstellungsaufwand für User je nach Konversionsverfahren

• Greenfield Ansatz: Kein Problem – die Altlasten verbleiben auf dem Alt-System.
• In-Place Conversion: Alt-Lasten müssen bereinigt werden, soweit sie die Konvertierung betreffen. Der Konversionsprozess verlangt, dass alle alten Datenmodelle entweder gelöscht oder konvertiert werden. Alte ABAPs können – soweit sie die Konvertierung technisch nicht beeinträchtigen – im System verbleiben (d.h. solche Altlasten verbleiben bei diesem Verfahren in der Regel im System). Das Löschen alter Datenmodelle kann aufwändig sein.
• Remote und Shell Conversion: Kein Problem – Altlasten verbleiben auf dem Alt-System. Allerdings müssen suboptimale Datenmodelle unter Umständen mit übernommen werden.

Abb. 8: Umgang mit Altlasten je nach Konversionsverfahren

• Greenfield Ansatz: Unter Umständen Datenübernahme aus Alt-BW, wenn möglich. Eventuell gibt es keine vollständige Kongruenz zwischen den alten und neuen Datenmodellen. Es ist denkbar, dass man im Alt-BW nicht die vollständigen Daten für die neuen Datenmodelle hat oder nicht die Daten in der zeitlichen Historie vorliegen, wie gewünscht.
• In-Place Conversion: Kein Problem – Daten bleiben bei Konvertierung der Datenmodelle erhalten.
• Remote Conversion: Kein Problem – Daten werden vom Alt-BW übernommen.
• Shell Conversion: Es sollte im Regelfall kein Problem sein, da man im Zweifel die Daten aus dem Alt-BW übernehmen kann.

Abb. 9: Datenübernahme je nach Konversionsverfahren

• Greenfield Ansatz: Es gibt keine Ausfallzeiten, solange man sich im Aufbau befindet. Die Frage ist, ob man schrittweise auf das neue System umstellt oder am Ende eine große Umstellung für alle Anwender durchführt.
• In-Place Conversion: Hier entstehen immer mal kurze Ausfallzeiten für aktuell konvertierte Datenmodelle, maximal sind dies ein paar Stunden. Das spielt für den Regelbetrieb erfahrungsgemäß keine Rolle. Hinzukommt die Ausfallzeit für die technische Konvertierung (wie bei einem Upgrade).
• Remote Conversion: Bei „Big Bang“-Szenario entsteht einige Tage ein Ausfall während der Umstellung, vergleichbar mit der Ausfallzeit für die technischen Konvertierung bei der In-Place Conversion.
• Shell Conversion: Es gibt keine richtige Ausfallzeit, nur gegebenenfalls am Ende bei einer großen Umstellung der User auf das neue System, wenn sie nicht schrittweise erfolgt.

Abb. 10: Ausfallzeiten je nach Konversionsverfahren

• Greenfield Ansatz: Bei diesem Ansatz entsteht kein Problem, da alles neu entwickelt wird. D.h. alle Objektnamen können konsequent der festgelegten Namenskonvention folgen.
• In-Place Conversion: Die technischen Namen werden übernommen. Wird ein InfoCube – der oft ein C im Namen enthält – in ein ADSO konvertiert, bleibt der Name mit dem C erhalten. Da die Datenmodelle mit den Daten konvertiert werden, können die Namen auch nicht so einfach geändert werden. Man müsste das Objekt mit dem korrekten Namen neu anlegen und dann die Daten aus dem alten Objekt in das neue übertragen. Da dies sehr aufwändig ist, wird auf eine Änderung der technischen Namen in der Regel verzichtet und in Kauf genommen, dass die Namenskonvention nicht eingehalten werden kann.
• Remote Conversion: Die technischen Namen werden übernommen, auch hier ist eine Änderung nicht leicht möglich, da die Daten mit übernommen werden. Daher kann die Namenskonvention – analog zur InPlace Conversion – nicht eingehalten werden.
• Shell Conversion: Auch hier werden die technischen Namen übernommen. Aber da die Objekte zunächst keine Daten enthalten, könnte man die Objekte verhältnismäßig einfach mit korrekten Namen (als Kopie der Original-Objekte) neu anlegen (plus Übertragung von Transformation und DTP). Trotzdem bedeutet das einige Zusatzaufwände.

Abb. 11: Technische Objektnamen je nach Konversionsverfahren

• Bei Greenfield, Remote und Shell Ansatz müssen zwei BW-System-Landschaften über einen längeren Zeitraum parallel beladen und betrie-ben werden. Für die technische Administration und für die Betreuung für die Projektlaufzeit bedeutet dies einen doppelten Aufwand.
• In-Place Conversion: Hier sind die geringsten Änderungen im Regelbetrieb zu erwarten, da der Regelbetrieb unverändert weiterläuft. Die BW- und technischen Betreuung im Rechenzentrum bemerken kaum etwas. Gegebenenfalls ändern sich technische Details (z.B. fallen bestimmte Schritte in Prozessketten weg oder ändern sich).

Abb. 12: Folgen der Umstellung auf den Regelbetrieb je nach Konversionsverfahren

Wichtige Punkte, die in den bisherigen Workshops regelmäßig aufgekommen sind:

• Ist eine Weiterentwicklung uneingeschränkt möglich? Dies ist bei der In-Place Konversion der Fall.
• Die S/4 Einführung spielte im Rahmen bisheriger BW/4-Projekte zumeist keine Rolle, da die betreffenden Unternehmen keine größeren betriebswirtschaftlichen Änderungen beim Umstieg auf S/4 planten.
• Die Zusatzkosten für den Betrieb einer zweiten BW-Landschaft fallen meist hoch aus und Unternehmen versuchen, diese Zusatzkosten zu vermeiden.
• Meist bevorzugen die Unternehmen eine Schritt-für-Schritt Umstellung ohne Zeitdruck (kein „Big Bang“-Szenario) und möchten auch nicht, dass die Anwender auf zwei Systemen arbeiten müssen.
• Man möchte möglichst geringe Änderungen für die Anwender.
• Die Ausfallzeiten spielen eine untergeordnete Rolle, es wird hingenommen, dass kurze Ausfallzeiten bei der Konvertierung von Datenmodellen (s. In-Place Conversion) entstehen.
• Es spielt auch meist keine Rolle, dass die Namenskonvention nicht vollständig eingehalten werden kann.

Daher entscheiden sich die meisten Unternehmen am Ende für die In-Place Konvertierung.

Bei der In-Place Konvertierung kennt das System vier Betriebs-Modi, die man kennen sollte, um den Projektablauf besser zu verstehen.

1. Im BW-Modus – Standard-Modus:
   o alles läuft, wie man es auf BW-Systemen kennt (keine Einschränkungen bis auf die Verwendung von Eclipse für InfoObjekte)
   o zusätzlich können neue Objekte mit Eclipse verwendet werden
2. Im Kompatibilitäts-Modus:
   o es können keine Alt-Objekte mehr angelegt werden (aber bearbeitet und transportiert über Ausnahme-Liste)
   o bestehende Szenarien mit Alt-Objekten laufen normal weiter, InfoCubes laufen weiter
   o BEx Tools können nur noch eingeschränkt verwendet werden, es kann nichts Neues mehr entwickelt werden
3. B4H-Modus
   o Keine Alt-Objekte mehr unterstützt (auch kein Transport)
   o BEx-Tools können nicht mehr verwendet werden, BEx-Arbeitsmappen und WAD-Berichte werden gelöscht, Altobjekte wie InfoCubes, DSOs, Infosets und Multiprovider müssen bei Aktivierung des B4H-Modus konvertiert bzw. gelöscht sein.
4. Ready For Conversion Modus
   o Keine Nutzung für BW-Anwender mehr möglich – die technische Konvertierung folgt unmittelbar. Dies ist der letzte Schritt, bevor das System konvertiert wird.

Grob betrachtet benötigt man

• eine Vorbereitungsphase von einigen Tagen oder Wochen,
• gefolgt von der Umsetzungsphase, die mehrere Monate in Anspruch nimmt. Das System wird im Kompabilitätsmodus betrieben und alle Datenmodelle werden umgesetzt.
• Es folgt der Switch auf den B4H-Modus, der mit Bereinigungstätigkeiten einige Tage oder Wochen dauert.
• Am Ende folgt die technische Konvertierung, die wie ein Upgrade zu sehen ist und zwei bis vier Monate in Anspruch nimmt.

Abb. 13: Projektablauf bei In-Place Conversion

Es müssen einige vorbereitende Schritte durchgeführt werden:

• Technische Voraussetzungen: Das System muss auf HANA und BW 7.50 laufen (+ Starter AddOn installieren)
• Note Analyzer: aktuellste Hinweise müssen eingespielt werden (Hinweis 2383530)
• Housekeeping: BW-Daten und Verwaltungsdaten bereinigen (STC01/ RSREQREDUCE) – ggf. alte Datenmodelle löschen
• Neue Quellsysteme (Typ ODP) anlegen bzw. notwendige Schritte prüfen
• 3.x-Datenflüsse nach 7.x migrieren (oder löschen)
• Ablösung der BEx Tools planen – wie und wann wird umgestellt (Analyzer, WAD, Report-Designer)
• PreCheck durchführen (über das Transfer-Cockpit RSB4HCONV). Der PreCheck listet alle Objekte auf, die bearbeitet werden müssen. Man sollte ihn im Verlauf des Projekts alle zwei bis vier Wochen ausführen um den Fortschritt zu prüfen.
• Code Scanner ausführen (über Transfer-Cockpit RSB4HCONV) und ABAP-Coding anpassen
• Queries und Variablen analysieren
• Allgemeine Punkte klären (ca. 25 – Beispiele: Ersatz für PSA, Request-Übertragung, Berechtigungen, 0LOGSYS, AddOns etc.)
• Scopes definieren, d.h. welche Pakete werden wann und wie umgesetzt.

• Schritt für Schritt: Alle Datenmodelle müssen umgesetzt werden, zunächst auf
  o Entwicklungssystem, dann auf
  o Q-System, zum Schluss auf dem
  o Produktiv-System
• Das Schema dabei ist immer:
  o Checklauf durchführen für die Datenmodelle
  o Manuelle Prüfung
  o Manuelle Korrekturen
  o Scope-Transfer ausführen, die Datenmodelle werden umgesetzt, beispielsweise von InfoCube zu ADSO, von Mulitprovider zu Composite Provider…
• Jeweils nach Transfer eines Scopes:
  o Durchführen von Tests
  o Notwendige Korrekturen vornehmen
  o Transport der Korrekturen auf Folgesysteme
• Anpassung der Berechtigungen (falls nicht schon vorab durchgeführt)
• BEx Analyzer, BEx WAD Berichte und BEx Report Designer Berichte ersetzen
• Bereinigungsmaßnahmen
  o PreCheck regelmäßig wiederholen
  o Im Rahmen der Konvertierung auf Basis des PreChecks weitere Bereinigungen durchführen (verstärkt zum Ende der Umsetzungsphase)

Soll der B4H Modus aktiviert werden, sind zunächst folgende Schritte auszuführen:

• Finale Bereinigungsschritte durchführen
  o PreCheck muss vollständig bereinigt sein
  o Rest-Objekte entweder konvertieren oder löschen!
• Alle BEx Anwendungen final ablösen
  o Alle BEx Objekte werden bei Modus-Umschaltung gelöscht
• Technischen Content löschen
  o muss manuell mit Report gelöscht werden.
• CMOD-Exit deaktivieren (alle Exit-Variablen müssen umgestellt sein)
• B4H-Modus aktivieren (im Transfer-Cockpit RSB4HCONV)

• Zunächst Systemkopie von P-System durchführen
• Test-Lauf auf Systemkopie (Sandbox)
• Während des technischen Laufs: „READY for Conversion Modus“ aktivieren
  o Dies kann aufwändig sein!
  o Alle Fehler genau dokumentieren.
  o Gegebenenfalls mögliche Maßnahmen vorab auf anderen Systemen vorbereiten
• Anwendungstests auf Sandbox
• Korrekturmaßnahmen auf Sandbox
• dann die übrigen Systeme konvertieren.
• je nach Testdauer auf Sandbox weiterer Test-Lauf auf Q-System.

Abb. 14: Projektablauf der technischen Konvertierung