Das strategische Potenzial des System-Cleanup bei der BW/4HANA-Conversion: Mehr als nur digitale Hausreinigung

Über Jahrzehnte hinweg entwickeln sich SAP-BW Systeme zu hochkomplexen, oft undurchsichtigen Gebilden. Neue Geschäftsanforderungen führen zu immer neuen Datenmodellen, während die ursprünglichen Lösungen häufig als „Schatten-Infrastruktur“ im System verbleiben. Dieser Wildwuchs besteht aus ungenutzten InfoObjects, verwaisten DSOs und InfoCubes, redundanten Prozessketten und individuellen ABAP-Entwicklungen, die eher historisch gewachsen sind als strukturiert geplant.

Ein moderner System-Cleanup setzt genau hier an. Er umfasst die methodische Identifikation, Bewertung und physische Entfernung all jener Elemente, die im operativen Betrieb oder für regulatorische Anforderungen keine Rolle mehr spielen. Dabei geht es nicht nur um das bloße Data Tiering. Es ist ein ganzheitlicher Ansatz, der die gesamte BW-Landschaft in ihrer technischen und funktionalen Tiefe evaluiert. Ziel ist es, absolute Transparenz zu schaffen, Redundanzen zu minimieren und ein „Lean Core“-Prinzip zu etablieren. Ein aufgeräumtes System bietet die notwendige Stabilität und Klarheit – zwei Faktoren, die für eine erfolgreiche Transformation unerlässlich sind.

Ein Punkt, der in der Praxis häufig zu Verzögerungen führt, ist das falsche Timing des Cleanups.

Viele Projektverantwortliche verlassen sich primär auf den SAP Readiness Check oder das BW/4HANA Transfer Cockpit (Transaktion RSB4HCONV). Diese Tools sind exzellent darin, technische Inkompatibilitäten aufzuzeigen – etwa wenn ein Objekttyp in BW/4HANA nicht mehr unterstützt wird. Eine kompakte Einführung in diese Werkzeuge bietet das SAP-Learning-Modul „Working with Migration Tools“, während SAP Note 2575059 die Voraussetzungen und Installationsschritte für den SAP Readiness Check im Detail beschreibt.

Doch hier liegt die Falle: Diese Pre-Checks erfassen die technische Existenz, aber nicht die fachliche Relevanz. Ein DSO oder ein InfoCube, welches seit fünf Jahren nicht mehr beladen oder abgefragt wurde, wird im Readiness-Check als „zu konvertierendes Objekt“ auftauchen. Das Projektteam investiert dann Zeit und Ressourcen, um ein Objekt zu analysieren, für das es möglicherweise keinen Business-Case gibt. Ein effektiver System-Cleanup sollte daher vor der offiziellen Vorbereitungsphase beginnen. Durch eine vorgelagerte Analyse der Nutzungsstatistiken (z. B. via Transaktion ST03 oder SCMON) können „tote“ Zweige des Datenbaums bereits eliminiert werden, bevor sie die Listen des Readiness-Checks unnötig aufblähen. Dies spart nicht nur Zeit in der Analysephase, sondern sorgt für eine wesentlich präzisere Projektplanung.

Die Herausforderung: Zeitaufwändige Abstimmungen mit den Fachbereichen lassen sich im laufenden Hauptprojekt kaum „nebenbei“ klären, ohne Termine und Ressourcen zu strapazieren. Jede zusätzliche Schleife erhöht das Risiko für Verzögerungen.

Die Lösung: Ein vorgelagertes Cleanup-Projekt schafft Abhilfe. Durch die bewusste zeitliche Entkopplung entsteht Raum für fundierte fachliche Klärungen. So starten Sie die eigentliche Conversion mit einem klar definierten, bereinigten Scope – fokussiert, strukturiert und deutlich risikoärmer.

Die Relevanz und Intensität des Cleanups hängen massiv davon ab, welchen Migrationspfad ein Unternehmen wählt. Jede Methode stellt unterschiedliche Anforderungen an den Zustand des Altsystems:

In-Place Conversion

Bei der In-Place-Methode wird das bestehende System schrittweise transformiert. Ein konsequentes Cleanup ist dabei essenziell. Da die technische Systembasis unverändert bleibt, werden bestehende Strukturen und Objekte vollständig in den Konvertierungsprozess übernommen. Nicht kompatible oder veraltete Objekte können dabei zu kritischen Blockaden führen und den Ablauf der Conversion beeinträchtigen oder inkonsistente Systemzustände verursachen. Eine systematische Bereinigung im Vorfeld ist daher eine zentrale Voraussetzung für einen stabilen und technisch erfolgreichen Transformationsprozess.

