SAP S/4HANA validieren - und validiert betreiben.
ERP-Systeme wie SAP S/4HANA tragen die GxP-Kernprozesse - Herstellung, Freigabe und Distribution von Arzneimitteln und Medizinprodukten - und sind damit die kritischsten Systeme 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 schaffen Transparenz und unterstützen bei Strategie und Umsetzung - risikobasiert, entlang des Standards, mit dem Betrieb von Anfang an im Plan.
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 - mit einer eindeutigen Grundregel: 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 wandert nicht mit in den Vertrag.
| Ebene | SAP (RISE) | Beim Betreiber |
|---|---|---|
| Technische Plattform - Rechenzentrum, OS-Lifecycle, Datenbank-Upgrades, Infrastruktur-Security | Standardleistung | Lieferanten-Oversight 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 - auch SAP-eingespielter 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 |
Die Trennlinie - unten die Plattform, die auf qualifizierte Infrastruktur zurückgeht, oben Verifizierung und Validierung der Anwendung - ist unsere Einordnung: GAMP-konsistent, der Katalog selbst spricht nicht von Validierung. An der Substanz ändert das nichts. Die Verifikation auf Anwendungsebene ist nicht an SAP delegierbar, und die Lieferanten-Oversight 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 - die Validierungsaspekte fehlen ihr. In unseren Projekten haben wir die Methodik genau darum 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 ist die Absicht, für die gebaut, angepasst und erweitert wird; an ihr prüft der Betreiber nach der Umsetzung, ob das System sie erfüllt.
- 3
Anforderungen & Risikoanalyse
Anforderungsmanagement als zentrales Element; Risikoanalysen gewichten Prozesse und Funktionen am 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 inkl. Transportwesen, Berechtigungs- und Konfigurationsmanagement; Change- und Prozessmanagement entlang definierter Schnittstellen zwischen Fachbereich und IT.
- 6
Periodische Evaluierung
Der validierte Zustand wird wiederkehrend bestätigt - das System bleibt über seinen Lebenszyklus beherrschbar.
Auf Kundenwunsch kann KI im Projekt unterstützen - beim Entwurf von Testfällen und Dokumentation. Wir schaffen auch die Voraussetzungen dafür: die Use-Case-Einbindung in die AI Governance, mit menschlicher Aufsicht über jede Entscheidung.
Validierungsaufwand nach Anpassungstyp.
Moderne ERP-Systeme sind hochkonfigurierbar. Der Dokumentations- und Testaufwand steigt mit der Tiefe der Anpassung - vom genutzten Standardumfang über 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 - 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 - an der Art der Änderung und am Nachweis ändert das nichts. 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 Monitoring-Plan, der einmal etabliert wird und sich mit der eigenen Anwendung ändert - 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 takten anders - auf zwei Arten: SAP Cloud ALM wird täglich produktiv aktualisiert, ohne Opt-out und ohne Kunden-Wartungsfenster; die Private Edition dagegen behält die vertraute Release-Mechanik, nur im dichteren Takt. Eine Einmal-Validierung trägt in beidem nicht. Die Antwort ist der risikobasierte Ansatz, den Computer Software Assurance bzw. GAMP 5 vorzeichnen, getragen vom Risikomanagement nach ICH Q9(R1) - der Aufwand bleibt nicht größer, als es das Risiko verlangt. Auf die Release-Modelle der SAP-Cloud übersetzen wir ihn in unseren Projekten.
Die Mainstream-Wartung von SAP ECC und Solution Manager 7.2 endet 2027 - S/4HANA-Migration und ALM-Werkzeugwechsel fallen 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 eingeführt - mit sauberer Namensraum-Trennung zwischen Template und Lokalisierung - und Validierungswerkzeuge über die Standard-APIs an die SAP-Toolkette angebunden. Der methodische Rahmen ist derselbe, an dem wir mitgeschrieben haben: im 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 - nach SAPs eigenem Katalog nur durch den Kunden leistbar. Die Validierung gegen den Intended Use bleibt Betreiberpflicht.
Sie ist ein Baustein, kein Nachweis: eine separate Subscription, deren Leistungsumfang im nicht öffentlichen Addendum zum Kundenvertrag steht - laut SAP mit 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 eine risikobasierte Regressionsstrategie entscheiden, was nachzutesten ist; die Evidenz des Anbieters wird dabei einbezogen statt wiederholt. Der Maßstab ist derselbe, den die CSA-Guidance bzw. GAMP 5 anlegen: Der Aufwand bleibt nicht größer, als es das Risiko verlangt.
Zunächst nur die Technik: Eigenentwicklungen liegen auf der BTP statt im Kern - die Art der Änderung und die Nachweisfrage bleiben dieselben. Extensions und Integrationen werden gegen ihre Spezifikation verifiziert, Namensräume trennen Template und Lokalisierung. SAPs BTP-Whitepaper unterstützt laut eigener Zweckbestimmung das Vendor Assessment - ein Validierungsnachweis ist es nicht.
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 der Nachweis risikobasiert gelingt - den Betrieb eingeschlossen. Kostenfrei, etwa 30 Minuten.
Erstgespräch vereinbaren
