IT-Systeme · Praxisleitfaden

SAP-Systemkopie und Mandantenrefresh unter GxP prüfen

Die SAP-Kopie startet erfolgreich. Im Hintergrund zeigt eine Verbindung jedoch noch auf ein produktives Ziel. Eine Systemkopie ist deshalb erst dann bereit für Tests, wenn Daten, Identitäten und aktive Funktionen zur vorgesehenen Zielumgebung passen. Der technische Start allein genügt nicht.

Inhaltsverzeichnis

Das Wichtigste vorab

Was ist nach einer SAP-Systemkopie oder einem Mandantenrefresh unter GxP zu prüfen?

Prüfen Sie den geplanten Daten- und Konfigurationsstand sowie alle relevanten Zielbezüge: Systemidentität, Verbindungen, Jobs, Benutzer, Ausgaben und Schnittstellen. Bewerten Sie Schutz und Zulässigkeit übernommener Daten gesondert. Führen Sie geeignete technische und fachliche Abnahmekontrollen aus und dokumentieren Sie die erlaubte Nutzung. Systemkopie und Mandantenrefresh haben unterschiedliche Umfänge; eine universelle Nacharbeitsliste reicht nicht für jede Landschaft.

Kopierverfahren und Zielzweck eindeutig bestimmen

Unterscheiden Sie Systemkopie, Mandantenkopie und einen projektspezifischen Refreshprozess. Der tatsächliche Umfang hängt von Verfahren, Produktstand und Landschaft ab. Dieser Beitrag gibt keine universelle SAP-Befehlsfolge vor. Beschreiben Sie Quelle, Ziel, übernommene Daten und Konfigurationen sowie bewusst ausgeschlossene Teile. Die technische Dokumentation des verwendeten Verfahrens ist die Grundlage für die konkrete Nacharbeit.

Legen Sie den Zweck fest: Entwicklung, Schulung, Regression, Migrationsprobe oder Fehleranalyse. Daraus folgen unterschiedliche Anforderungen an Datenstand und Funktion. Eine für Schulung geeignete Umgebung ist nicht automatisch ein repräsentatives Validierungssystem. Wenn Tests dort als Freigabenachweis dienen sollen, müssen relevante Unterschiede zur vorgesehenen Produktion bewertet werden. Das Kopierdatum allein belegt weder vollständige Gleichheit noch fachliche Eignung.

Quellen: [1] [2]

Vor der Kopie Abhängigkeiten und Datenrisiken erfassen

Erstellen Sie ein Inventar der relevanten Schnittstellen, Hintergrundjobs, Ausgaben, Identitätsdienste und externen Ablagen. Prüfen Sie, welche Verbindungen durch die Kopie mitkommen und welche separat bestehen bleiben. Ein im System gespeicherter Zielname kann nach dem Refresh unverändert auf Produktion zeigen. Auch Drucker, E-Mail-Empfänger und Dateiablagen können reale Folgen außerhalb der Testumgebung auslösen.

Bewerten Sie vertrauliche und personenbezogene Daten vor der Übernahme. Die datenschutzrechtliche Zulässigkeit wird gesondert geklärt. Maskierung und Zielberechtigungen müssen zum vorgesehenen Test passen. Berücksichtigen Sie lokale Kopien und Exporte externer Projektbeteiligter. Ein identischer Datenbestand erleichtert manche Tests, rechtfertigt aber nicht automatisch jeden Zugriff. Definieren Sie, welche Schutz- und Konfigurationsmaßnahmen vor der ersten Benutzernutzung abgeschlossen sein müssen.

Quellen: [2]

Systemidentität und Verbindungen kontrolliert nacharbeiten

SAP beschreibt Post-Copy-Automation für technische Nacharbeiten. Ob und wie diese eingesetzt wird, hängt vom konkreten Verfahren und verfügbaren Umfang ab. Automatisierung ist ein Hilfsmittel, keine pauschale Abnahme. Prüfen Sie die tatsächlich erforderlichen Systemkennungen, Verbindungen und Zielbezüge. Halten Sie fest, welche Einstellungen übernommen, angepasst oder bewusst wiederhergestellt werden.

Besonders wichtig ist die Trennung zur produktiven Verarbeitung. Testen Sie die vorgesehenen Schnittstellen mit kontrollierten Gegenstellen oder geeigneten Ersatzverfahren. Eine Verbindung, die technisch funktioniert, kann gerade deshalb gefährlich falsch sein, wenn sie das falsche System erreicht. Dokumentieren Sie Zieladresse, Berechtigung und fachliche Wirkung. Der Nachweis soll bestätigen, dass der geplante Weg aktiv und unerlaubte reale Verarbeitung verhindert ist, nicht lediglich eine erfolgreiche Netzwerkantwort zeigen.

Quellen: [1]

Konstruiertes Beispiel: Refresh eines Validierungssystems

