Inhaltsverzeichnis
Das Wichtigste vorab
Wie validiert man SAP S/4HANA Cloud Public Edition im GxP-Umfeld?
Validiert wird der vorgesehene Geschäftsprozess mit seiner Konfiguration, Datenverarbeitung, Erweiterung und Integration. Bewerten Sie Lieferantennachweise, Verantwortlichkeiten und eigene Prozessrisiken. Für Releases werden Änderungen auf Relevanz geprüft und betroffene Funktionen mit passenden Nachweisen bewertet. Der Cloudanbieter übernimmt seine vereinbarten Leistungen; die Eignungsentscheidung für den regulierten Einsatz bleibt beim Anwender.
Public Edition ist ein eigenes Betriebsmodell
Unterscheiden Sie SAP S/4HANA Cloud Public Edition von Private Edition und On-Premise. Releasewege, Erweiterungsmöglichkeiten und Betriebsverantwortungen können sich unterscheiden. Ein vorhandenes Validierungskonzept für eine andere Edition lässt sich daher nicht unverändert übertragen. Dokumentieren Sie Produkt, Landschaft, verwendete Geschäftsprozesse und die relevanten Integrationen. Prüfen Sie, welche Systeme neben dem ERP eine qualitätsrelevante Entscheidung beeinflussen.
SAP beschreibt für die Public Edition regelmäßige große Upgrades und eine vorgezogene Bereitstellung im Testsystem. Die referenzierte Dokumentation nennt zwei große Upgrades pro Jahr. Der aktuelle Terminplan, die tatsächliche Systemlandschaft und weitere Änderungen werden im Projekt verbindlich abgeglichen. Der technische Rhythmus ist eine Planungsgrundlage, keine Vorgabe für einen pauschalen Umfang Ihrer GxP-Tests. Nicht jede Änderung betrifft jeden Anwender in gleichem Maß.
Verantwortung an konkreten Leistungen festmachen
Erstellen Sie eine Verantwortungsmatrix für Entwicklung, Hosting, Konfiguration, Stammdaten, Schnittstellen, Benutzerverwaltung und fachliche Freigabe. „SAP betreibt die Cloud“ ist dafür zu grob. Weitere Implementierungspartner und Plattformdienste können beteiligt sein. Legen Sie fest, welche Nachweise Sie vom jeweiligen Lieferanten erhalten, wie Änderungen kommuniziert werden und wer offene Fragen bewertet. Verträge und tatsächliche Betriebsabläufe müssen zueinander passen.
Der regulierte Anwender bewertet den vorgesehenen Einsatz und die Abdeckung seiner Anforderungen. Lieferantentests können relevante Standardfunktionen belegen, decken aber nicht automatisch Ihre konkrete Konfiguration oder vollständige Prozesskette ab. Prüfen Sie Version, Umfang, Qualität und Übertragbarkeit der Unterlagen. Eine allgemeine Herstellerbescheinigung ist kein Ersatz für diesen Abgleich. Ebenso wenig ist es sinnvoll, sämtliche Standardtests ohne eigene Risikofrage erneut auszuführen.
Quellen: [2]
GxP-Scope entlang des Geschäftsprozesses bestimmen
Beschreiben Sie den tatsächlichen Ablauf, beispielsweise Wareneingang, Qualitätsstatus, Lagerbewegung und Auslieferung. Bestimmen Sie die relevanten Daten und Entscheidungen. Nicht jedes ERP-Feld ist automatisch gleich kritisch. Ein kaufmännischer Bericht und eine freigaberelevante Chargenentscheidung können im selben System liegen, benötigen aber unterschiedliche Nachweise. Die Begründung des Scopes sollte für Fachbereich, IT und QA verständlich sein.
Ergänzen Sie Grenzen und externe Abhängigkeiten. Stammt der Qualitätsstatus aus einem QMS? Erzeugt ein anderer Dienst Etiketten oder Zertifikate? Welcher Stand ist bei widersprüchlichen Informationen maßgeblich? Ein durchgängiges Prozessbild verhindert, dass die Validierung an der ERP-Oberfläche endet, obwohl die eigentliche Entscheidung erst nach einer Schnittstelle erfolgt. Die Systemgrenze wird durch den Verwendungszweck bestimmt und nicht allein durch Lizenz- oder Projektpakete.
Quellen: [2]
Erstvalidierung: Konfiguration und Betrieb zusammen prüfen
Erfassen Sie Anforderungen, bewertete Lieferantenunterlagen und die relevante Kundenkonfiguration. Prüfen Sie kritische Funktionen mit geeigneten positiven, negativen und Grenzfällen. Verwenden Sie realistische Rollen und kontrollierte Testdaten. Ein Test mit einem Implementierungsadministrator kann fehlende Beschränkungen verdecken. Halten Sie den tatsächlich geprüften Stand fest, einschließlich relevanter Integrationen und Erweiterungen.
Der Nachweis umfasst außerdem Betrieb: Änderung, Zugriff, Protokollierung, Datenaufbewahrung, Störungsbehandlung und benötigte Recherche. Prüfen Sie, welche Wiederherstellungs- oder Exportleistungen der Anbieter erbringt und welche fachlichen Kontrollen beim Anwender bleiben. Eine allgemeine Backupbeschreibung bestätigt nicht automatisch die Wiederherstellung einer konkreten fehlerhaften Geschäftsaufzeichnung. Bewerten Sie die für Ihren Prozess benötigten Szenarien und vereinbarten Möglichkeiten.
Konstruiertes Releasebeispiel: eine relevante Statusprüfung
Im Beispiel beeinflusst eine Änderung den Ablauf vor der Auslieferung. Eine weitere Releasefunktion betrifft nur eine nicht verwendete Auswertung. Das Team ordnet beide Änderungen dem Systeminventar und den freigegebenen Prozessen zu. Für die Statusprüfung wird ein gezielter Test vorgesehen; die nicht verwendete Funktion erhält eine dokumentierte Begründung, warum daraus aktuell kein zusätzlicher Prozessnachweis folgt.
Der relevante Test prüft eine freigegebene, eine gesperrte und eine nicht eindeutig zuordenbare Charge. Ergänzend wird der tatsächliche Schnittstellenweg betrachtet. Das Soll entsteht aus der bestehenden Prozessregel und den geänderten Funktionen. Eine Screenshotreihe des neuen Menüs würde diese Frage nicht beantworten. Die folgende Matrix ist eine eigene Arbeitshilfe. Sie beschreibt keine festen gesetzlichen Testklassen und keine von SAP zugesicherte Wirkung eines bestimmten Releases.
| Änderung | Eigene Relevanzfrage | Möglicher Nachweis |
|---|---|---|
| Statusprüfung | Ändert sich erlaubte Weiterverarbeitung? | Positive und negative Prozessfälle |
| Schnittstellenfeld | Ändern sich Bedeutung oder Format? | Mapping und Zielzustand prüfen |
| Rollenfunktion | Werden Zugriffe erweitert oder entzogen? | Tests mit vorgesehenen Rollen |
| Nicht genutzte Funktion | Kann sie bestehende Prozesse beeinflussen? | Begründete Auswirkungsbewertung |
| Ausgabe | Ändert sich ein benötigtes Dokument? | Inhalt, Empfänger und Stand vergleichen |
| Betriebsfunktion | Ändert sich Review oder Recherche? | Passenden Betriebsfall ausführen |
Releasebewertung als wiederkehrenden Ablauf organisieren
Beginnen Sie mit Releaseinformationen und dem eigenen Nutzungsinventar. Ordnen Sie Änderungen betroffenen Anforderungen, Konfigurationen, Datenwegen und Betriebsregeln zu. Dokumentieren Sie auch begründete Nichtbetroffenheit. Die Bewertung sollte durch fachlich geeignete Verantwortliche erfolgen. Eine automatische Suche nach „GxP“ in Release Notes kann Hinweise liefern, erfasst aber nicht zuverlässig die Bedeutung einer Änderung für Ihren individuellen Ablauf.
Planen Sie das Testfenster und benötigte Daten frühzeitig. Prüfen Sie, welche Funktionen im Testsystem tatsächlich dem späteren produktiven Stand entsprechen. Offene Befunde brauchen eine Bewertung vor der relevanten Nutzung. Wenn Risiken nicht ausreichend beherrscht sind, werden geeignete Maßnahmen mit Anbieter und Verantwortlichen geklärt. Ein technisch feststehender Upgradetermin legitimiert keine ungeprüfte Fortsetzung eines unvertretbaren Prozesses. Eskalation und Entscheidung müssen deshalb im Betriebsmodell vorgesehen sein.
Quellen: [2]
Automatisierung gezielt und kontrolliert einsetzen
Wiederkehrende Prüffälle können automatisiert werden, wenn erwartete Ergebnisse, Daten und Auswertung zuverlässig sind. Gute Kandidaten haben stabile fachliche Aussagen, etwa eine Statussperre oder ein Schnittstellenabgleich. Ein automatisierter Test sollte nicht nur bestätigen, dass eine Seite erreichbar ist. Er muss erkennen, ob der relevante Zielzustand erreicht oder ein unerlaubter Zustand verhindert wurde.
Bewerten Sie Testwerkzeuge und Skripte entsprechend ihrer Funktion im Nachweisprozess. Veränderte Oberflächen können technische Tests fehlschlagen lassen, ohne dass der Fachprozess falsch ist; umgekehrt können schwache Assertions einen echten Fehler übersehen. Halten Sie Wartung und Ergebnisbewertung verantwortlich. Automatisierung reduziert wiederholte Arbeit, ersetzt aber keine Auswirkungsanalyse. Ein ungepflegtes Regressionstestpaket mit vielen grünen Ergebnissen liefert nur begrenzte Sicherheit über neu hinzugekommene Risiken.
Quellen: [2]
Abschluss und dauerhafte Nachweisfähigkeit
Die Releaseentscheidung verbindet betroffene Prozesse, geprüften Stand, Ergebnisse, Abweichungen und erforderliche Betriebsmaßnahmen. Grenzen werden ausdrücklich benannt. Nach dem Produktivwechsel folgen die begründeten Kontrollen, die sich nur dort ausführen lassen. Diese sind vorab geplant und dürfen nicht als Ersatz für zuvor mögliche Tests verwendet werden. Halten Sie fest, wer die Nutzung im verantworteten Umfang bestätigt.
Pflegen Sie Prozessinventar und Referenztests mit jedem relevanten Änderungsereignis. Das verhindert, dass Wissen bei einzelnen Mitarbeitern bleibt und jedes Release wieder bei null beginnt. Für mehrere GxP-Systeme lohnt eine gemeinsame Governance mit systemspezifischen Nachweisen. Der Maßstab ist ein ausführbarer Lebenszyklus: Verantwortlichkeiten, bewertete Änderungen und rekonstruierbare Entscheidungen. Ein umfangreiches Einführungsdossier allein stellt diesen dauerhaften Betrieb nicht sicher.
Quellen: [2]
Häufige Fragen zu S/4HANA Public Cloud: Validierung
Ist SAP S/4HANA Cloud Public Edition bereits vom Hersteller validiert?
Der Hersteller stellt Funktionen und gegebenenfalls geeignete Nachweise für seinen Leistungsumfang bereit. Der regulierte Anwender bewertet den konkreten Verwendungszweck, Konfigurationen und Integrationen. Lieferantennachweise können genutzt werden, müssen aber auf Umfang und Übertragbarkeit geprüft werden. Eine pauschale Kundenfreigabe folgt daraus nicht.
Quellen: [2]
Muss nach jedem Cloudrelease alles neu getestet werden?
Der Umfang richtet sich nach den bewerteten Änderungen und betroffenen Risiken. Gezielte Funktions-, Prozess- und Betriebsnachweise können angemessen sein. Dokumentieren Sie auch begründete Nichtbetroffenheit. Ein pauschaler Volltest ist ebenso wenig immer sinnvoll wie ein vollständiger Testverzicht aufgrund des Cloudbetriebs.
Kann das Validierungskonzept der Private Edition übernommen werden?
Nur nach Bewertung der Unterschiede. Betriebsmodell, Releasewege, Erweiterungen und Verantwortlichkeiten können abweichen. Übernehmen Sie geeignete Prinzipien und Referenzfälle, passen Sie jedoch Scope und Kontrollen an die tatsächliche Public-Edition-Landschaft an. Der gleiche Produktfamilienname belegt keine identische Nachweisstrategie.
Reichen die Release Notes für die Änderungsbewertung?
Sie sind ein wichtiger Eingang, aber keine vollständige kundenspezifische Bewertung. Ordnen Sie die Änderungen Ihren Prozessen, Konfigurationen, Daten und Integrationen zu. Fehlende Details werden mit dem Lieferanten geklärt. Die dokumentierte Entscheidung muss erkennen lassen, warum ein zusätzlicher Nachweis erforderlich ist oder entfällt.
Können automatisierte SAP-Tests den Fachreview ersetzen?
Nein. Automatisierte Prüffälle können definierte Aussagen wiederholt prüfen. Die Auswirkungsanalyse legt erst fest, welche Aussagen nach einer Änderung relevant sind. Ergebnisse und Fehlermeldungen benötigen eine geeignete Bewertung. Neue Funktionen oder geänderte Prozessgrenzen können außerhalb des bisherigen Testpakets liegen.
Was gehört in ein dauerhaftes Public-Cloud-Validierungskonzept?
Mindestens der definierte Einsatz, Verantwortlichkeiten, Lieferantenbewertung, Kundenkonfiguration, passende Nachweise und kontrollierte Betriebsprozesse. Ergänzen Sie einen wiederkehrenden Releaseablauf mit Relevanzbewertung, Tests und Entscheidung. Umfang und Dokumentstruktur werden an Prozess, Risiko und verfügbare Nachweise angepasst.
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.
- SAP S/4HANA Cloud Public Edition: Upgrade Timeline
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
- PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)
Zuletzt fachlich geprüft am 14.10.2026.
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-Compliance-Programm →
Ein wiederverwendbares IT-GxP-Compliance Framework mit Verantwortlichkeiten und umsetzbaren Prozessen aufbauen.