Remote Conversion

Bei diesem Ansatz wird ein neues BW/4HANA-System parallel zur bestehenden Landschaft aufgebaut. Die relevanten Datenmodelle und Datenbestände werden gezielt aus dem Altsystem übernommen. Auch wenn dieser Ansatz konzeptionell einen Neustart ermöglicht, ist ein vorgelagertes Cleanup im Quellsystem ausdrücklich empfehlenswert.

Es unterstützt eine klare Scope-Definition und stellt sicher, dass ausschließlich fachlich und technisch erforderliche Artefakte transferiert werden. Eine ungeprüfte 1:1-Übernahme hingegen würde die gewachsene Komplexität des Altsystems unverändert in die neue Systemlandschaft übertragen – mit entsprechenden Auswirkungen auf Wartbarkeit, Transparenz und Betrieb.

Shell Conversion

Ähnlich wie bei der Remote Conversion wird ein neues System aufgebaut, jedoch ohne Übernahme von Bewegungs- oder Stammdaten; migriert werden ausschließlich Metadaten. Der Schwerpunkt des Cleanups liegt daher primär auf der Modellierungsebene.

Da keine Datenmigration erfolgt, eröffnet dieser Ansatz die Möglichkeit, bestehende Modellierungsansätze kritisch zu hinterfragen und nicht mehr zeitgemäße Strukturen konsequent auszuschließen. In das Zielsystem werden ausschließlich fachlich und technisch valide Kernlogiken überführt. Dadurch entsteht eine schlanke, zukunftsfähige Modellarchitektur als Grundlage für den weiteren Ausbau. Eine übergreifende Beschreibung der Migrationspfade (In-Place, Remote, Shell) sowie der Voraussetzungen für den „B4H-Modus“ findet sich im SAP BW/4HANA Master Guide. Einen kompakten Überblick über die Unterschiede zwischen In-Place und Remote Conversion liefert zudem der SAP-Community-Beitrag „Quick Guide to SAP BW/4HANA Migration“.

Der vielleicht schlagkräftigste Grund für einen umfassenden Cleanup ist die Optimierung der Infrastrukturkosten. SAP BW/4HANA basiert auf der In-Memory-Technologie von SAP HANA. Im Gegensatz zu klassischen festplattenbasierten Datenbanken wird hier der Arbeitsspeicher (RAM) zur primären Ressource. RAM ist leistungsstark, aber im Vergleich zu Festplattenspeicher deutlich teurer.

Jedes Gigabyte an Altdaten, das nicht gelöscht oder archiviert wird, fließt direkt in das HANA Sizing ein. In der Praxis sehen wir häufig, dass durch das Löschen von PSA-Tabellen, alten Change-Logs und veralteten Request-Statistiken das benötigte RAM-Volumen um 20 % bis 40 % reduziert werden kann. Dies führt zu einer unmittelbaren Senkung der Lizenz- und Hosting-Kosten – ein Argument, das besonders bei der Cloud-Migration (z. B. auf RISE with SAP) massiv an Bedeutung gewinnt. Das Potenzial von Cleanup-Maßnahmen für den RAM-Bedarf lässt sich mit dem HANA BW Sizing Report (/SDF/HANA_BW_SIZING) gemäß SAP Note 2610534 im Detail quantifizieren.

Ein überladenes System erhöht die Fehleranfälligkeit während der Conversion erheblich. Inkompatible Altlasten wie 3.x-Datenflüsse, veraltete Transformationen oder inkonsistente InfoObjects stellen typische Stolpersteine dar, die Projektverzögerungen verursachen können.

Das BW/4HANA Transfer Cockpit validiert jedes Objekt. Je weniger veraltete oder unnötige Datenstrukturen vorhanden sind, desto schneller lassen sich die automatisierten Tasklisten abarbeiten. Ein bereinigtes System erleichtert zudem die Fehlersuche: Treten während der Migration Probleme auf, lassen sich die Ursachen in einer verschlankten Umgebung deutlich schneller identifizieren und beheben.

Dieser Ansatz erhöht die Stabilität der neuen Plattform und unterstützt die Einhaltung der engen Zeitfenster während der produktiven Umstellung (Downtime). Die typischen Herausforderungen, Risiken und Cleanup-relevanten Reports im Rahmen einer BW/4HANA-Migration werden im SAP-Community-Beitrag „SAP BW/4HANA Migration Analysis“ sowie im SAP BW/4HANA Conversion Guide ausführlich beschrieben.