Im Beispiel wird ein SAP-Testsystem mit einem aktuellen Datenstand versorgt. Die Quelle enthält einen nächtlichen Versandjob, eine Laborverbindung und eine Ausgabe an einen realen Drucker. Im Ziel sollen nur kontrollierte Testgegenstellen verwendet werden. Der technische Kopierlauf endet erfolgreich. Vor der Freigabe prüft das Team, ob Jobs, Verbindungen und Ausgaben dem Zielkonzept entsprechen und keine produktive Aktion auslösen.

Das Referenzpaket enthält außerdem einen bekannten Artikel, eine Charge und einen offenen Vorgang. Diese Objekte werden nach dem Refresh fachlich geprüft. Ein korrekt gestartetes System mit falsch übernommenem Customizing wäre für den geplanten Nachweis ungeeignet. Die folgende Matrix ist eine eigene Arbeitshilfe. Sie wird an das tatsächliche Kopierverfahren angepasst und behauptet keine identischen Nacharbeiten für jedes SAP-Produkt oder jede Cloudedition.

Eigene Arbeitshilfe: Konstruiertes Beispiel: Refresh eines Validierungssystems
BereichAbnahmefragePassender Nachweis
SystembezugIst das richtige Ziel aktiv?Eindeutige Identität und Kennzeichnung
SchnittstelleWelche Gegenstelle wird erreicht?Kontrollierter Test mit Zielnachweis
HintergrundjobDarf er im Ziel laufen?Geprüfte aktive Jobliste
AusgabeWohin geht Druck oder Nachricht?Definierter Testkanal
DatenstandIst der benötigte Bestand vorhanden?Referenzobjekte und Abgleiche
NutzungWelche Tests sind freigegeben?Dokumentierte Eignung und Grenzen

Quellen: [2]

Daten, Konfiguration und Ausführbarkeit getrennt prüfen

Ein Mengennachweis kann bestätigen, dass relevante Datenbestände übernommen wurden. Ergänzen Sie fachliche Referenzobjekte und Beziehungen. Prüfen Sie wichtige Stammdaten, Status, Nummernbezüge und benötigte Historie. Eine identische Anzahl Datensätze belegt nicht automatisch korrekte Zuordnung. Wenn Daten maskiert oder transformiert wurden, werden diese Regeln mitgeprüft und vom ursprünglichen Bestand unterscheidbar dokumentiert.

Die Konfiguration kann von Datenübernahme und Softwarestand abweichen. Prüfen Sie, welche kundenspezifischen Einstellungen und Erweiterungen für den Test relevant sind. Danach folgt die Ausführbarkeit eines bekannten Prozessfalls. Alle drei Ebenen liefern unterschiedliche Aussagen. „Daten vorhanden“ bedeutet nicht „Prozess repräsentativ“; „Prozess läuft“ bedeutet nicht „alle benötigten Daten vollständig“. Die Abnahme verbindet die für den vorgesehenen Zweck erforderlichen Nachweise.

Quellen: [2] [3]

Benutzer und Berechtigungen nach dem Refresh bewerten

Übernommene Konten können im Ziel ungeeignete Rechte oder historische Zugriffsstände besitzen. Prüfen Sie vorgesehene Rollen, technische Benutzer, externe Beteiligte und gesperrte Konten. Ein Projektadministrator sollte nicht automatisch Zugriff auf alle produktiven vertraulichen Daten erhalten. Die Berechtigung folgt dem Zielzweck. Auch Verbindungen zum Identitätsdienst werden auf den richtigen Kontext geprüft.

Testen Sie relevante erlaubte und abgewiesene Aktionen. Bewerten Sie, ob vorhandene Testidentitäten erhalten oder neu eingerichtet werden müssen. Historische Benutzerzuordnungen und aktive Zugriffsrechte sind getrennte Fragen. Eine Maskierung von Anzeigenamen darf notwendige Testbeziehungen nicht unbeabsichtigt zerstören. Zugleich darf eine historische Referenz nicht als Grund dienen, ausgeschiedenen Mitarbeitern erneut Zugang zu geben. Die konkrete Umsetzung wird nachvollziehbar im Zielkonzept festgehalten.

Quellen: [2]

Repräsentativität für Validierungstests nachweisen

Wenn das Ziel für einen GxP-Nachweis genutzt wird, dokumentieren Sie relevante Unterschiede zur vorgesehenen Produktion. Dazu können Schnittstellenersatz, Datenvolumen, Softwarekomponenten, Drucker und Berechtigungen gehören. Nicht jede Abweichung macht einen Test ungeeignet. Sie muss jedoch in Bezug auf die konkrete Prüfaussage bewertet werden. Ein simulierter Laborwert kann eine Mappingregel prüfen, aber nicht automatisch die reale Ende-zu-Ende-Übertragung belegen.

Legen Sie ergänzende Nachweise für nicht repräsentative Teile fest. Beschreiben Sie, welche Kontrollen später in einer geeigneten Umgebung erfolgen müssen. Halten Sie den verwendeten Stand stabil oder bewerten Sie weitere Änderungen vor der Testausführung. Ein neuer Refresh während eines laufenden Testzyklus kann Ausgangsdaten und bereits erzeugte Nachweise entwerten. Die Beteiligten müssen erkennen können, auf welchen Stand jedes Ergebnis zurückgeht.

Quellen: [2]

