SAP-Innovation trifft auf GxP-Compliance

5. Mai 2026

Wie müssen sich Validierungsansätze vor dem Hintergrund aktueller SAP-Innovationen. verändern? Diese Herausforderungen waren Thema des Vortrag von Stefan Staub beim SAP Executive Exchange Forum for Life Sciences 2026 in Zürich.

Cloud Computing, vor allem der Trend hin zu Public Cloud / SaaS Lösungen, zwingt die regulierten Unternehmen sich mit kürzeren Release-Zyklen auseinanderzusetzen. Trendthema Nummer 1, die Künstliche Intelligenz (KI bzw. AI) wird mit innovativen Anwendungen die Prozesse in der Life Science Industrie in den kommenden Jahren stark verändern. SAP spielt hier an vorderster Front und die neuen technologischen Möglichkeiten werden den Unternehmen laufend in den SAP-Produkten zur Verfügung gestellt.
Während die regulatorische Erwartung (Sicherstellung von Produktqualität, Patientensicherheit und Datenintegrität) gleichbleibt, verändern sich die Anforderungen an die Validierungsansätze rasch. Der Vortrag zeigte, wie Unternehmen diese neuen Herausforderungen erfolgreich meistern können: Risikobasierte Lieferantenbewertung und -auswahl mit Unterstützung durch Audits und der GxP Cloud Control Matrix, kontinuierliche und automatisierte Validierung mit Hilfe einer End-to-End Digital Validation Platform.

Exciting times“ – aber mit neuen Compliance-Herausforderungen

Beim SAP Executive Exchange Forum for Life Sciences 2026 in Zürich hielt Stefan Staub, Partner & Principal Consultant der DHC Schweiz, den Vortrag „SAP Innovation meets GxP Compliance – An Overview“. Im Mittelpunkt stand eine Frage, die aktuell viele QA-, CSV- und IT-Teams beschäftigt:
Wie können Life-Sciences-Unternehmen SAP-Innovation (Private und Public Cloud SaaS Lösungen, KI-Anwendungen, …) nutzen – ohne GxP-Compliance zu riskieren?

Aktuell zeigt sich dabei folgendes Spannungsfeld:

Technologieanbieter treiben Innovation kontinuierlich voran, Unternehmen wollen und werden sie zeitnah nutzen – aber Gesetzgeber, Regulatoren benötigen Zeit, um Wissen zu generieren, dazugehörende Risiken zu identifizieren und entsprechende Gesetze und Leitlinien zu definieren.

QA/CSV-Teams stehen dadurch häufig zwischen „technologisch möglich“ und „regulatorisch eindeutig geregelt“.

• Die gute Nachricht: Die Ziele der Regulierung bleiben stabil: Sicherstellung von Produktqualität, Patientensicherheit und Datenintegrität.
• Die herausfordernde Nachricht: Die technologischen Rahmenbedingungen verändern sich schneller als je zuvor – und zwingen Unternehmen dazu, die Validierungsansätze der neuen Realität, trotz noch fehlender Gesetze und Leitlinien und der damit verbunden Unsicherheit, anzupassen.

Klassische, stark dokumentenzentrierte Validierungsansätze aus „Waterfallmodell-Zeiten“ geraten zunehmend an Grenzen, wenn sich die neuen IT-Systeme wie ein „Organismus“ permanent verändern.

Von „linear & dokumentenzentriert“ zu „continuous & risikozentriert & automatisiert“

Viele Validierungsansätze stammen aus einer Zeit, in der Software vergleichsweise statisch war. Entsprechend waren Ansätze zur Computersystemvalidierung (CSV) stark dokumentationsgetrieben, teils sogar papierbasiert, linear entlang eines klassischen Wasserfallmodells. Das gilt in Teilen bis heute – wird aber zunehmend als zu langsam, bürokratisch und teuer erlebt.

Das zentrale Bild: IT-Systeme verhalten sich heute eher wie ein „Organismus“, der sich kontinuierlich verändert: Cloud-Services, vor allem SaaS-Anwendungen und die damit verbundenen schnellen Release-Zyklen beschleunigen die Änderungsdynamik. Mit den aufkommenden KI-Anwendungen werden sich die Anforderungen weiter erhöhen.

