SAP S/4HANA validieren - und validiert betreiben.
ERP-Systeme wie SAP S/4HANA tragen die GxP-Kernprozesse, von der Herstellung über die Freigabe bis zur Distribution von Arzneimitteln und Medizinprodukten. Damit gehören sie zu den kritischsten Systemen im Unternehmen. Validiert wird auch hier die Anwendung im Prozess, gegen den Intended Use. Cloud-Betriebsmodelle wie RISE with SAP ändern daran nichts, aber sie ändern die Arbeitsteilung: SAP betreibt die Plattform, der Nachweis bleibt beim Betreiber. Wir ordnen diese Verantwortungen, erweitern SAP Activate um die Validierungsaspekte und planen den Betrieb von Anfang an mit.
Was SAP übernimmt und was bei Ihnen bleibt.
Mit RISE with SAP (S/4HANA Cloud Private Edition) mietet das Unternehmen Betrieb und technische Plattform. SAPs vertraglicher Roles-&-Responsibilities-Katalog regelt die Arbeitsteilung in Leistungskategorien, und seine Grundregel ist eindeutig: Was nicht gekauft oder als Standardleistung erbracht wird, liegt beim Kunden. Für den GxP-Betreiber heißt das: Validiert wird die Anwendung im Prozess, und diese Pflicht behält der Betreiber auch im RISE-Modell.
| Ebene | SAP (RISE) | Beim Betreiber |
|---|---|---|
| Technische Plattform (Rechenzentrum, OS-Lifecycle, Datenbank-Upgrades, Infrastruktur-Security) | Standardleistung | Lieferantenaufsicht nach EU GMP Annex 11: Nachweise bewerten, auch für Subprovider |
| GxP-Leistungen (Installation Qualification, reguliertes Change- und Konfigurationsmanagement, Periodic Review) | kostenpflichtige Optional Services ("must be specifically contracted for") | vertraglich vereinbaren, bewerten und ins eigene QMS einbinden |
| Funktionales Testen und Abnahme von Änderungen, einschließlich der von SAP eingespielten Security Notes | Excluded Task ("can only be performed by the customer") | vollständig beim Betreiber |
| Validierung gegen den Intended Use | kein SAP-Angebot | der Kern der Betreiberpflicht: Eignung im eigenen Prozess nachweisen |
Diese Trennlinie ist unsere GAMP-konsistente Einordnung: Unten liegt die Plattform, die auf qualifizierter Infrastruktur aufsetzt, darüber liegen Verifizierung und Validierung der Anwendung. Der Katalog selbst spricht nicht von Validierung. Die Substanz bleibt dieselbe. Die Verifizierung auf Anwendungsebene ist nicht an SAP delegierbar, und die Lieferantenaufsicht bleibt beim Betreiber, auch dort, wo SAP Hyperscaler als Subprovider einsetzt.
Vom Standard zum validierten System.
SAPs Einführungsmethodik SAP Activate führt über Fit-to-Standard-Workshops zum Zielbild. Was ihr in unseren Projekten fehlte, waren die Validierungsaspekte, und genau deshalb haben wir die Methodik erweitert: Aus den Fit-to-Standard-Entscheidungen entstehen Intended Use, Anforderungen und Risikobewertung in einem Zug. Standard vor Konfiguration, Aufwand nach Risiko.
- 1
Audit & Bewertung
Ist-Stand von Validierung und Betrieb des ERP-Systems; Bewertung von Prozessen, Stammdaten und Berechtigungskonzepten als Ausgangspunkt.
- 2
Fit-to-Standard & Intended Use
Die Workshops klären, was der Standard leistet, und halten fest, wofür das System im Prozess gebraucht wird. Der Intended Use kommt aus dem Prozess: die Absicht, für die das System gebaut, angepasst und erweitert wird. Nach der Umsetzung prüft der Betreiber, ob das System diese Absicht erfüllt.
- 3
Anforderungen & Risikoanalyse
Anforderungsmanagement als zentrales Element; Risikoanalysen gewichten Prozesse und Funktionen nach dem Patienten-, Produkt- und Datenintegritätsrisiko. Dazu gehört die Identifikation organisatorischer Risiken: Anforderungen, die das System nicht oder nur mit unverhältnismäßigem Aufwand abdeckt, werden benannt und prozessual abgefangen.
- 4
Validierung
Prozessorientierte Dokumentation, risikobasierte Teststrategie und Datenintegrität inkl. 21 CFR Part 11 und EU GMP Annex 11: elektronische Aufzeichnungen, Audit Trail, Zugriffs- und Stammdatenmanagement.
- 5
Betrieb & Application Management
IT-Qualifizierung und Betriebsprozesse: Transportwesen, Berechtigungs- und Konfigurationsmanagement. Hinzu kommen Change- und Prozessmanagement entlang definierter Schnittstellen zwischen Fachbereich und IT.
- 6
Periodische Evaluierung
Der validierte Zustand wird wiederkehrend bestätigt, damit das System über seinen Lebenszyklus beherrschbar bleibt.
Auf Kundenwunsch kann KI im Projekt unterstützen, etwa beim Entwurf von Testfällen und Dokumentation. Wir schaffen auch die Voraussetzung dafür: die Use-Case-Einbindung in die AI Governance, mit menschlicher Aufsicht über jede Entscheidung.
Validierungsaufwand nach Anpassungstyp.
ERP-Systeme sind hochkonfigurierbar. Der Dokumentations- und Testaufwand steigt mit der Tiefe der Anpassung, vom genutzten Standardumfang über die Konfiguration bis zur WRICEF-Eigenentwicklung.
| Anpassungstyp | Standard | Konfiguration | WRICEF-Eigenentwicklung |
|---|---|---|---|
| Was dahintersteht | genutzter Standardumfang des ERP-Systems | parametrierte Anpassung innerhalb des Standards | firmenspezifische Erweiterung (Workflow, Report, Interface, Conversion, Enhancement, Form) |
| Dokumentationsaufwand | geringster Aufwand | erhöhter Aufwand | höchster Aufwand |
| Einsatzregel | Standard nutzen, wo er die Anforderung erfüllt | nur dort, wo der Standard nicht ausreicht | nur dort, wo nötig, und dann angemessen dokumentiert und getestet |
| Validierungsaufwand | folgt der GxP-Relevanz und Risikoanalyse | folgt der GxP-Relevanz und Risikoanalyse | folgt funktionaler Komplexität und festgestelltem Risiko |
Clean Core ist dabei zunächst Technik: Erweiterungen liegen auf der SAP Business Technology Platform (BTP) statt im Kern. Der Nachweis folgt weiter der Art der Änderung: Extensions und Integrationen werden gegen ihre Spezifikation verifiziert, Namensräume trennen Template und Lokalisierung sauber. Die BTP selbst ist Platform as a Service und wird wie ausgelagerte Infrastruktur behandelt: kontinuierlich überwacht, mit einem einmal etablierten Monitoring-Plan. Er ändert sich mit der eigenen Anwendung, nicht mit jedem Plattform-Update des Anbieters. In unseren SAP-Projekten ist diese Plattform-Kontrolle fester Bestandteil der Betriebsplanung. Wie das im Konzernmaßstab trägt, zeigt unsere S/4HANA-Template-Fallstudie.
Was ändert die Cloud am validierten Zustand?
Cloud-Betriebsmodelle ändern den Takt auf zwei Arten: SAP Cloud ALM wird täglich produktiv aktualisiert, ohne Opt-out und ohne Kunden-Wartungsfenster. Die Private Edition behält dagegen die vertraute Release-Mechanik bei, nur in dichterer Folge. In beiden Fällen trägt eine Einmal-Validierung nicht. Die Antwort ist der risikobasierte Ansatz, wie ihn die FDA mit Computer Software Assurance formuliert hat. Die Methodik dazu liefert GAMP 5, getragen vom Risikomanagement nach ICH Q9(R1). In unseren Projekten übertragen wir diesen Ansatz auf die Release-Modelle der SAP-Cloud.
Die Mainstream-Wartung von SAP ECC und Solution Manager 7.2 endet 2027. S/4HANA-Migration und ALM-Werkzeugwechsel fallen damit zusammen. Wer SAP Cloud ALM einführt, plant die Validierungs-Toolkette am besten gleich mit.
SAP-Compliance, durchgängig begleitet.
Zwischen Methodik und Vertrag liegt die eigentliche Arbeit.
GAMP 5 (Second Edition) deckt Cloud-Infrastruktur, externe Provider und Shared Responsibilities ab. Die Übersetzung der Methodik in die Vertrags- und Release-Realität der SAP-Cloud ist Projektarbeit.
Genau dort arbeiten wir: Wir haben SAP Activate in eigenen Projekten um die fehlenden Validierungsaspekte erweitert, S/4HANA als Private-Cloud-Plattform im Konzernmaßstab mit sauberer Namensraum-Trennung zwischen Template und Lokalisierung eingeführt und Validierungswerkzeuge über die Standard-APIs an die SAP-Toolkette angebunden. Die Methodik dahinter kennen wir von innen: aus dem Kernteam der GAMP 5 Second Edition.
Häufige Fragen zur SAP S/4HANA Validierung.
Nein. SAP betreibt die technische Plattform; GxP-Leistungen wie die Installation Qualification oder der Periodic Review sind kostenpflichtige Optional Services. Funktionales Testen und die Abnahme von Änderungen sind vertraglich Excluded Tasks und nach SAPs eigenem Katalog nur durch den Kunden leistbar. Die Validierung gegen den Intended Use bleibt Betreiberpflicht.
Die GxP-Option ist eine separate Subscription und damit ein Baustein, kein Nachweis. Ihr Leistungsumfang steht im nicht öffentlichen Addendum zum Kundenvertrag und umfasst laut SAP die Services für Qualifizierung und Konformität mit 21 CFR Part 11 und EU GMP Annex 11. Was sie liefert, ist vertraglich präzise zu vereinbaren und zu bewerten. Den Nachweis der Eignung im eigenen Prozess ersetzt sie nicht.
Nein, aber jedes Release wird bewertet. Change Control und die Regressionsstrategie entscheiden, was nachzutesten ist. Die Evidenz des Anbieters fließt in die Bewertung ein, ohne dass der Betreiber die Tests wiederholt. Der Maßstab bleibt risikobasiert: Es entsteht nicht mehr Aufwand, als das Risiko rechtfertigt.
Zunächst wenig: Welcher Beleg zu erbringen ist, hängt weiterhin von der Art der Änderung ab, nicht davon, ob sie im Kern oder auf der BTP liegt. Neu ist der Blick auf die Plattform selbst: Die BTP ist Platform as a Service und gehört in die Lieferantenaufsicht. SAPs BTP-Whitepaper unterstützt dabei laut eigener Zweckbestimmung das Vendor Assessment. SAP selbst weist ihm keine größere Rolle zu.
Stand:
Migration und Validierung zusammen planen.
Ob RISE-Umstieg, S/4HANA-Migration oder der Wechsel auf SAP Cloud ALM: Im Erstgespräch klären wir den Stand Ihres Vorhabens und wie Sie den Nachweis führen, von der Migration bis in den laufenden Betrieb. Kostenfrei, etwa 30 Minuten.
Erstgespräch vereinbaren
