Ein veraltetes Testsystem mit ungenauen Daten, stellt ein Risiko in jedem Projekt dar. Eines der größten SAP Projekte steht aktuell in den Startlöchern und viele Unternehmen sind mit der Planung ihrer Reise nach S/4 beschäftigt. In diesem Blog möchte ich Ihnen zeigen, was vor, während und nach einem S/4HANA Migrationsprojekt zu beachten ist.
Vor der S/4HANA Migration:
Brownfield Migration: SAP Landschaft effizienter gestalten
Viele Unternehmen weltweit haben umfassende SAP Nicht-Produktionslandschaften im Einsatz. Einige Systemkopien, egal ob von einem Produktivsystem oder von ganzen Mandanten, sind Relikte von schon längst abgeschlossenen IT-Projekten. In den letzten 20 Jahren wurde unternehmenseigener Speicherplatz günstiger und einfacher zu managen, was den Unternehmen überhaupt erst ermöglichte, ihre SAP Landschaften anwachsen zu lassen.
Mit S/4HANA wird es nun wieder wichtig, unnötigen Datenballast zu entfernen, denn der Speicherplatz der In-Memory-Datenbanktechnologie ist wesentlich teurer. Gleichzeitig sollten Sie für Ihr S/4 Projekt qualitativ hochwertige Testdaten sicherstellen, unabhängig davon, welchen Weg Sie wählen.
Um veraltete Testsysteme zu ersetzen, ermöglicht Data Sync Manager beispielsweise den Aufbau neuer Systemhüllen mit schlanken Mandanten und maskierten Daten. Oder Sie nutzen die leistungsstarke Löschfunktion von Client Sync, um redundante Mandanten zu entfernen oder Mandanten zu löschen, die zurückgesetzt und mit neuen Daten befüllt werden sollen.
Vorbereitungen für Ihr S/4HANA Projekt
Viele Dinge können bereits vor einer S/4HANA Migration angegangen werden, wie zum Beispiel die Custom-Vendor Integration. Die Möglichkeit Daten auf Abruf in einem Entwicklungs- oder Sandboxsystem zur Verfügung zu stellen, bietet Ihnen einige Vorteile bei diesen funktionalen Vorprojekten. Beispielsweise kann so Zeit bei der Durchführung eingespart werden. Außerdem erhalten Sie sehr wahrscheinlich ein genaueres Abbild davon, welche Arbeiten in der Produktion noch getan werden müssen.
Erstellen Sie mit Data Sync Manager zuverlässige Testdaten und wählen Sie nur die Daten aus, die Sie wirklich brauchen. Erfahren Sie mehr, wie Object Sync funktioniert und wie Sie die Lösung einsetzen können.
Sensible Daten maskieren
SIs und Beratungsfirmen begleiten Sie ggf. während Ihres S/4 Projekts. Diese benötigen Zugang zu Ihren Nicht-Produktivsystemen, um Empfehlungen abzugeben, Analyseberichte vorzubereiten und potenzielle Projekte skalieren zu können. Auch wenn all diese Unternehmen über Ländergrenzen hinweg kommunizieren und nur mit akkuraten Daten arbeiten können, heißt das im Umkehrschluss nicht, dass es echte personenbezogene Daten sein müssen. Die Schlagzeilen weltweit über Datenschutzverletzungen häufen sich. Gehen Sie nicht das Risiko ein, dass jemand sensible Daten aus Ihrem QA-System herunterlädt und an den Meistbietenden verkauft. Mit Data Secure behalten Sie die volle Kontrolle durch Pseudonymisierung Ihrer sensiblen Daten.
Während der S/4HANA Migration:
Sandbox
Vor dem Projektstart empfiehlt SAP dringend den Aufbau einer Sandbox. Was genau Sie hier testen sollten, zeigen wir Ihnen in diesem Blog. Je genauer die Qualität der Daten in Ihrer Sandbox, desto besser. Da liegt eine vollständige Kopie der Produktion nahe, was aber viel Speicherplatz und somit auch hohe Kosten bedeuten würde. Nutzen Sie DSM, um eine schlanke, qualitativ hochwertige Sandbox für Ihr Projekt aufzubauen. Ziehen Sie auch eine Sandbox in der Cloud in Betracht, da die Dauer des Projektes nicht vorherzusagen ist. Ballance Agri nutze DSM für die Sandbox in ihrem S/4 Projekt - lesen Sie mehr dazu.
Auf Basis der Produktion ein Nicht-Produktivsystem aufbauen
Sollten Sie den Brownfield-Ansatz verfolgen empfehle ich Ihnen, den Unterschied zwischen der Konfiguration, dem Customising und dem Code im Entwicklungs- und Produktionssystem zu betrachten. Sie sollten bedenken, dass mit den Jahren die Differenz immer größer wurde, da alte Z-Codes verworfen, Konfigurationen ins QA eingespielt das Projekt dann aber abgebrochen wurde oder Add-Ons von Drittanbietern in die Entwicklung geladen, aber nie deinstalliert wurden. Als ein Teil unserer Cloud Migrationsstrategie setzen wir DSM ein, um aus dem Produktionssystem eine neue Nicht-Produktionslandschaft aufzubauen. Dieses Vorgehen wäre auch für Ihre S/4HANA Migrationsstrategie denkbar.
Ein Neuaufbau des Entwicklungs- und QA-Systems mit den Daten des Produktivsystems verkleinert die oben erwähnten Differenzen, ermöglicht einen besseren Projektstart und verringert die Fehlerquote. Viele Unternehmen führen die Migration mit einer vollständigen Kopie ihres Produktivsystems durch und werden dann, wenn es bereits zu spät ist, von den anfallenden Kosten überrascht. Die Verringerung des zu überarbeitenden Custom Codes ist hierbei wahrscheinlich die treibende Kraft. Die Verwendung von DSM zum Aufbau kleinerer und neuer Test- und Entwicklungssysteme, bietet aber den gleichen Vorteil. Die Unterschiede zwischen Entwicklung und Produktion lassen sich verringern und die Menge des zu überarbeitenden Z-Codes reduziert sich. Jedoch fallen nur ein Bruchteil der Kosten an, da kleinere Applikationen verwendet werden können.
Hybride Cloudoptionen
Die Möglichkeit Daten beim Austritt aus Ihrem System maskieren zu können, eröffnet Ihnen die Option, das Produktivsystem weiterhin On-Premise zu nutzen und alle Nicht-Produktivsysteme in die Cloud auszulagern. Gerade diese Systeme können von der Flexibilität der Cloud profitieren: fahren Sie die Systeme während wichtiger Projektphasen hoch. Wenn Sie gerade nicht gebraucht werden, schalten Sie diese wieder ab. Object und Client Sync aktualisieren Ihre Daten und halten diese auf dem neuesten Stand, sodass keine sensiblen Daten Ihr Netzwerk verlassen.
Nach der S/4HANA Migration:
TDMS wird für S/4 nicht unterstützt
Der Abschluss einer erfolgreichen S/4HANA Migration bedeutet nicht das Ende der Reise. Die funktionalen Teams sehen in S/4HANA den Kern eines intelligenten Unternehmens. Viele weiteren Projekte werden folgen, bei denen die Möglichkeiten von maschinellem Lernen und künstlicher Intelligenz getestet werden, um einen Wettbewerbsvorteil zu finden oder zu halten. All diese Projekte brauchen aktuelle Testdaten und eine agile Nicht-Produktionslandschaft.
Die SAP Lösung Test Data Migration Server (TDMS) wird auf S/4 nicht mehr unterstützt, was viele unserer Kunden überhaupt erst auf DSM gebracht hat.
Wir haben in den letzten 4 Jahren Änderungen an unserer Architektur vorgenommen, um mit den neuen, von S/4 verwendeten Technologien umgehen zu können. Data Sync Manager wird nicht nur auf S/4 unterstützt, sondern wurde für den Gebrauch auf S/4 zertifiziert.
Gleichbleibende Testsysteme, auch bei wachsender Produktion
Wächst Ihr Produktivsystem weiter an, muss das nicht automatisch bedeuten, dass Ihr Nicht-Produktivsystem im gleichen Maßstab mitwachsen muss. Sorgfältige Planung und der Einsatz von DSM Client Sync hält kleinere Testsysteme mit Teilmengen aus der Produktion auf dem neuesten Stand, d. h. die Wachstumsrate der Testsysteme ist weitaus geringer als die der Produktion.
Brauchen Sie Unterstützung bei Ihrer S/4HANA Migration?
Unser S/4 Assessment Report hilft Ihnen einen Einblick in die erforderlichen Maßnahmen einer Migration zu gewinnen und warnt Sie bei möglichen Komplikationen vor, wie beispielsweise:
- SAP Readiness Check Items, die relevant für Ihr SAP System sind
- Anzahl der Kunden und Lieferanten ohne verknüpfte BPs
- Technische Blockaden wie ein Nicht-Unicode-System
- Von Ihrem System verwendete SAP-Bereiche, die nicht mehr unterstützt werden
- Menge an benutzerdefiniertem Code
- Visuell interaktives Dashboard des Systems, als Ansatzpunkt für interne Gespräche
Fragen Sie Ihr kostenloses S/4 Assessment noch heute an. Für regelmäßige Updates zum Thema S/4HANA und Testdaten abonnieren Sie diesen Blog. Geben Sie hierzu einfach Ihre E-Mail-Adresse unter 'Blog abonnieren' am Beginn dieser Seite an.
Einen Kommentar schreiben