Folglich muss sich die Validierung in Richtung einer kontinuierlichen Validierung (Continuous Validation) entwickeln. Rein manuell lässt sich das Tempo, vor allem beim Change Impact Assessment und dem notwendigen Testen, nicht halten; Testautomatisierung wird zur Notwendigkeit (und perspektivisch können auch KI-Ansätze Validierungsaktivitäten unterstützen).

In einer SAP-Landschaft, die von Cloud-Services, häufigen Releases und neuen KI-Anwendungen geprägt ist, müssen Validierungsansätze und Validierungswerkzeuge künftig daher folgende Eigenschaften erfüllen:

• Schnell & agil: Validierung muss mit neuen und schnellen Software-Entwicklungsmethoden und den damit verbundenen Release-Zyklen „mitlaufen“ – nicht nachgelagert bremsend und Innovations- und Effizienzpotenziale verhindernd.
• Automatisiert: Wiederkehrende Prüf- und Dokumentationsschritte
  müssen industrialisiert werden (z. B. Change-Impact-Assessment auf Basis Release Notes, Regressionstests, Traceability,).
• Supplier-supported: In Cloud Computing, z.B. SaaS sind die Lieferanten aufgrund ihrer Verantwortlichkeiten und Kontrolle der Infrastruktur-, Plattform- und Softwareebene aktiv in die Qualifizierungs- und Validierungsaktivitäten einzubinden.
• Kontinuierlich validierend: „Stay validated“ wird zum Betriebsmodell –
  mit klarer Governance, Change Impact Analysis und laufender
  Überwachung statt punktueller Validierung mit periodischer Überprüfung.
• Vollständig digitalisiert: CSV-Aktivitäten werden künftig vollständig elektronisch in integrierten, workflowgesteuerten CSV-Tools (Tool-Chain) als strukturierte Daten statt in isolierten Dokumenten gesteuert. Dadurch wird die audit-sichere Dokumentation automatisiert erzeugt, Compliance und Transparenz steigen, während Aufwand und Durchlaufzeiten für Validierung und Freigabe GxP-relevanter Systeme sinken.
• KI-unterstützt: KI kann unterstützen, Informationen zu strukturieren, Änderungen vorzubereiten oder Reviews zu beschleunigen – ohne die regulatorische Verantwortung zu „delegieren“.

Cloud: „Shared responsibility“ – aber einseitige Accountability / Rechenschaftspflicht

Ein Kernpunkt im Cloud-Kontext lässt sich in einem Satz zusammenfassen:

Viele Aufgaben liegen nicht mehr unter direkter Kontrolle des regulierten Unternehmens – die Rechenschaftspflicht bleibt aber bei ihm.

Dieses Spannungsfeld von geteilter Verantwortung bei gleichzeitig einseitiger Rechenschaftspflicht („shared responsibility but one-sided accountability“) erklärt, warum Lieferantenauswahl und Lieferantenqualifizierung im Cloud-Kontext nicht „Nice to have“, sondern ein Muss sind: Niemand möchte erst nach Vertragsabschluss feststellen, dass ein Anbieter GxP-Fähigkeiten oder Qualifizierungsunterstützung nicht liefern kann – und dann in Audits/Inspektionen ohne Nachweise dastehen. Daher gibt es regulatorische Anforderungen, die verlangen, dass man diesen Auswahl- und Assessment-Prozess durchführt, bevor man die Zusammenarbeit startet.

Die folgende Abbildung konkretisiert das entlang der Cloud-Service-Modelle (IaaS/PaaS/SaaS): Provider verantworten u. a. sicheren Betrieb, Change Management und Datenintegrität die regulierte Organisation muss nachweisen, dass der Provider die Anforderungen erfüllt (Qualification) und muss Anwendungen „fit for intended use“ validieren.

Zum Assessment eignen sich folgende zwei Methoden mit ihren
Varianten:

Risikobasierte Cloud Service Provider Bewertung

Es gibt verschiedene Wege um Cloud Service Provider (CSP) zu bewerten. Je nach Kritikalität der Applikation/des Lieferanten, sind unterschiedliche durchzuführen.

GxP Cloud Control Matrix als strukturierter Nachweis

Basierend auf dem internationalen Standard der Cloud Controls Matrix der Cloud Security Alliance hat die DHC die GxP Cloud Control Matrix entwickelt, welche für Life Sciences Unternehmen  um GxP-Anforderungen  erweitert wurde („GxP-enhanced cloud control matrix“). Die GxP CCM eignet sich ideal zur Bewertung von CSPs und als dokumentierter Nachweis, dass das geforderte Assessment durchgeführt wurde.

