SAP validieren: Welche Module und Geschäftsprozesse sind GxP-relevant?

GxP-Validierung von SAP-internen Datenprüfungen unterscheiden

In SAP-Dokumentationen kann Validierung auch eine Eingabeprüfung, Kontierungskontrolle oder fachliche Plausibilitätsregel bezeichnen. Dieser Artikel behandelt die Eignung eines computergestützten Systems für seinen vorgesehenen regulierten Einsatz. Eine korrekt konfigurierte Feldprüfung kann dazu beitragen, ist aber noch kein vollständiger Nachweis für einen Geschäftsprozess.

Die regulatorischen Beispiele gelten für Humanarzneimittel-GMP. Annex 11 ist hier die GMP-Leitlinie für computergestützte Systeme; die Europäische Kommission führt weiterhin die Revision vom Januar 2011. Medizinprodukte, Veterinärarzneimittel und andere Tätigkeiten benötigen ihre eigene Anforderungsgrundlage. FDA Part 11 wird zusätzlich anhand der einschlägigen Aufzeichnungspflichten und elektronischen Nutzung beurteilt.

Notieren Sie vor der technischen Diskussion den konkreten Anlass: Einführung, geänderter Prozess, Migration oder Bewertung eines bestehenden Systems. Derselbe SAP-Bestand kann je nach Änderung einen unterschiedlichen Nachweisbedarf haben. Ein Inventar beschreibt, was vorhanden ist; die Scopeentscheidung erklärt, was davon warum untersucht wird.

Quellen: [1] [2] [3]

Mit Entscheidungen und Fehlerfolgen beginnen

Wählen Sie einen Vorgang mit erkennbarem Anfang und Ende, etwa die Annahme eines Rohstoffs bis zur zulässigen Verwendung. Wer entscheidet anhand welcher Information, dass weitergearbeitet werden darf? Was würde eine falsche, fehlende oder verspätete Information bewirken? Beschreiben Sie auch den Fall, dass ein berechtigter Mitarbeiter den üblichen Weg verlassen muss.

Diese Fragen bilden eine eigene Arbeitshilfe zur risikobasierten Abgrenzung. Die EMA empfiehlt für komplexe Systeme eine vertiefte Betrachtung kritischer Funktionen. Eine Prozessbeschreibung darf deshalb über die organisatorische Zuständigkeit eines einzelnen Moduls hinausreichen. Eine Spezifikation kann in einer Anwendung entstehen, die Bewertung im Labor erfolgen und die Materialbewegung wiederum in SAP ausgelöst werden.

Nutzen Sie kurze, prüfbare Aussagen: Ein ungeklärter Materialstatus darf die definierte Produktionsentnahme nicht erlauben. Der freigegebene Ergebnisstand muss dem richtigen Material zugeordnet sein. Solche Aussagen helfen QA und IT, fachliche Anforderungen und technische Umsetzung gemeinsam zu besprechen. Sie sind deutlich konkreter als die Vorgabe, SAP müsse insgesamt GxP-konform sein.

Quellen: [1] [5]

Module als Orientierung nutzen, Ausschlüsse begründen

Modulnamen helfen beim Auffinden von Funktionen und Verantwortlichen. Sie sind aber keine verlässliche Grenze zwischen relevant und irrelevant. Auch eine scheinbar rein kaufmännische Sperre kann mit einer logistischen Freigabe zusammenwirken. Klären Sie, ob diese Verbindung die qualitätsrelevante Entscheidung beeinflusst oder lediglich einen getrennten Geschäftsablauf betrifft.

Die folgende Matrix ist eine eigene Diskussionshilfe und keine Behördenklassifikation. Sie zeigt mögliche Prüffragen, keine pauschale Einstufung ganzer Module. Ihre Entscheidung sollte den tatsächlich genutzten Ablauf und die tragenden Annahmen nennen. Bleibt eine Annahme ungeklärt, gehört sie als offene Aufgabe in die Planung statt stillschweigend in den Ausschluss.

Ein begründeter Ausschluss könnte lauten: Die betrachtete Reisekostenabrechnung erzeugt und verändert keine GMP-relevanten Aufzeichnungen und ist nicht Teil der beschriebenen Qualitätsentscheidung. Eine gemeinsame Benutzerverwaltung bleibt dennoch als technische Abhängigkeit separat zu betrachten. Aus dieser gemeinsamen Plattform folgt nicht, dass jede Reisekostenfunktion fachlich gleich tief geprüft werden muss.

Quellen: [1] [5]

Den Datenweg und seine Bedeutung sichtbar machen

Verfolgen Sie für die gewählte Entscheidung mindestens einen Datensatz vom Entstehen bis zur Aufbewahrung. Benennen Sie das führende System, verwendete Identifikatoren, Einheiten, Versionen und Status. Unterscheiden Sie einen angezeigten Wert von der zugrunde liegenden Aufzeichnung und einer daraus berechneten oder zusammengefassten Darstellung.

