QFINITY · Dienstleistungsbereiche · ERP / SAP S/4HANA
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.
Verantwortungsteilung
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.
Betrieb lässt sich mieten - Nachweisverantwortung nicht.
Ablauf
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 dokumentieren zugleich, wofür das System im Prozess gebraucht wird. Der Intended Use entsteht dort, wo entschieden wird.
- 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.
Aufwand folgt dem Risiko
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. Wie das im Konzernmaßstab trägt, zeigt unsere S/4HANA-Template-Fallstudie.
Betrieb
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.
Doppelte Deadline 2027
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.
Unser Service
SAP-Compliance, durchgängig begleitet.
Auditierung der aktuellen Vorgehensweise zu Validierung und Betrieb des ERP-Systems
Fit-to-Standard-Begleitung mit Intended Use, Anforderungen und Risikobewertung
Prozessorientierter Aufbau der Validierungsdokumentation inkl. Eigentümerkonzept (lokal/global)
Risikobasierte Teststrategie - Berechtigungstests, Regressionsstrategie für die Release-Takte der SAP-Cloud, Testautomatisierung
Sicherstellung der Datenintegrität inkl. 21 CFR Part 11 und EU GMP Annex 11 - elektronische Aufzeichnungen, Audit Trail, Zugriffs- und Stammdatenmanagement
Lieferanten-Oversight: Bewertung der SAP-Nachweise (SOC-Reports, Whitepaper) im QMS
Anbindung der Qualifizierungs- und Validierungswerkzeuge an SAP Cloud ALM über die Standard-APIs
Periodische Evaluierung und Projektmanagement für Validierungsprojekte
Aus der Projektpraxis
Zwischen Methodik und Vertrag liegt die eigentliche Arbeit.
GAMP 5 (Second Edition) deckt Cloud-Infrastruktur, externe Provider und Shared Responsibilities ab - RISE nennt der Leitfaden nicht. 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.
SAP S/4HANA
RISE / Private Edition
BTP / Clean Core
SAP Cloud ALM
GAMP 5 Second Edition - Kernteam
FAQ
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 der CSA Guide bzw. GAMP 5 anlegt: 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
