SAP S/4HANA validieren: Schnittstellen und Datenmigration

Eine GxP-konforme S/4HANA-Validierung muss die Datenkette absichern, nicht nur einzelne SAP-Transaktionen. Für jede kritische Schnittstelle und jedes Migrationsobjekt braucht es einen definierten Scope, kontrolliertes Mapping, nachvollziehbare Transformationen, technische Fehlerbehandlung und eine fachliche Abstimmung zwischen Quelle und Ziel. Der Nachweis endet erst, wenn Vollständigkeit, Richtigkeit und Verwendbarkeit der Daten für den vorgesehenen Prozess belegt sind.

Warum der größte Validierungsblinde Fleck zwischen den Systemen liegt

Das SAP-Programm meldet erfolgreiche Unit- und Integrationstests. Gleichzeitig bleiben offene Fragen: Wurden alle freigaberelevanten Materialstämme übernommen? Erreicht jede Qualitätsmeldung das Zielsystem? Was passiert bei einem abgebrochenen Schnittstellenlauf? Und lassen sich historische Entscheidungen nach dem Cutover noch rekonstruieren?

Diese Fragen liegen nicht in einem einzelnen Modul. Sie liegen zwischen SAP, LIMS, MES, Lager, Qualitätsplattformen und Archiv. Genau dort treffen fachliche Regeln, technische Transformationen und regulatorische Records aufeinander.

EU GMP Annex 11 fordert, dass Anforderungen auf dokumentierter Risikobewertung und GMP-Wirkung beruhen. Für elektronische Datenaustausche sollen Kontrollen zur korrekten und sicheren Eingabe und Verarbeitung eingebaut sein. Bei der Übertragung in andere Datenformate oder Systeme ist zu prüfen, dass Wert und Bedeutung der Daten nicht verändert werden.

Die SAP-Validierung für Pharma muss diese Anforderungen in die Programmplanung integrieren. Ein separates CSV-Teilprojekt am Ende erkennt Lücken zu spät.

Migration und Schnittstelle sind zwei unterschiedliche Kontrollobjekte

SAP beschreibt das S/4HANA Migration Cockpit als Werkzeug für die initiale Datenübernahme. Migration Objects definieren Quell- und Zielstrukturen, Feldzuordnungen sowie Transformationsregeln. Das Werkzeug ist nicht für einen kontinuierlichen Datenaustausch zwischen Systemen vorgesehen.

Diese Trennung ist auch für die Validierung entscheidend:

Kontrollobjekt	Datenbewegung	Typischer Nachweis
Datenmigration	Einmalige oder phasenweise Übernahme zum Cutover	Scope, Mapping, Probeläufe, Abstimmung, Freigabe
Laufende Schnittstelle	Wiederkehrender Austausch im Betrieb	Trigger, Transformation, Fehlerbehandlung, Monitoring, Reprocessing
Historisches Archiv	Langfristiger Erhalt nicht migrierter Records	Vollständigkeit, Kontext, Lesbarkeit, Retrieval-Test
Manuelle Übernahme	Kontrollierte Eingabe ausgewählter Werte	Vier-Augen-Prinzip, Eingabeprüfung, Herkunftsnachweis

Ein einziger „End-to-End-Test“ kann diese Nachweise nicht ersetzen. Migration, Integration und Archiv benötigen jeweils eigene Akzeptanzkriterien.

GxP-kritische Schnittstellen priorisieren

1. Mit dem Geschäftsprozess beginnen

Listen Sie nicht zuerst IDoc-, API- oder Dateischnittstellen auf. Starten Sie bei der Qualitätsentscheidung. Welche Daten benötigt der Prozess, um Material zu sperren, eine Charge freizugeben, ein Ergebnis zu bewerten oder eine Abweichung zu bearbeiten?

Danach wird die technische Kette zugeordnet. Ein kritischer Datenfluss kann mehrere Systeme, Warteschlangen und Transformationsschritte umfassen.

2. Kritikalität je Datenobjekt festlegen