Ein produktspezifisches Beispiel zeigt, weshalb das nötig ist: In ByDesign können identifizierte Bestandsnummern je nach Einstellung nur innerhalb eines Produkts eindeutig sein. Eine reine Chargennummer ohne Produktbezug wäre dann kein hinreichender Schlüssel. Dieser Befund gilt für die ausgewertete ByDesign-Dokumentation und wird nicht auf alle SAP-Produkte übertragen.

Prüfen Sie auch scheinbar harmlose Übergänge: Ein Export entfernt einen Status, ein Bericht fasst Datensätze zusammen oder eine Schnittstelle wandelt die Einheit um. Für den eigenen Scope zählt, ob dabei die Bedeutung der entscheidungsrelevanten Information erhalten bleibt. Die EMA behandelt bei datenbankgestützten Systemen ausdrücklich Bedeutung und logischen Zusammenhang der Daten. Eine richtige Gesamtsumme allein beantwortet diese Frage nicht.

Quellen: [7] [5] [4]

Abhängigkeiten bis zur fachlichen Wirkung verfolgen

Zeichnen Sie eine einfache Systemgrenze mit Ein- und Ausgängen: SAP-Anwendung, Labor, Lager, Dokumentenquelle, Identitätsdienst und relevante Auswertungen. Kennzeichnen Sie, wo Daten entstehen, geprüft, übernommen oder verändert werden. Ein externer Dienst bleibt nicht außerhalb der Betrachtung, nur weil ein anderer Vertrag oder ein anderes Team ihn betreut.

Die technische Schnittstelle muss zum konkreten Produktstand passen. SAP beschreibt beispielsweise für S/4HANA Cloud Public Edition 2608 einen Ablauf zur externen Ergebniserfassung über die Inspection-Lot-API. Das Beispiel umfasst keine Ergebniserfassung für Prüfpunkte. Schon diese Grenze zeigt, warum eine allgemein vorhandene Schnittstelle nicht jede fachliche Variante abdeckt.

Als eigene Prüffragen eignen sich doppelte Nachrichten, falsche Zuordnung, verspätete Rückmeldung und Wiederanlauf nach Unterbrechung. Bestimmen Sie, welches System einen Widerspruch erkennt und wer ihn bearbeitet. Ein technisch erfolgreicher Datentransport kann fachlich trotzdem falsch sein. Der Nachweis endet daher an der richtigen Wirkung im Zielprozess, nicht bereits beim erfolgreichen Sendeprotokoll.

Quellen: [6] [1]

Hersteller-, Partner- und Anwendernachweise zuordnen

Trennen Sie drei Fragen: Was ist über die Standardfunktion belegt? Wie wurde Ihre konkrete Lösung eingerichtet oder erweitert? Und funktioniert sie für Ihren vorgesehenen Ablauf? Passende Unterlagen können sich ergänzen. Sie müssen weder sämtliche Herstellertests wiederholen noch jede Partnerdokumentation ungeprüft als ausreichend behandeln.

Legen Sie zu einer übernommenen Evidenz ihren Stand, den belegten Sachverhalt und verbleibende Einschränkungen fest. Ein Herstellerbeleg kann eine bestimmte Fehlerbehandlung zeigen; die Zuordnung Ihrer eigenen Materialkennzeichen bleibt möglicherweise eine Anwenderprüfung. Der tatsächliche Lieferumfang entscheidet, nicht eine pauschale Annahme darüber, was Anbieter grundsätzlich testen.

Benennen Sie Verantwortliche für Anforderungen, Konfiguration, Datenschnittstellen und fachliche Bewertung. Der Prozessverantwortliche erklärt die richtige Entscheidung, IT den Datenweg und der Umsetzungspartner die technische Realisierung. QA beurteilt die Nachweisführung im vereinbarten Qualitätsrahmen. Für den Abschluss müssen diese Sichtweisen zusammenpassen; ein einziges unterschriebenes Deckblatt ersetzt die offenen Sachfragen nicht.

Quellen: [1]

Aus dem Scope eine begründete Prüftiefe ableiten

GxP-Relevanz und Testtiefe sind zwei verschiedene Entscheidungen. Zunächst bestimmen Sie, welche Nutzung betroffen ist. Danach bewerten Sie, wie schwer ein Fehler wiegen könnte, wie er erkannt wird und welche Kontrollen vorhanden sind. Daraus ergeben sich Schwerpunkte für positive Abläufe, Grenzfälle und unzulässige Aktionen.

Eine pauschale GAMP-Kategorie für die gesamte SAP-Landschaft beantwortet diese Fragen nicht. Standardfunktionen, Einstellungen, eigene Erweiterungen und Schnittstellen können unterschiedliche Nachweise benötigen. Beschreiben Sie diese Unterschiede konkret, ohne aus dem Produktnamen eine starre Einstufung oder eine feste Menge an Testskripten abzuleiten.

Beziehen Sie unterstützende Infrastruktur angemessen ein. Annex 11 unterscheidet die Validierung der Anwendung von der Qualifizierung der IT-Infrastruktur. Gemeinsame Dienste wie Zugriff und Datensicherung werden dadurch nicht bedeutungslos, müssen aber nicht als separate fachliche ERP-Prozesse beschrieben werden. Bewerten Sie ihre Leistung für die kritischen Abläufe und machen Sie bestehende passende Nachweise nutzbar.

