Herausforderungen nach einer SAP® Systemkopie

Systemkopien sind ein häufiges Mittel um sicherzustellen, dass sich das Qualitätssicherungssystem im Hinblick auf Testdaten nicht zu sehr von der Produktion entfernt.
Hierfür wird im Normalfall die Produktion auf die Qualitätssicherung kopiert.
Eine erfolgreiche Systemkopie ist jedoch mit dem eigentlichen Kopieren und den notwendigen Anpassungen der Datenbank (Ändern der System ID, Anonymisierung von Daten, etc.) nicht abgeschlossen. Es sind ja alle Änderungen, welche sich vor der Kopie nur im QA aber nicht im Prod.-System befanden verloren gegangen und müssen Reimportiert werden.
Auf den ersten Blick scheint dies sehr einfach. Alles was in Qualitätssicherung, nicht aber in Produktion ist muss reimportiert werden.
Auf den zweiten Blick kann man sich mit dieser Simplifizierung nicht nur das zukünftige Arbeiten erschweren und die Testqualität reduzieren, nein man kann sogar ein nicht funktionsfähiges Qualitätssicherungssystem erstellen.
Die zwei Hauptfaktoren hierbei sind nach dem Test verworfene Entwicklungen sowie die im SAP Umfeld berüchtigten Überholer.
Um genau zu sein kann man sowohl zu viel als auch zu wenig importieren.
Zuviel, weil man stur alles reimportiert, auch Transporte, die niemals in Produktion gehen sollen.
Zu wenig, weil man Überholer nicht berücksichtigt. So kann zum Beispiel ein überholender Hotfix, welcher schon Produktiv ist, mit dem simplifizierten Ansatz nicht gefunden werden und geht verloren.
Am Ende hat man ein überladenes und trotzdem nicht funktionierendes Qualitätssicherungssystem.
Diese Herausforderungen bei Volumen von hunderten oder gar tausenden Transportaufträgen manuell zu bewältigen ist auch mit sehr großen Aufwänden schier unmöglich.
Eine Lösung wie Conigma QCopy bietet hier eine vollautomatisierte Bewältigung der beschriebenen (und vieler anderer) Herausforderungen. Objektmodell bzw. am Prozess (Stichwort: 4 -> 6 Augen-Prinzip für gewisse kritische Vorgänge o. ä.) sind 'on the fly' meist binnen kürzester Zeit möglich, wenn sich z. B. aufgrund gesetzlicher Bestimmungen bzw. Anforderungen aus internen Audits oder Audits des Wirtschaftsprüfers Änderungsanforderungen ergeben, die aus Compliance-Gründen zeitnah umzusetzen sind. Conigma™ verwaltet beliebige Objekthierarchien mit Systemlandschaft übergreifenden Objekten und kann diese Anforderung somit vollumfänglich abdecken. Hierbei können beliebige Objekttypen und -hierarchien gecustomized werden. Eine Anforderung kann z. B. auf verschiedene Releases aufgeteilt werden. Darüber hinaus können verschiedene Release-Typen mit Sub-Releases angelegt werden. Conigma™ ermöglicht diesen wiederum eine Zuordnung hierarchischer Changes mit Unter-Changes.

Im gesamten komplexen Baum folgen alle Objekte ihren eigenen Workflow, erben Eigenschaften / (Status-)Informationen von Ihren Ober-Objekten und aggregieren diese wieder zurück.