BW/4HANA: Plädoyer für die InPlace Konvertierung 

Situation 

Die Uhr tickt. Die Wartung für 7.5 BW-Systeme (BW7x) endet im Jahr 2027 bzw. 2030. Es wird zunehmend dringlich, für jedes BW-System eine klare Zukunftsstrategie zu entwickeln. Die Zeit des Zögerns ist aus meiner Sicht vorbei, da SAP mittlerweile Klarheit darüber geschaffen hat, wie es mit BW/4HANA (BW4) weitergeht. Falls Sie bislang noch keine Strategie erarbeitet haben, sollten Sie sich in jedem Fall entsprechend vorbereiten, um später mehr Flexibilität zu gewinnen. 

Welche Möglichkeiten gibt es für bestehende BW7x Systeme?  

Option 1: BW soll bleiben und ein Upgrade auf BW4 wird angestrebt 
Option 2: BW soll erst mal bleiben und durch andere Tools ergänzt/ersetzt werden. BW4 wird vermutlich notwendig sein.  
Option 3: BW wird abgestellt und/oder durch alternative Lösungen ersetzt werden. 

Wenn die Entscheidung für Option 3 steht, kann man eigentlich hier aufhören zu lesen. Dennoch wäre es nicht überraschend, wenn Unternehmen, die diesen Pfad einschlagen, feststellen, dass das Abstellen oder Ersetzen der bestehenden Lösungen nicht so unkompliziert ist, wie es zunächst erscheint. Falls es eine geringe Möglichkeit gibt, von Option 3 zu Option 2 zu wechseln, könnte es sich lohnen, weiterzulesen. Vorbereitende Maßnahmen könnten in dieser Hinsicht sinnvoll sein. 

Was ist im System und was wird gebraucht?  

Unabhängig von der gewählten Strategie ist es entscheidend, zu wissen, welche Elemente sich in meinem System befinden und welche tatsächlich noch benötigt werden. In vielen Systemen werden kontinuierlich neue Anwendungen und Modelle erstellt, aber nicht mehr genutzte Elemente werden selten bereinigt, wenn sie nicht mehr verwendet werden. Es ist notwendig, eine Liste von Anwendungen/Modellen zu erstellen, die später, in welcher Form auch immer, weiterverwendet werden sollen. 

Kann DataSphere eine Rolle spielen? 

Eine Anmerkung zum Thema DataSphere ist hier angebracht. SAP positioniert dieses Produkt als den natürlichen Nachfolger von BW7x und BW4. In den letzten Jahren hat es erhebliche Fortschritte gemacht. Dennoch muss sorgfältig geprüft werden, ob es heute wirklich geeignet ist, ein BW7x-System zu ersetzen. Die BW-Systeme, welche ich in den letzten 20 Jahren gesehen habe, wären damit ohne fundamentale Umbauten und funktionale Änderungen/Einschränkungen nicht abzulösen (auch unter Berücksichtigung der Bridge). Ähnliche Herausforderungen treten im Übrigen auch beim Wechsel von BW zu Nicht-SAP-Tools auf. 

Warum InPlace? 

Neben Green- oder Brownfield Ansätzen gibt es auch die von der SAP angeboten Transfer Tools (Remote, Shell, InPlace) um ein bestehendes BW7x System Richtung BW4 zu konvertieren. Hierzu lassen sich umfangreiche Informationen finden. Es gilt immer noch, was ich 2018 zu dem Thema geschrieben habe: Which road to take to BW/4HANA? 

Nachdem wir bereits erfolgreich einige In-Place-Konvertierungen vorbereitet und durchgeführt haben, möchte ich an dieser Stelle die besonderen Vorteile der In-Place-Konvertierung hervorheben und potenzielle Nachteile bzw. Stolpersteine auflisten. 

Was sind die Vorteile einer InPlace Konvertierung?  

Man kann sofort loslegen  

Wenn die Voraussetzungen erfüllt sind (BW 7.5 on HANA mit einem einigermaßen aktuellen Support Package Level) und man weiß, was weiterhin benötigt wird, dann kann unverzüglich losgelegt werden. Zuallererst sollte sichergestellt sein, dass keine „nicht BW4 konformen“ Objekte mehr neu angelegt werden. Anschließend gleicht man die Liste der relevanten Datenmodelle mit der Liste der nicht BW4-kompatiblen Objekte ab. Daraus ergeben sich die Elemente, die gelöscht oder konvertiert werden müssen. Insbesondere bei den zu löschenden Objekten können Sie sofort starten. 

Man kann sich (noch) Zeit lassen 