Quellen: [1] [5]

Konstruiertes Beispiel: Freigabeinformation vom Labor bis zum Lager

Das folgende Beispiel ist ausdrücklich konstruiert. Es beschreibt weder eine Kundeninstallation noch ausgeführte Tests oder eine zugesicherte SAP-Standardfunktion. Ein Labor bewertet eine Rohstoffcharge. Ein ERP-Prozess übernimmt die Entscheidung, und ein Lagerprozess soll nur geeignetes Material für einen definierten Herstellauftrag bereitstellen.

Für diesen Ablauf gehört die korrekte Ergebniszuordnung zum Scope, ebenso die Übertragung und die tatsächliche Wirkung auf die Entnahme. Eine unabhängig geführte Kostenstellenabrechnung wird für dieses Beispiel fachlich ausgeschlossen. Ihre gemeinsame Infrastruktur und mögliche Datenverbindungen werden trotzdem erfasst. Die Grenzen sind damit an begründete Funktionen gebunden, nicht an die organisatorischen Teams.

Die zweite Arbeitshilfe übersetzt Anforderungen in Nachweise. Im Projekt werden daraus konkrete Testdaten und Akzeptanzkriterien. Wenn etwa die Zielanwendung trotz veralteter Freigabeinformation weiterarbeiten kann, ist das zunächst ein Befund. Entscheiden Sie anhand des vorgesehenen Prozesses, welche technische oder organisatorische Kontrolle erforderlich ist; ändern Sie nicht nachträglich das Soll, nur damit ein Test als bestanden gilt.

Quellen: [1] [5]

Scope bei Bestandsanlagen und Änderungen fortführen

Bei bestehenden Landschaften beginnen Sie mit dem tatsächlichen Einsatz und den vorhandenen Unterlagen. Die EMA beschreibt für Altsysteme Anforderungen und Lückenanalyse als Grundlage der Eignungsprüfung. Fehlende Dokumentation bedeutet weder automatisch, dass alles unbrauchbar ist, noch dass langjährige Nutzung den Nachweis ersetzt.

Halten Sie nach einer Änderung fest, welche Annahmen des bisherigen Scope noch gelten. Eine neue Schnittstelle, ein geänderter Bericht oder eine zusätzliche Rolle kann relevant sein, obwohl kein neues SAP-Modul hinzukommt. Bewerten Sie auch neue Verwendung vorhandener Daten: Ein bisher rein betrieblicher Bericht kann künftig Teil einer Qualitätsentscheidung werden.

Migration und Aufbewahrung benötigen eigene Betrachtung, wenn Datenformat, Struktur oder Zugriff wechseln. Das gilt ebenso beim Systemausstieg. Prüfen Sie, welche historischen Beziehungen erhalten bleiben müssen und welche kontrollierte Zugriffsmöglichkeit vorgesehen ist. Der konkrete Umfang folgt der Änderung und den relevanten Aufzeichnungen; aus einem Releasewechsel ergibt sich nicht pauschal ein Neubeginn der gesamten Validierung.

Quellen: [5] [1] [4]

Den Scope mit den richtigen Beteiligten arbeitsfähig abschließen

Für ein kleines Team ist ein gemeinsamer Durchgang durch einen repräsentativen Vorgang oft der beste Einstieg. Bringen Sie Prozessverantwortliche, QA, IT und die betroffenen Labor-, Produktions- oder Lagerrollen zusammen. Nutzen Sie einen echten Prozessablauf als Gesprächsgrundlage, für die Tests anschließend kontrollierte geeignete Daten.

Der erste Arbeitsstand sollte eine verständliche Grenze, wesentliche Risiken, vorhandene Belege und offene Entscheidungen enthalten. Planen Sie Aufwand erst auf dieser Grundlage. Viele Varianten, individuelle Erweiterungen, schwache Stammdaten oder unklare Verantwortlichkeiten erhöhen den Klärungsbedarf. Eine belastbare Schätzung nennt diese Treiber und ihre Annahmen; sie verspricht keine feste Dauer allein aus der Zahl der Module.

• Vorgesehener Einsatz und regulatorische Grundlage sind benannt.
• Prozessanfang, Ende, Entscheidungen und mögliche Fehlerfolgen sind beschrieben.
• Relevante Daten, führende Systeme und fachliche Identifikatoren sind erfasst.
• Schnittstellen, externe Dienste und unterstützende Infrastruktur sind zugeordnet.
• Einbezogene Funktionen und Ausschlüsse haben eine verständliche Begründung.
• Hersteller- und Partnernachweise sind nach Version und Abdeckung bewertet.
• Offene Fragen besitzen Verantwortliche und eine geplante Entscheidung.
• Anforderungen, Prüfschwerpunkte und Akzeptanzkriterien passen zusammen.
• Der vereinbarte Scope wird bei Änderungen und neuer Nutzung erneut bewertet.

Quellen: [1]