Fremdsystemadministratoren informieren
On cloud: alle beteiligten Quell-/Zielsysteme auf Hyperscalern wie zB Microsoft Azure oder Amazon Web Services
Die Schritte, die vor dem Herunterfahren des SAP-Zielsystems durchgeführt werden müssen, lassen sich wie folgt zusammenfassen: Lange vor der Durchführung der Aktualisierung sollten Sie die Benutzer des Zielsystems – vor allem Projektmanager, Entwickler und Tester – per E-Mail, SAP-Systemnachrichten und/oder eine Nachricht bei der Systemanmeldung über die geplanten Wartungsarbeiten informieren. Die Verwendung des SAP-Transportsystems setzt eine sorgfältige Vorbereitung voraus, damit Softwareentwicklungsprojekte soweit wie möglich abgeschlossen werden können. Kurz vor dem Beginn der Aktualisierung informieren Sie die Benutzer erneut darüber, dass Wartungsarbeiten am System bevorstehen und sie sich vom Zielsystem abmelden sollen. Nach der Abmeldung der Benutzer sowie der Sperrung der Anmeldung laden Sie aus der Datenbank des Zielsystems systemspezifische Inhalte für die Anpassung herunter (darunter Sicherheitseinstellungen, Remote Function Call (RFC)-Ziele und Betriebsmodi).
Die von uns eingesetzten Tools können problemlos entweder in der Cloud betrieben oder On Premise. Dazu müssen die zu kopierenden SAP-Systeme einen Zugriff auf Betriebssystemebene erlauben. Die typischen Infrastrukturen aus der Cloud, wie zum Beispiel AWS oder Azure stellen keine Hürde für diesen Service dar.
Checkliste für die Vorarbeiten
Solche Systemkopien mit ihrem enormen manuellen Aufwand und den oftmals hunderte Punkte langen Checklisten von SAP sind vor jedem Refresh durchzuführen. Meist sind dafür drei bis vier Tage einzuplanen, in denen das QS-System – das in zweistufigen SAP-Umgebungen auch Entwicklungssystem ist – nicht für die eigentlichen Arbeiten zur Verfügung steht. Dabei entsteht die Verzögerung eigentlich nur durch den minutiösen Abgleich von Banalem, beispielsweise von Verzeichnisnamen. Weil solche SAP-Systemkopien für jede SAP-Anwendung auf dem QS-System angelegt werden müssen und somit schnell Dutzende Systemkopien erforderlich machen können, binden sie viele Ressourcen und Mitarbeiter.
Anwender müssen sich dabei nicht mit einzelnen Tabellen auseinandersetzen, sondern können auf eine Datenbank von Geschäftsentitäten zurückgreifen. Dass heißt, sie wählen keine Tabellen, sondern Business-Objekte wie Mitarbeiter oder Belege aus. Dazu muss in den Werkzeugen jedoch das Beziehungswissen über das komplexe Datenmodell der SAP enthalten sein. Selbst Unternehmen, die das Aufsetzen von Testsystemen als Service anbieten, leisten dies selten für beliebige SAP-Datenbestände. Zusätzlich können Anwender Objekte selbst definieren, um Customizing und Eigenentwicklungen zu berücksichtigen.
Sofern Sie "Shortcut for SAP Systems" verwendet haben, um systemspezifische Tabellen vor dem Systemrefresh zu sichern, können etliche manuelle Schritte entfallen - die Daten können durch das Rücksichern der vor der Systemkopie gesicherten Daten wiederhergestellt werden.
Zum anderen muss mit einem derartigen Tool gewährleistet sein, dass immer eine Nachvollziehbarkeit oder Transparenz gegeben ist.
Und last, but not least müssen derartige Tools eine Erweiterbarkeit zulassen oder kundenspezifische Erweiterungen/Anforderungen ermöglichen, wie etwa die Einbindung in einen Scheduler.