Bei einem Kunden haben wir mit den Vorbereitungen im Rahmen des Tagesgeschäft 3 Jahre vor dem eigentlichen BW4 Projektstart angefangen (der Kunde ist mittlerweile auf BW4). Auf Systemebene wurden nicht unterstützte Add-Ons im Rahmen der regulären Wartung entfernt, und notwendige Betriebssystem- sowie HANA-Updates wurden durchgeführt, alles mit Blick auf ein mögliches BW4 Upgrade. Auf der Anwendungsebene haben wir darauf geachtet, dass die Richtlinien BW4 konform waren, das Transfer Cockpit wurde im Rahmen ohnehin geplanter Änderungen an bestehenden Datenmodellen getestet, und wir haben verstärkt den Fokus auf nicht mehr verwendete Queries/Provider und deren Löschung gelegt. 

So kann man über einen längeren Zeitraum das System schrittweise vorbereiten. Je näher man zum eigentlichen Upgrade kommt, desto projektähnlicher geht man vor. Das Tempo bestimmt man dabei selbst.  

Jeder Schritt bringt einen näher zum Ziel  

Beim ersten Blick auf die Protokolle des Pre-Checks der Transfer-Tools könnte die hohe Anzahl der Einträge abschreckend wirken. Doch mit jedem gelöschten, konvertierten oder manuell angepassten Element kommen Sie dem Ziel näher, und die Liste wird schrittweise kürzer. 

Es bleibt beim gleichen System (SID) 

Bei einer In-Place-Konvertierung wird aus einem BW7x ein BW4-System. Das bedeutet, dass die System-ID (SID) unverändert bleibt und bestehende Verbindungen normalerweise nahtlos weiter funktionieren. Auch Aspekte wie Berechtigungen, Front-Ends, Tools und sogar bestehende Datenladungen können ohne bzw. sehr geringem Aufwand übernommen werden. Darüber hinaus ändert sich für die Endanwender vorerst nichts, da aus ihrer Sicht größtenteils alles beim Alten bleibt. 

Testaufwände lassen sich (eventuell) reduzieren 

In den meisten Fällen, insbesondere bei InfoProvider Konvertierungen, handelt es sich um technische Änderungen, die die Anwender selten unmittelbar betreffen. Daher können diese bei den Tests in der Regel vernachlässigt werden, während der Fokus auf technischen Tests liegt. Bei kritischeren Anwendungen ist eine intensivere Testphase empfehlenswert. Dies erfordert jedoch eine aussagekräftige Testumgebung und eine sorgfältige Planung.  

Auswirkungen auf die Anwender flexibler steuern 

Viele Projekte dieser Art erzwingen einen Entwicklungsstopp, welche die Anwender für einen längeren Zeitraum betrifft. Im Falle einer InPlace ist dies jedoch nicht zwingend notwendig. Wenn die folgenden Themen sichergestellt sind, dann lassen sich die Auswirkungen auf die Endanwender reduzieren und auch besser steuern:  

1. strukturiertes und diszipliniertes Vorgehen bei den Konvertierungen und Änderungen. 

2. Neuentwicklungen werden konsequent BW4 konform entwickelt.  

Frontend Themen können zum Großteil ausgeblendet werden 

Im Bereich der Frontends gibt es einige Aufgaben, die angegangen werden müssen. Zum Beispiel wird der BEx Analyzer nicht mehr von BW/4 unterstützt. Ansonsten können die meisten Frontend-Tools für BW4 vorerst unverändert weiterverwendet werden, einschließlich BEx Web. Dies bietet die Möglichkeit, den Fokus auf die Migration zu BW4 zu legen, ohne gleichzeitig Änderungen im Frontend bewältigen zu müssen. 

Geringerer Aufwand 

Dass InPlace immer mit einem geringeren Aufwand verbunden ist, würde ich so pauschal nicht behaupten wollen. Jedoch wird das in vielen Fällen so sein. Viele Objekte und Konfigurationen im System kann man unverändert übernehmen. Zum Beispiel sind InfoObjekte oder Queries durch die InPlace Konvertierung kaum betroffen.  

Was sind die Nachteile? Worauf sollte man achten? 

Die Flexibilität einer In-Place-Konvertierung bringt jedoch auch gewisse Risiken mit sich. Kontinuierliche Systemänderungen erfordern eine sorgfältige Koordination. Einschränkende Prozesse, unzureichende Testumgebungen oder mangelndes Projektmanagement können zu Unzufriedenheit im Projekt führen. 