Use Case: Vertrauensaufbau zwischen Cloud Service Provider (CSP) und reguliertem Unternehmen am Beispiel SAP Digital Manufacturing (SAP DM)

Als Voraussetzung für eine erfolgreiche langfristige Zusammenarbeit zwischen reguliertem Unternehmen und Cloud Service Provider (CSP) müssen beide Seiten ihre Hausaufgaben erledigen:

Reguliertes Unternehmen:

• CSP Auswahl und Bewertung (siehe vorgängiger Abschnitt)
• Vertragliche Regelung der Zusammenarbeit, dazu gehören:
  • Master Service Agreement (MSA) und Service Level Agreement (SLA)s
  • Quality Assurance Agreement (QAA)
  • Data Processing Agreement (DPA)
  • …

Hierbei sollte das Unternehmen darauf achten, dass es die Möglichkeit hat, beim CSP Audits durchzuführen.

• Überwachung der Compliance und der Service Qualität des CSP über die Dauer der Zusammenarbeit.

SAP als Cloud Service Provider (CSP) für die SAP DM

SAP muss sicherstellen, dass regulatorische und funktionale Anforderungen in der Life Science Industry sichergestellt werden. Der Kunde, das regulierte Unternehmen, braucht die Unterstützung bei der Qualifizierung und Validierung durch die SAP.  Folgendes bietet die SAP im Falle der DM mit dem Quality Requirement Schedule für ihre GxP relevanten Kunden:

• Qualitätssicherungsmassnahmen im Bereich Softwareentwicklung und -operations inkl.
  • Qualitätsmanagementsystem (QMS)
  • SOP für den SDLC (Softwareentwicklungszyklus)
  • Zertifizierungen und Bescheinigungen
  • GxP-Whitepapers (SAP DM & SAP BTP)
  • Rahmenwerk für interne Audits und Kontrollen
• Qualifizierte SaaS-Lösung inkl.
  • SAP-DM-Produktzertifizierung
  • SAP-BTP-Plattformzertifizierung
  • Zertifizierung für Continuous Platform Services
  • Matrix zur Rückverfolgbarkeit regulatorischer Anforderungen
  • Audit vor Ort auf Anfrage
• Konzept für den Betrieb inkl.
  • Standardarbeitsanweisungen (SOP) für IT-Betrieb und Servicemanagement
  • Service Level Agreements (SLAs)
  • Release-Management

Use Case: SaaS-Validierung am Beispiel SAP Digital Manufacturing (SAP DM)

Erkenntnisse und Lehren aus der SAP DM Validierung:

1. SAP DM Systemarchitektur, -grenze und -funktionalität

SAP DM ist eine SaaS-Lösung auf der SAP Business Technology Platform (BTP als PaaS), welche auf einer Hyperscaler IaaS läuft. Für regulierte Organisationen bedeutet das: keine direkte Kontrolle über das System (Stichwort: geteilte Verantwortlichkeiten), aber vollumfängliche Rechenschaftspflicht (siehe hierzu die vorgängigen Kapitel).

1. Ein (noch) konventioneller Ansatz kann funktionieren – aber…

Eine klassische, sich am GAMP5 orientierende und Dokumenten-basierte Validierung auf einem DMS kann durchaus gut funktionieren. Der eigentliche Engpass bei einem solchen Vorgehen zeigt sich beim Change Management, insbesondere beim Change Impact Assessment sowie beim Regressionstesten und da konkret im Binden der Business-Ressourcen.

Quartalsweise werden von SAP neue Releases eingespielt, welche in einem 2-wöchigen Testfenster getestet werden müssen. Eine Woche bevor das Testfenster geöffnet wird, werden die Release Notes  (What’s New) publiziert. Es ergeben sich zwei Herausforderungen:

• Change Impact Assessment
  Eine der großen Herausforderungen im SaaS Umfeld ist die Interpretation der Release Notes und damit auch das Change Impact Assessment. Typischerweise werden die SAP DM What’s New eine Woche vor dem Testfenster publiziert. Den regulierten Unternehmen bleibt eine Woche die Release Notes auszuwerten und den Impact auf die genutzten Funktionalitäten und Prozesse zu bewerten.