Freigabe, Wiederholbarkeit und nächste Änderung

Der Abschluss verbindet Kopierumfang, technische Nacharbeiten, Datenabgleich, Berechtigungen, Referenzfälle und bekannte Grenzen. Benennen Sie die erlaubte Nutzung. Eine Umgebung kann für Entwicklung bereit sein, während noch Bedingungen für einen formalen Prozessnachweis fehlen. Diese Unterschiede sollten sichtbar sein und nicht allein im Wissen eines Administrators verbleiben. Offene kritische Zielverbindungen werden vor der betreffenden Nutzung geklärt.

Für wiederkehrende Refreshes eignet sich ein gepflegtes Verfahren mit kontrollierten Eingängen und Abnahmekriterien. Automatisierte Kontrollen können typische Fehlkonfigurationen erkennen. Prüfen Sie jedoch ihre Wirksamkeit und Änderungen. Eine Liste, die bei jedem Lauf nur erneut unterschrieben wird, belegt keine tatsächliche Prüfung. Gute Post-Copy-Arbeit liefert einen nachvollziehbaren Zielzustand und macht den nächsten Testzyklus verlässlich planbar.

Quellen: [2] [1]

Häufige Fragen zu SAP-Systemkopie: Validierung

Sind Systemkopie und Mandantenrefresh dasselbe?

Nein. Umfang und technische Wirkung hängen vom konkreten Verfahren ab. Beschreiben Sie, welche Daten, Konfigurationen und Komponenten übernommen werden. Die Nacharbeiten werden daraus abgeleitet. Eine allgemeine Checkliste kann unterstützen, ersetzt aber keine Bewertung des tatsächlichen Kopierwegs und der Zielumgebung.

Reicht ein erfolgreicher SAP-Start nach der Kopie?

Nein. Er bestätigt nur einen technischen Teilzustand. Prüfen Sie relevante Daten, Konfigurationen, Verbindungen, Jobs und Berechtigungen. Für Validierungstests muss zusätzlich die Eignung der Umgebung für die jeweilige Prüfaussage nachvollziehbar sein. Ein laufendes System kann weiterhin falsche produktive Ziele verwenden.

Müssen alle Schnittstellen im Testsystem ausgeschaltet werden?

Nicht pauschal. Benötigte Tests können kontrollierte Verbindungen verlangen. Entscheidend ist, welche Gegenstellen und Wirkungen ausdrücklich erlaubt sind. Produktive Aktionen dürfen nicht unbeabsichtigt ausgelöst werden. Prüfen Sie Zieladressen, Identitäten und Verarbeitung anhand des freigegebenen Zielkonzepts.

Darf eine Produktionskopie unverändert für Tests genutzt werden?

Das braucht eine Bewertung von Zweck, Zugriff, Schutz und datenschutzrechtlicher Zulässigkeit. Für manche Prüfungen sind maskierte oder synthetische Daten geeigneter. Prüfen Sie außerdem aktive Jobs und Kommunikationswege. Die Bezeichnung Testsystem allein rechtfertigt weder jeden Datenzugriff noch jede ausgehende Verarbeitung.

Kann Post-Copy-Automation die Abnahme ersetzen?

Nein. Sie kann definierte Nacharbeiten ausführen und dokumentieren. Die Abnahme prüft, ob der benötigte Zielzustand tatsächlich erreicht ist. Umfang und Grenzen der Automatisierung müssen bekannt sein. Ergänzen Sie geeignete technische und fachliche Kontrollen statt allein einen erfolgreichen Automationsstatus zu übernehmen.

Quellen: [1]

Was passiert mit bereits ausgeführten Tests nach einem Refresh?

Bewerten Sie, ob ihr nachgewiesener Stand und ihre Aussage weiterhin zur vorgesehenen Freigabe passen. Ein Refresh kann Daten, Konfigurationen oder Abhängigkeiten verändern. Frühere Ergebnisse bleiben historische Nachweise, dürfen aber nicht ungeprüft dem neuen Stand zugerechnet werden. Erforderliche Wiederholungen werden begründet festgelegt.

Quellen & fachlicher Stand

Stand: 14. Oktober 2026. Regulatorische Einordnung und Herstellerfunktionen sind getrennt belegt. Beispiele, Testmatrizen und Vorlagen sind eigene Arbeitshilfen; sie werden für den tatsächlichen Einsatzzweck angepasst.

  1. SAP: ABAP Post-Copy Automation Configuration Guide
  2. Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
  3. PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)

Zuletzt fachlich geprüft am 14.10.2026.

Daniel Herrmann, Daniel Herrmann Consulting

Daniel Herrmann Consulting

Wie wir Sie dabei unterstützen

Daniel Herrmann Consulting verbindet die fachliche Bewertung mit der Arbeit am konkreten System. Im Erstgespräch klären wir Ihren Einsatzzweck, vorhandene Nachweise und den nächsten sinnvollen Schritt.

  • IT-GxP-Consulting →

    Anforderungen, Tests und Umsetzung für Ihren konkreten Systemprozess zusammenführen.

Ihr Vorhaben besprechenEinblicke in unsere Projektarbeit →