Sebastian Geissler verantwortet als Gesellschafter der Vostura GmbH die Geschäftsstelle Mannheim und den Bereich Testmanagement Consulting. Er ist seit fast fünfzehn Jahren im Bereich Testmanagement für SAP-zentrische Lösungen tätig und besitzt langjährige Projekterfahrung in komplexen Implementierungs- und Entwicklungsprojekten. Diese Erfahrung teilt Sebastian in diesem für die EPI-USE Labs verfassten Beitrag sowie dem Webinar „Testdatenmanagement in (D)einer S/4-Transformation“.
Viele Unternehmen stehen derzeit vor einer S/4-Transformation. Der damit verbundene Aufbau einer S/4-Landschaft bietet die Möglichkeit, das Testdatenmanagement neu zu gestalten oder nachhaltig zu verbessern. Viele Unternehmen hätten sich nämlich ein fest definiertes, standardisiertes und werkzeuggestütztes Vorgehen für das Testdatenmanagement bereits für ihre klassische SAP-Welt gewünscht.
Somit entsteht im Rahmen eines S/4-Implementierungsprojekts die einmalige Gelegenheit, einen Top-Down-Ansatz für das Testdatenmanagement einer S/4-Landschaft für den operativen Betrieb mit dem ersten Go-Live zu implementieren. Dieser, in nachfolgender Abbildung skizzierte, Top-Down-Ansatz sieht es vor, das Testsystem (S/4 QAS) mit aktuellen, produktionsnahen Daten zu versorgen. Hierfür kopiert man reduzierte und gegebenenfalls anonymisierte Daten des Produktivsystems (S/4 PRD). Die grauen Pfeile in der Abbildung stellen dabei Transportwege für Customizing- und Workbench-Änderungen, die blauen Pfeile die Kopierwege für Stamm- und Bewegungsdaten dar.
Top-Down Ansatz für das Testdatenmanagement in (D)einer S/4-Landschaft im operativen Betrieb
Auf Grund der technischen Beschaffenheit von SAP-Systemlandschaften ist ein reines Kopieren von Daten zu beliebig wählbaren Zeitpunkten – die oft gesuchte „Datenschleuder“ – nicht möglich. Vor allem Stamm- aber auch Bewegungsdaten sind z.B. an Data Dictionary- oder Repository-Objekte gebunden, die mitkopiert werden müssen. Deshalb sind vor einer Kopie folgende Voraussetzungen zu erfüllen:
- Vollständiger Go-Live aus dem Implementations-Track
- Vollständiger Retrofit aus dem Maintenance-Track
Da diese Voraussetzungen nicht zu jedem Zeitpunkt erfüllt werden können, empfiehlt es sich in der Praxis, mit einem sogenannten Golden Client des Testsystems zu arbeiten. In einem solchen Szenario wird zunächst unter Beachtung der o.g. Voraussetzungen das Produktivsystem in das Testsystem inkl. dem Golden Client kopiert. Zu frei wählbaren Zeitpunkten erfolgt der Daten-Refresh des Testsystems nun immer aus dem Golden Client – solange, bis die Voraussetzungen für eine erneute Kopie des Produktivsystems auf das Testsystem wieder erfüllt werden können. Für die Kopie des Golden Clients in das Testsystem sind ebenfalls einige Voraussetzungen zu erfüllen. Diese können aber entweder automatisiert oder zumindest deutlich einfacher sichergestellt werden als bei einer Kopie des Produktivsystems auf das Testsystem.
Weitere Quell-/Zielsystemkombinationen für das Kopieren von (Test-)Daten, z.B. vom Testsystem zum Trainingssystem (S/4 TRX) oder vom Produktivsystem zum Integrationssystem (S/4 PRE), sind selbstverständlich ähnlich umsetzbar.
Sinnvolle Einsatzgebiete für einen ganzheitlich durchdachten Testdatenmanagementansatz gibt es aber nicht erst mit dem ersten Go-Live und im Betrieb eines produktiven S/4-Systems, sondern auch schon während der Implementierungsphase im sogenannten Bottom-Up-Ansatz.
Bottom-Up Ansatz für das Testdatenmanagement in (D)einer S/4-Implementierungsphase
In der Praxis werden folgende vier Use Cases des Bottom-Up-Ansatzes häufig verwendet:
Use Case 1:
Im Rahmen der Vorbereitung eines S/4-Implemtierungsprojekts benötigen üblicherweise viele Parteien Zugriff auf ein produktionsnahes System. Das System, welches durch ein S/4-System abgelöst werden soll, ist in diesem Beispiel ein SAP ECC-System. Der Zugriff auf konsistente aber reduzierte und anonymisierte (Test-)Daten kann realisiert werden, indem das Produktivsystem (ECC PRD) auf das Testsystem (ECC QAS) kopiert wird und zeitgleich die Daten nach vorgegebenen Regeln anonymisiert werden. Auch hier ist es wichtig, die Voraussetzungen des Top-Down-Ansatzes zu beachten. In der nachfolgenden Skizze ist dieser erste Use Case des Bottom-Up-Ansatzes dargestellt.
Use Case 2:
Bei der Wahl eines Brownfield-Ansatzes für das S/4-Implemntierungsprojekt unterstützt der zweite Use Case des Bottom-Up-Ansatzes – dargestellt in untenstehender Skizze – ebenfalls in der Vorbereitungsphase. Er erleichtert die durch SAP Best Practices empfohlene Bereitstellung eines Sandboxsystems (ECC -> S/4 SBX). Auf diesem Sandboxsystem können sowohl vorbereitende Schritte als auch die Migration an sich durch – falls erforderlich wiederholtes – Zurücksetzen des Sandboxsystems mehrfach geübt werden
Auch in diesem Use Case hat sich der Einsatz von DSM zur Kopie des Produktivsystems (ECC PRD) auf die Sandbox bewährt. Die Einhaltung der im Top-Down-Ansatz beschriebenen Voraussetzungen ist auch hier von Vorteil, wenn auch abhängig vom konkreten Einsatzszenario nicht zwingend erforderlich.
Use Case 3:
Ein dritter Use Case des Bottom-Up-Ansatzes ist der Aufbau des S/4-Testsystems (S/4 QAS) aus dem S/4-Entwicklungssystem (S/4 DEV). Dieser findet dann Beachtung, wenn in S/4-Implementierungsprojekten agile Vorgehensweisen gelebt werden und erste „Prüfaktivitäten“ ein vollständiges Set an Daten bereits auf dem Entwicklungssystem erfordern. Kunden, die sich wünschen, dieses im Entwicklungssystem aufgebaute Set von Daten im Testsystem wiederzuverwenden, bauen das Testsystem mittels DSM aus dem Entwicklungssystem initial auf, auch wenn dies etwas von der SAP Best Practice, das Entwicklungs- und Testsystem parallel aufzubauen, abweicht. Dies ist in nachfolgender Abbildung skizziert.
Beim initialen Aufbau des Testsystems aus dem Entwicklungssystem mittels DSM ist es unabdingbare Voraussetzung, dass im Entwicklungssystem keine offenen Transporte vorhanden sind.
Use Case 4:
Logisch schließt sich daran der vierte Use Case des Bottom-Up-Ansatzes an, nämlich der regelmäßige Refresh des Testsystems (S/4 QAS) aus einem dafür geschaffenen Golden Client (GC). Insbesondere zur Unterstützung von Regressionen in agilen Ansätzen, die häufig mit dem SAP Solution Manager inkl. Focused Build umgesetzt werden, bietet sich ein solcher Refresh mittels DSM an, um z.B. für Wiederholungen von Tests immer wieder die gleichen Grundvoraussetzungen zu schaffen.
In dem, in obiger Grafik skizzierten, vierten Use Case sind dieselben Voraussetzungen zu beachten, die bereits für den Refresh im Top-Down-Ansatz beschrieben wurden.
Ähnlich wie im Top-Down-Ansatz sind auch im Bottom-Up-Ansatz weitere Quell-/Zielsystemkonstellationen denkbar. So sind z.B. der regelmäßige Refresh des Integrationssystems (S/4 PRE) aus einem Golden Client oder die Auffrischung von Trainingssytemen (S/4 TRX) ebenfalls häufig genutzte Szenarien.
Weiterführende Einblicke in die beschriebenen Szenarien und Use Cases bietet das Webinar „Testdatenmanagement in (D)einer S/4-Transformation“.
Einen Kommentar schreiben