Nicht jede übertragene Spalte hat dieselbe Wirkung. Priorität haben Daten, deren Verlust, Verfälschung oder Verzögerung eine GMP-Entscheidung beeinflussen kann.

Typische Beispiele sind Materialstatus, Chargenattribute, Prüfergebnisse, Freigabestatus, Haltbarkeitsdaten, Qualitätsmeldungen, elektronische Signaturen oder Zuordnungen zu Spezifikationen.

3. Fehlerwege als Intended Use behandeln

Eine Schnittstelle ist nicht validiert, wenn nur der fehlerfreie Lauf getestet wurde. Das Team muss festlegen, wie Dubletten, fehlende Pflichtfelder, ungültige Werte, Zeitüberschreitungen, Teilübertragungen und Systemausfälle behandelt werden.

Der Nachweis beantwortet vier Fragen:

• Wird der Fehler zuverlässig erkannt?
• Bleiben Daten und Status konsistent?
• Kann eine autorisierte Rolle den Vorgang kontrolliert wiederholen?
• Ist erkennbar, welche Records betroffen waren?

4. Monitoring und Verantwortlichkeit verbinden

Ein technischer Fehlerhinweis ohne fachlichen Owner ist keine geschlossene Kontrolle. Für kritische Schnittstellen werden Alarm, Reaktionszeit, Eskalation, Reprocessing und Quality-Einbindung festgelegt.

Datenmigration in sechs kontrollierten Schritten

1. Scope und Abgrenzung dokumentieren

Definieren Sie, welche Stamm-, Bewegungs- und Bestandsdaten migriert werden. Ebenso wichtig ist die Negativliste. Nicht migrierte historische Daten brauchen eine kontrollierte Archiv- oder Stilllegungsstrategie.

Die Auswahl folgt Aufbewahrung, Prozessbedarf und GxP-Relevanz. Der Beitrag zur GxP-Datenarchivierung beschreibt den ergänzenden Nachweis.

2. Mapping und Transformation freigeben

Jedes kritische Feld braucht Quelle, Ziel, Format, Transformationsregel und fachlichen Owner. Default-Werte, Zusammenführungen und Werteableitungen werden ausdrücklich gekennzeichnet.

Mapping-Freigabe ist keine rein technische Aufgabe. Fachbereich und Quality müssen beurteilen können, ob Bedeutung und Verwendungszweck erhalten bleiben.

3. Datenqualität vor der Übernahme bewerten

Eine Migration korrigiert nicht automatisch unvollständige oder widersprüchliche Quelldaten. Vor dem Load werden Qualitätsregeln, Bereinigung, Dublettenbehandlung und Entscheidungsrechte festgelegt.

Bereinigungen bleiben nachvollziehbar. Sonst ist später nicht mehr erkennbar, ob ein Wert aus dem Quellsystem, einer Transformationsregel oder einer manuellen Entscheidung stammt.

4. Probeläufe mit messbaren Akzeptanzkriterien durchführen

Mehrere Probeläufe zeigen, ob Extraktion, Transformation, Load und Abstimmung stabil funktionieren. Akzeptanzkriterien können Record-Anzahlen, Summen, Schlüsselbeziehungen, Pflichtfelder, Fehlerraten und Stichproben kritischer Inhalte umfassen.

5. Quelle und Ziel abstimmen

Eine reine Erfolgsmeldung des Migrationstools reicht nicht. Die Abstimmung kombiniert technische Vollständigkeit und fachliche Richtigkeit.

Für kritische Objekte sollten mindestens Anzahl, Identität, Beziehungen, Status und ausgewählte Inhaltswerte verglichen werden. Abweichungen brauchen Bewertung und dokumentierte Entscheidung.

6. Cutover und Hypercare kontrollieren

Freeze-Zeitpunkt, letzte Delta-Übernahme, fachliche Freigabe und Rückfallentscheidung gehören in einen abgestimmten Cutover-Plan. Nach Go-Live überwacht Hypercare kritische Schnittstellen und Datenobjekte mit vorab definierten Kriterien.

