Es vergeht kein Tag, an dem ich nicht die Worte "S/4HANA-Roadmap" höre. Es scheint, dass viele Unternehmen entweder einige Teile ihres Bestands auf S/4HANA umgestellt haben oder aktiv ihre nächsten Schritte ana...
Als globales Softwareunternehmen unterstützen wir, EPI-USE Labs, mit unseren Produkten und Services Unternehmen dabei, die Performance ihrer SAP und SAP SuccessFactors Systeme zu steigern.
In diesem Artikel will ich Ihnen den Weg auf die S/4HANA Version 1709 und die technischen Optionen darstellen, Alles mit dem Vorbehalt, dass auch dies irgendwann veraltet sein wird.
Vereinfacht gesagt, haben Sie diese drei Möglichkeiten:
EPI-USE Labs ist darauf spezialisiert, Kunden bei den oben genannten Optionen zu helfen, entweder als Migrationsspezialist oder als Managed Service Provider. In diesem Artikel konzentriere ich mich auf die Systemkonvertierung (Brownfield), für Kunden, die heute die SAP Business Suite einsetzen und herausfinden möchten, wie sie mit der Umstellung auf S/4HANA Version 1709 beginnen können.
Technisch gesehen hat SAP ein robustes Transition-Tool (namens SUM), um die Systemkonvertierung zu S/4HANA durchzuführen und Ihre alte (Oracle/DB2/MSSQL) Datenbank auf die SAP HANA Datenbank zu migrieren sowie Ihre alte ECC-Anwendung auf die neuere S/4HANA Codebasis zu aktualisieren.
©SAP
Das SUM-Tool ermöglicht es Ihnen, in einem Schritt von Pre-S/4HANA auf S/4HANA zu wechseln. Dieser Ein-Schritt-Prozess ist jedoch idealistisch, da er nur funktioniert, wenn ALLE der folgenden Punkte zutreffen:
Wenn Ihnen eine dieser Voraussetzungen fehlt, wird Ihr Prozess für eine erfolgreiche S/4HANA Migration mindestens zwei Schritte erfordern. Einen einheitlichen Weg gibt es hierbei nicht, da viele Faktoren eine Rolle spielen wie das folgende Flussdiagramm zeigt.
©SAP
Lassen Sie uns also alle technischen Schritte für die S/4HANA Migration analysieren, einschließlich der Voraussetzungen. So können Sie besser verstehen, ob es sinnvoll ist einige dieser Voraussetzungen- zur besseren Vorbereitung - im Voraus durchzuführen.
Wenn Ihr bestehendes ECC 6.0-System auf einem dualen ABAP- & Java-Stack basiert, müssen Sie es - wie erwähnt - in zwei separate Stacks aufteilen, damit Sie den resultierenden reinen ABAP-Stack auf S/4HANA konvertieren können. Dieser Prozess ist gut dokumentiert; ich würde empfehlen, mit dem Artikel Dual-Stack Split, von Borris Zarske zu beginnen.
Für einen ersten Schritt in Richtung S/4HANA, muss Ihr Quellsystem mindestens auf ECC 6.0 sein, da die niedrigeren Releases SAP R/3 4.7 und SAP ECC 5.0 nicht die Customer-Vendor-Integration (CVI) enthalten. Es spielt keine Rolle, auf welcher Version des ECC 6.0 Enhancement Package Sie sich befinden. Wenn Ihr System auch noch nicht auf Unicode ist, können Sie das Upgrade eventuell mit einer Unicode-Konvertierung kombinieren - siehe nächster Punkt.
SAP S/4HANA wird nur mit Unicode ausgeliefert, und der SUM-Prozess beinhaltet keine Konvertierung von Nicht-Unicode nach Unicode (für ein 7.5x-Ziel). Wenn Sie Ihre Quellumgebung auch auf ECC 6.0 aktualisieren müssen, um für S/4HANA bereit zu sein, können Sie diese beiden Schritte miteinander kombinieren, indem Sie die sogenannte kombinierte Upgrade- & Unicode-Konvertierung (CU&UC) verwenden. Die Umstellung eines SAP ECC-Systems auf Unicode ist ein recht gut dokumentierter Prozess, der hauptsächlich eine technische Übung mit minimalen funktionalen Auswirkungen ist, abgesehen von Regressionstests in Bereichen wie Schnittstellen, Self-Services und benutzerdefiniertem ABAP-Code.
Bevor Sie auf die SAP HANA-Datenbank oder die neue S/4HANA-Version umsteigen, sollten Sie sich darüber im Klaren sein, dass es einen Business Case gibt, die Menge an überschüssigen Daten in Ihrer Umgebung zu minimieren. Die zugrundeliegende HANA-Architektur nutzt viel teurere Hardware, um alle Daten speichern zu können.
Nutzen Sie dies als Gelegenheit, Ihre Systemlandschaft zu bereinigen und beispielsweise das Archivierungsprojekt in der Produktion in Angriff zu nehmen, das Sie bisher vermieden haben.
EPI-USE Labs bietet ein Pre-S/4HANA SLO-Engagement an, um Datenvolumen vor der S/4HANA-Konvertierung zu reduzieren und das ganze Projekt so ganzheitlich zu optimieren. Sie können auch jederzeit selbst schlanke, sichere Nicht-Produktionssysteme mit Data Sync Manager erstellen und unserer DSGVO/GDPR Compliance Suite zur Verfremdung Ihrer sensiblen Daten nutzen.
Wenn Sie seit Jahren mit SAP ECC arbeiten, dann haben Sie einen großen Anteil an benutzerdefiniertem ABAP-Code. Auf dem Weg zu S/4HANA müssen Sie sicherstellen, dass all dieser benutzerdefinierte Code aktualisiert wird, um veraltete durch neue und äquivalente Anweisungen zu ersetzen. Am besten fangen Sie damit an, nicht mehr genutzten Code zu entfernen - warum sollten Sie Zeit mit etwas verschwenden, das einfach nur herumliegt?
Generell sollten Sie sich mit dem SAP Code Inspector (SCI) und dem ABAP Test Cockpit (ATC) beschäftigen. ATC hat einige technische NetWeaver-Stack-Anforderungen, und eine praktische Lösung besteht darin, eine separate ABAP-Instanz mit den erforderlichen Softwareversionen einzurichten und diese zu verwenden, um eine Verbindung zu Ihrer ECC-Umgebung herzustellen und eine Remote-Code-Analyse von dieser ABAP-Instanz aus durchzuführen, ohne etwas in Ihre ECC-Umgebung laden zu müssen.
Wenn Sie eine Unicode-Migration oder ein Upgrade von vor ECC 5.0 auf ECC 6.0 durchführen müssen, sollten Sie wissen, dass beide Prozesse eine Anpassung des ABAP-Codes erfordern.
Für die HANA-Datenbank gilt generell, dass ABAP-Code auf SAP HANA wie zuvor läuft, mit Ausnahme von nicht-HANA-Datenbank-spezifischem Code.
Die Migration auf S/4HANA hat ihre eigenen Anforderungen und Hilfsmittel, die Sie bei der Analyse und Behebung von benutzerdefiniertem ABAP-Code unterstützen. Sie können immer noch das ATC verwenden, um einige semantische Prüfungen für Ihren benutzerdefinierten ABAP-Code unter S/4HANA durchzuführen; der Custom Code Analyzer ist jedoch Teil des formalen S/4HANA-Konvertierungs-Toolset und bewertet Ihren Code anhand der Simplification Lists. Weitere Informationen finden Sie im SAP-Hinweis 2185390 oder im SAP Help Portal.
Bei der Umstellung auf eine HANA-Datenbank sind mitunter erhebliche Änderungen der Plattformarchitektur zu berücksichtigen. Der Fokus wird hier auf den logischen Software-Schritten liegen, die erforderlich sind.
Wenn Sie sich fragen, warum ich das Feld für das HANA-Datenbank-Upgrade in meinem obigen Diagramm in einer anderen Farbe dargestellt und auf zwei Silos aufgeteilt habe, versuche ich Ihnen damit zu zeigen, dass Sie sich dafür entscheiden können, Ihre Nicht-HANA-Datenbank auf HANA zu migrieren, bevor Sie ein Upgrade auf S/4HANA durchführen.
Oder Ihre Datenbankmigration zu SAP HANA kann als Teil des SUM-Prozesses (mit DMO) bei der Umstellung auf S/4HANA durchgeführt werden. Die Migration Ihrer ECC 6.0-Datenbank von Nicht-HANA auf HANA hat weitaus weniger Auswirkungen auf die Geschäftsprozesse/Funktionen als die Konvertierung Ihrer ECC 6.0-Landschaft auf S/4HANA. Es handelt sich vielmehr um einen technologischen Prozess, der es Ihren Basisteams ermöglicht, sich mit der Verwaltung von HANA, mit der neuen Architektur sowie mit der neuen Hardwareanforderung vertraut zu machen. Unterschiedliche Beweggründe führen bei unseren Kunden zu unterschiedlichen Verfahrenswünschen. So haben manche kein Interesse an dem technologischen Prozess und wollen nach einem einmaligen Test sofort auf S/4HANA umsteigen.
Eine weitere Randnotiz ist, dass die Umstellung auf NetWeaver Stack 7.5 bestimmte Anforderungen an die Datenbank-Quellversion stellt, was bedeutet, dass die Datenbank Ihres Vor-NetWeaver-Stacks auf einen Mindeststand aktualisiert werden muss, bevor Sie mit dem Upgrade auf 7.5 beginnen - für die HANA-Datenbank ist dieser Mindeststand SPS09, Revision 97. Weitere Informationen finden Sie im SAP-Hinweis 2158828.
Der Hauptbestandteil dieser Phase sind SAP-Tools (S/4HANA Readiness Check), die Ihr bestehendes SAP ECC-System analysieren und die Geschäftsprozesse (Simplification List) und den benutzerdefinierten ABAP-Code identifizieren, die von Ihrem Umzug nach S/4HANA betroffen sind (Custom Code Migration Worklist). Technisch gesehen werde ich hier nicht ins Detail gehen, außer zu erwähnen, dass Sie, wenn Sie die Umstellung auf S/4HANA in Erwägung ziehen, Ihre Solution Manager-Implementierung wirklich in Ordnung bringen müssen, damit Sie in dieser Phase das neuere Maintenance Planner-Tool verwenden können, das von SAP für die Identifizierung und den Download der relevanten Software vorgeschrieben ist. Der SAP S/4HANA Readiness Check funktioniert auch über den Solution Manager.
EPI-USE Labs bietet ebenfalls ein kostenloses HANA Readiness Assessment an, das den Solution Manager nicht benötigt und eine super einfache Möglichkeit ist, eine zusätzliche Perspektive von dritter Seite in Bezug auf den erforderlichen Aufwand für die Migration auf HANA und S/4HANA zu erhalten. Alles, was Sie tun müssen ist, einen kleinen Transport in Ihr ECC-System zu importieren und einen Bericht auszuführen, der einen Metadaten-Extrakt im Klartext erzeugt, der über ein sicheres Portal an uns zurückgeschickt wird und Ihren Bericht online zur Ansicht bereitstellt. Es sind keine tatsächlichen Kundendaten enthalten, sondern nur Dinge wie Versionstabellen, Zeilenzahlen, spezifische Konfigurationswerte usw., die wir ermittelt haben, um Ihnen einen quantitativen Überblick über Ihr System zu geben.
Schließlich fehlen noch die letzten technischen Aufgaben, um die eigentliche Konvertierung von alt nach neu durchzuführen.
Nachdem SUM den Konvertierungsprozess abgeschlossen hat, werden Sie einen neuen NW7.5 Unicode-Stack auf einer HANA-Datenbank mit den S/4HANA Core ABAP-Komponenten ausführen. Im Anschluss fehlen noch wichtige Aufgaben:
Anpassung des Custom Codes - stellen Sie sich dies als Ihren typischen SPAU/SPDD-Prozess bei einem Upgrade vor.
S/4HANA-Migrationscockpit - stellen Sie sich das so vor, dass Sie alle fremden Legacy-Daten in Ihr neues S/4HANA-System importieren.
Einrichtung von Fiori-Front-End-Servern - ich möchte hier die neue Fiori-Benutzeroberfläche nennen, die Sie im Voraus verstehen und planen müssen. Sie müssen ein Design für eine Fiori Front End Server (FES)-Landschaft entwerfen, die es den Anwendern in Ihrem Unternehmen ermöglicht, auf die neuen Fiori-Benutzeroberflächen in S/4HANA zuzugreifen. Die verfügbaren Optionen sind ein eingebetteter Einsatz (FES eingebettet in S/4HANA) oder ein Hub-Einsatz (FES als Hub). Dieses Thema mag harmlos klingen, kann aber ziemlich schnell kompliziert werden, da man Netzwerksicherheitsdesigns, Reverse Proxies, Authentifizierung, etc. berücksichtigen muss.
Dies ist sicherlich nicht der erste und auch nicht der letzte Artikel, den Sie über dieses Thema lesen werden. Ich hoffe, er hat Ihnen geholfen, die technischen Schritte und Ihre Optionen zu verstehen, wenn Sie einen Umstieg von Ihrem aktuellen ERP 6.0 auf S/4HANA 1709 per Systemkonvertierung vor Ort in Betracht ziehen. Bitte kontaktieren Sie uns, wenn Sie detailliertere Unterstützung bei der S/4HANA Migration Ihres Unternehmens wünschen.
EPI-USE Labs hat Kunden bei der Umstellung auf S/4HANA unterstützt, zusätzlich zur Umstellung von physisch auf virtuell, von On-Premise auf Cloud, von Inhouse auf voll verwaltet. Als SAP-Partner sind wir seit über 30 Jahren im Bereich SAP-Datenmanagement tätig und bieten SAP-zertifizierte Software, Landschaftsumwandlungs- und Migrationsservices sowie Managed Services.
Wenn Sie mehr über SAP S/4HANA und Migrationsstrategien erfahren möchten, einschließlich der Frage, wo Sie anfangen sollten und welche Optionen Sie haben, wenden Sie sich an uns.
© 2023 EPI-USE Berlin GmbH, Friedrichstraße 95, 10117 Berlin
© 2023 EPI-USE GmbH, Sophie-Scholl-Platz 8, 63452 Hanau
© 2023 EPI-USE Labs GmbH, Altrottstraße 31, 69190 Walldorf
Einen Kommentar schreiben