Um einen effektiven Cleanup durchzuführen, müssen verschiedene Bestandteile des Systems analysiert werden. Dabei gilt es zu unterscheiden, welche Aufgaben strategisch im Vorfeld (Pre-Cleanup) sinnvoll sind und welche technisch im Rahmen der Vorbereitungsphase durch die SAP-Tools unterstützt werden:

Objektebene (Strategischer Fokus): Die Identifikation und Löschung ungenutzter Queries, InfoProvider und MultiProvider ist eine klassische Aufgabe für die Zeit vor dem Readiness-Check. Da Test-Objekte und verwaiste Datenmodelle das Transfer-Cockpit unnötig mit Warnungen füllen, reduziert ihre Entfernung die Komplexität der Konvertierung erheblich. Zur Identifikation inaktiver Pfade hilft eine detaillierte Metadaten-Analyse: Beispielhaft lässt sich über die Tabellen RSBKREQUEST (für DTPs) und RSLDPIO (für InfoPackages) präzise ermitteln, wann ein Ladeprozess letztmalig aktiv war, um so Rückschlüsse auf die Relevanz ganzer Datenflüsse zu ziehen.

Datenebene (Sizing & Archivierung): In BW/4HANA wird das klassische Request-Management durch das neue RSPM ersetzt. Zwar überführt das Transfer-Tool PSA-Daten und Change-Logs technisch in die neue Welt, doch aus Sizing-Sicht ist ein manueller Cleanup vorab (Löschen oder Archivierung in einen „Cold Store“) der größte Hebel, um RAM-Kosten in HANA einzusparen. Hier bieten sich – insbesondere im Kontext personenbezogener Daten – weiterführende Ansätze zur Datenanonymisierung an, wie sie beispielsweise im movisco-Beitrag „anovisco – Die movisco-Lösung zur Datenanonymisierung in SAP BW/4HANA“.

Prozessebene (Stabilität): Auf der Prozessebene weisen bestehende Prozessketten häufig inaktive Pfade oder technologisch obsolete Befehle auf. Ein gezielter Cleanup vor der Conversion stellt sicher, dass lediglich die geschäftskritischen und produktiv genutzten Logiken bereinigt übernommen werden. Diese Reduktion der Komplexität minimiert das Fehlerrisiko bei der automatisierten Überführung in den BW/4-Standard und sichert die langfristige Stabilität der Datenbewirtschaftung.

Entwicklungsebene (Vorbereitungsphase): Die detaillierte Analyse von Custom Code hinsichtlich HANA-Kompatibilität erfolgt üblicherweise erst in der Vorbereitungsphase, beispielsweise mithilfe des Reports RS_B4HANA_CODE_SCAN. Wird jedoch bereits im Vorfeld nachweislich ungenutzter Code (z. B. identifiziert über SCMON) entfernt, reduziert sich der Wartungs- und Testaufwand für die Konvertierung erheblich, da inaktiver und potenziell inkompatibler Code nicht mehr berücksichtigt werden muss. Für ältere BW-Releases, in denen das Transfer Cockpit noch nicht direkt verfügbar ist, beschreibt SAP Note 2448571 ein geeignetes Pre-Check-Tool, das bei der Vorbereitung unterstützt. Wie das Löschen von technischem Content in der Praxis aussehen kann, illustriert zudem der Beitrag „A BW/4HANA Conversion in Pictures“.

Ein erfolgreicher Cleanup folgt einem klaren, iterativen Prozess:

Technische Analyse: Einsatz von Tools zur Ermittlung der tatsächlichen Nutzung (z.B. wann wurde eine Query zuletzt ausgeführt?).

Fachliche Validierung: Abgleich der technischen Ergebnisse mit den Fachbereichen. Hier wird entschieden: Ist das Objekt wirklich obsolet oder wird es für seltene Audits benötigt?

Klassifizierung: Einteilung der Objekte in „Löschen“, „Archivieren“ oder „Konvertieren“.

Durchführung: Physische Löschung der Daten und Objekte in Wellen, beginnend im Entwicklungssystem und durchlaufend bis zur Produktion.

Monitoring: Überprüfung der Systemstabilität nach den Löschvorgängen.

Der SAP BW/4HANA Conversion Guide beschreibt diesen Ablauf und die zugehörigen Aktivitäten im Rahmen der Phasen „Preparation“ und „Realization“ detailliert und dient als zentrale Referenz für die Planung eines Cleanup-Projekts.