Testdaten und Evidenz kontrollierbar halten

Probeläufe und Schnittstellentests benötigen repräsentative Daten. Produktive GxP-Daten sollten jedoch nicht unkontrolliert in Testumgebungen kopiert werden. Das Testdatenkonzept legt Herkunft, Schutz, Maskierung, Freigabe und Löschung fest.

Die Evidenz muss den ausgeführten Test mit Version, Mapping, Datenstand und Ergebnis verbinden. Screenshots allein sind bei großen Migrationen zu schwach. Maschinenlesbare Abstimmungsreports, Fehlerlisten und freigegebene Zusammenfassungen liefern eine bessere Kette. Sie müssen jedoch gegen Manipulation geschützt, verständlich und dem richtigen Lauf zugeordnet sein.

Auch der Umgang mit fehlgeschlagenen Probeläufen gehört in den Nachweis. Ein später erfolgreicher Lauf löscht die vorherige Abweichung nicht. Er zeigt erst zusammen mit Ursachenanalyse, Korrektur und Wiederholung, dass die Kontrolle wirksam funktioniert.

Für den finalen Lauf werden Werkzeuge, Skripte und Parameter versioniert freigegeben. So bleibt erkennbar, ob die produktive Übernahme tatsächlich mit der geprüften Konfiguration ausgeführt wurde.

Die finale Freigabe benennt Restabweichungen, offene Kontrollen und die verantwortlichen Owner für Hypercare ausdrücklich.

Ein integrierter Nachweis statt drei getrennter Testwelten

Die stärkste Struktur verbindet Prozessrisiko, technische Tests und Migration Evidence in einer Traceability-Kette:

1. GxP-Prozess und Intended Use
2. kritischer Record oder Datenobjekt
3. Quelle, Transformation und Ziel
4. Risiko und Kontrollmaßnahme
5. Testfall und objektive Evidenz
6. Abweichung und Freigabeentscheidung

Diese Kette verhindert, dass SAP-Projekt, Integrationspartner und Validierung unterschiedliche Vollständigkeitsbegriffe verwenden. Eine integrierte Validierungsplanung macht Verantwortlichkeiten bereits vor der Testphase sichtbar.

Häufige Fragen

Muss bei einem S/4HANA-Wechsel jedes SAP-Modul vollständig neu validiert werden?

Nicht pauschal. Der notwendige Umfang folgt Intended Use, GxP-Risiko, Migrationsansatz und tatsächlicher Änderung. Unveränderte, ausreichend belegte Funktionen können anders behandelt werden als neue Prozesse, Rollen, Datenmodelle oder Schnittstellen. Die Begründung muss systemspezifisch dokumentiert sein.

Wie weist man die Vollständigkeit einer Datenmigration nach?

Durch eine geplante Abstimmung zwischen Quelle und Ziel. Sie kombiniert Record-Anzahlen, Schlüssel, Summen, Beziehungen, Status und inhaltliche Stichproben kritischer Daten. Toolmeldungen werden durch fachliche Akzeptanz ergänzt.

Was gehört in einen GxP-Schnittstellentest?

Neben dem erfolgreichen Datenfluss gehören Transformation, Pflichtfelder, Dubletten, Ausfall, Wiederanlauf, Fehlerwarteschlange, Reprocessing, Berechtigung und Monitoring in den Scope. Der Test muss zeigen, dass Daten und fachlicher Status konsistent bleiben.

Primär- und Produktquellen

• EU GMP Annex 11: Computerised Systems, wirksame Fassung 2011
• SAP Help: Migrate Data Directly from SAP System
• SAP Help: What Data Can Be Migrated?

---

Autor

Daniel Herrmann Consulting — Boutique-Beratung für GxP-Compliance und Computer System Validation in Pharma, Biotech und MedTech. 15+ Jahre Hands-on-Expertise. 60+ validierte Systeme. 100 % Audit-Bestehensquote. 0 kritische Findings.