Während einer InPlace Konvertierung sind grundlegende Optimierungen der Datenmodelle nicht vorgesehen. Das Grundgerüst der Datenmodelle bleibt unverändert. Es wird nichts schlanker, schneller oder sauberer. Dieser Umstand mag zunächst enttäuschend sein, ist jedoch aus Effizienzgründen nicht zwangsläufig negativ. Wenn eine Anwendung derzeit einwandfrei funktioniert und die Anwender zufrieden sind, bietet sich eine technische Konvertierung mithilfe des Transfer Cockpits als schnellere und kostengünstigere Lösung an. Wenn Sie mit einer bestehenden Anwendung oder Reporting-Lösung nicht zufrieden sind, haben Sie die Möglichkeit, eine BW4-konforme Lösung im System neu zu erstellen. In diesem Fall schließt die eine Option die andere nicht aus, und Sie sind nicht verpflichtet, alles von Grund auf neu zu erstellen.  

In Systemen wo entsprechend den SAP-Vorgaben entwickelt wurde, halten sich die manuellen Eingriffe aufgrund von BW4 in Grenzen. Hierzu gehören hauptsächlich APDs, virtuelle Provider, Exits, bestimmte Aggregationsebenen und DB Connect-Quellsysteme. Andere Elemente, insbesondere InfoProvider und SAP DataSources, werden von den Transfer-Tools unterstützt. 

Abweichende Entwicklungsphilosophien, die nicht den Empfehlungen und Vorgaben von SAP entsprechen, können Probleme verursachen. Insbesondere in ABAP-intensiven BW-Systemen, in denen viele Aspekte mithilfe von ABAP-Reports und -Klassen umgesetzt wurden, erfordert die Migration besondere Vorsicht. Nach der Konvertierung der InfoProvider funktioniert beispielsweise ein aufgerufener ABAP-Code in einer Prozesskette möglicherweise nicht mehr wie zuvor. Hier ist eine sorgfältige Vorabprüfung und ausgiebiges Testen unerlässlich. 

Auch ABAP-basierte Anwendungen im BW-System erfordern eine gründliche Prüfung. Zum einen hat sich SAP Standard Coding verändert (die man eigentlich hätte gar nicht nutzen dürfen😊), zum anderen haben sich gewisse Schnittstellen geändert bzw. verhalten sich nun anders.  

Für eine erfolgreiche In-Place-Konvertierung ist fundiertes Fachwissen von entscheidender Bedeutung. Das Thema an sich ist komplex und erfordert spezialisiertes Know-how. Selbstständiges Erlernen ist zwar möglich, aber zeitaufwändig und erfordert entsprechende Qualifikationen. Darüber hinaus ist das erworbene Wissen nach einer erfolgreichen Konvertierung nur begrenzt verwendbar. Daher argumentiere ich, dass es selten einen besseren Grund gab, sich für dieses Thema externe Unterstützung ins Haus zu holen. In diesem Fall ist jedoch sicherzustellen, dass der externe Partner über das erforderliche Fachwissen verfügt. 

Zusammenfassung 

Kein BW-System gleicht dem anderen, weshalb allgemeine Aussagen über Upgrades auf BW4 herausfordernd sind. Jeder Fall erfordert eine individuelle Analyse. Eine erste Vorstellung geben die Logs der Transfer Tools. Basierend auf diesen Informationen kann eine geeignete Strategie entwickelt und der erforderliche Aufwand grob eingeschätzt werden. Wenn die Voraussetzungen gegeben sind, ist eine gut organisierte In-Place-Konvertierung oft die kosteneffizienteste Möglichkeit, das System für die Zukunft vorzubereiten und auf BW4 umzustellen. 

Das sind die wichtigsten Erfolgsfaktoren aus meiner Sicht: 

• Fokussierung auf die relevanten Themen.  
• Koordiniertes Vorgehen. Je mehr Personen involviert sind und je größer das System ist, desto wichtiger ist das.  
• Entsprechendes Know-how aufbauen und/oder einkaufen.  
• So früh wie möglich anfangen, zumindest mit der Analyse und dem Aufräumen des Systems. 
• Konsequent sein, wenn man anfängt, dann muss man die angefangen Teile auch zum Ende bringen.  

Wie kann ZPARTNER unterstützen? 

Steht eine BW4 Upgrade an und Sie brauchen Unterstützung? Hierbei können wir Sie unterstützen: 

• Initialanalyse auf Basis der Transfer Tool Logs.  
• BW4 Konvertierungs-Workshop. 
• Unterstützung des Projektmanagements für einen Kosten- bzw. Zeitplan. 
• Unterstützung bei den notwendigen Konvertierungen. 
• Unterstützung bei notwendigen manuellen Umbauten und Löschungen. 
• BW4 Training  

Bei Fragen können Sie sich gerne direkt an mich wenden stefan.witteck@zpartner.eu.