• Testen
  Test- bzw. Regressionstestplanung, Ressourcenbereitstellung und das Ausführen der Tests, ist für viele Organisationen ein grosser Aufwand. Größere Organisationen können hier teilweise auf Test Factories ausweichen, welche das Testen fürs Business übernehmen. Kleinere Organisation haben diese Möglichkeiten nicht, und überstrapazieren das Business mit den Testaktivitäten. Auf Dauer ist hier das manuelle Testen keine Lösung.

Das praktische Fazit: Mit einem konventionellen Ansatz kann man validiert bleiben – aber man kann nicht alle paar Wochen dauerhaft die Fachbereiche mit manuellen Tests blockieren. Langfristig führt kein Weg vorbei an einer Testautomatisierung sowie einer Digitalisierung/Automatisierung von Change Impact Analyse, Dokumentationspflege und Testing.

Damit wird Tool-Unterstützung in der Validierung vom „nice-to-have“ zum Muss. Wenn Release Notes in kurzen Abständen bewertet, Changes sauber zugeordnet, Dokumente gepflegt, Tests geplant/ausgeführt und Nachweise auditfähig abgelegt werden müssen, lässt sich das weder dauerhaft manuell noch rein dokumentenzentriert skalieren.
Entscheidend ist eine durchgängige Kette aus Change-Impact-Bewertung, Dokumentenpflege, (automatisiertem) Testen und automatischer Traceability – sonst wird die Continuous Validation zur Dauerbelastung für IT, Fachbereich und QA/CSV-Organisation.

SAP’s Initiative zur End-2-End Digital Validation Platform

Viele Organisationen haben in den letzten Jahren den SAP Solution Manager (SolDoc, ChaRM, ITSM, Testmanagement, ggf. Focused Build mit Test Step Designer usw.) oder auch andere Werkzeuge als zentrales Valdierungswerkzeug genutzt. Aber: Der SAP Solution Manager läuft Richtung Supportende, man muss sich mit „What’s next“ beschäftigen.

SAP positioniert Cloud ALM als Solution Manager Nachfolger, aber es kann und will nicht die eierlegende Wollmilchsau der Validierungswerkzeuge werden.

Daher setzt SAP zusammen mit mehreren SAP-Partnern in einer aktuellen Initiative zur End-2-End Digital Validation Platform auf eine integrierte Toolchain bestehend aus:

• SAP LeanIX: fürs Enterprise Architecture Management (EAM)
• Signavio: fürs Business Process Managmenet (BPM). Aus Validierungssicht ist Signavio ein guter Einstieg für die Prozessdefinition und -modellierung
• SAP Cloud ALM: als Zentrum für Application Lifecycle Management (ALM) inkl. Transport Management, Test Management, Requirements Management usw.
• Tricentis Tosca: für automatisiertes Testen
• p36: für die Continuous Service Qualification, besonders für BTP Services
• DHC Smart Validation Accelerator (SVA): für das Management von Validierungsobjekten, Changes- und Dokumenten. Als wichtiger ergänzender Baustein für die Validierungsdokumentation, Versionierung, elektronische Workflows, Sign-offs und Traceability.
  Der Smart Validation Accelerator ermöglicht elektronisch und integriert die Erstellung und Ablage von z.B.:
  • Validierungsplänen
  • Validierungsobjekten und URS, FS, Risikoanalysen usw.
  • technische Dokumentationen
  • Testreports, Sign-offs, Validierungsreports

und steuert die integrierte Zusammenarbeit innerhalb der Toolchain.

Aktuell arbeitet DHC an der Fertigstellung des Change Impact Analyzers, um „What’s New“ / Release Notes zu interpretieren und risikobasierte Change Impact Assessments zu unterstützen, um zu entscheiden, welche Validierungsobjekte/Dokumente betroffen sind und was zu regressionstesten ist. Damit möchte man dem engen Zeitfenster im SaaS-Release-Management begegnen.

Fazit

Innovation ist möglich und muss möglich sein – Voraussetzung und auch Enabler dazu muss eine Validierungsvorgehensweise mit entsprechenden Tools bzw. einer Toolchain sein, die integriert, vollständig digitalisiert, und automatisiert ist.

Sie möchten mehr erfahren – jetzt unverbindliches 1:1-Expertengespräch vereinbaren