Validierung
GAMP 5 wird in Projekten oft wie eine Checkliste behandelt. Das verfehlt den Kern. ISPE beschreibt GAMP ausdrücklich als pragmatische Guidance, nicht als Standard, und betont einen risikobasierten Lebenszyklusansatz sowie „fit for intended use“.
Dynamics 365 Validierung bei AENUMA
Nicht der Produktname Dynamics 365 entscheidet über den Validierungsumfang. Entscheidend ist, wofür eine konkrete Funktion eingesetzt wird. Ein rein finanzwirtschaftlicher Prozess kann außerhalb des qualitätsrelevanten Scopes liegen, während Chargenrückverfolgung, Sperrbestände, Produktionsfreigaben oder Reklamationsprozesse direkt relevant sein können.
ISO/TR 80002-2 adressiert Software im Qualitätsmanagement, in Produktion und Service sowie bei Überwachung und Messung. Genau deshalb beginnt die Validierung mit Prozess und Risiko.
Microsoft testet und betreibt die Plattform. Das ersetzt aber nicht den Nachweis des Herstellers, dass die eigene Konfiguration für den vorgesehenen Zweck geeignet ist. Gleichzeitig muss nicht jede Standardfunktion mit derselben Tiefe erneut bewiesen werden.
Der sinnvolle Ansatz ist: Lieferanten- und Produktnachweise nutzen, Konfiguration und Erweiterungen verstehen, kritische Funktionen identifizieren und dort eigene Verifikation vertiefen.
Eine belastbare Kette verbindet Anforderung, Risiko, Konfiguration und Test. Für kritische Anforderungen sollte nachvollziehbar sein, warum sie existieren, wie sie technisch umgesetzt wurden und welcher Nachweis zeigt, dass sie funktionieren.
| Element | Frage |
|---|---|
| Intended Use | Wofür wird die Funktion eingesetzt? |
| Anforderung | Was muss das System leisten? |
| Risiko | Was passiert bei Fehler? |
| Konfiguration | Wie ist die Anforderung umgesetzt? |
| Test | Welcher Nachweis reicht aus? |
Ein Standardbericht mit geringer regulatorischer Bedeutung braucht nicht dieselbe Testtiefe wie eine Funktion, die den Qualitätsstatus einer Charge steuert. GAMP 5 unterstützt genau diese Differenzierung. Kritisches Denken ersetzt dabei nicht Dokumentation, sondern sorgt dafür, dass Dokumentation und Testaufwand dort entstehen, wo sie einen echten Nachweis liefern.
Bei Dynamics 365 besteht eine Lösung meist aus Microsoft-Standard, Konfiguration, Power-Platform-Komponenten, Schnittstellen und eventuell kundenspezifischen Erweiterungen. Je weiter eine Funktion vom Standard entfernt ist und je kritischer ihr Einsatz, desto genauer müssen Design, Änderung und Test nachvollziehbar sein.
Die Validierung endet nicht mit dem Go-live. Service Updates, neue Features, Konfigurationsänderungen und Erweiterungen verändern den Systemzustand. Deshalb gehören Change Control, Impact Assessment, Regressionstests und dokumentierte Freigaben zum Betriebsmodell.
Weiter: Wann braucht ein Dynamics-365-Update Revalidierung?
Nächster Schritt: Validation Health Check oder Dynamics 365 validieren.
Alle Fachbeiträge zu regulierten Systemen
Ein risikobasierter Ansatz bedeutet nicht, Microsofts Tests einfach zu übernehmen. Er bedeutet, vorhandene Lieferanten- und Produktnachweise bewusst in die eigene Bewertung einzubeziehen. Für Standardsoftware ist entscheidend, welche Verantwortung beim Anbieter liegt und welche Verantwortung der Hersteller für Konfiguration, Daten, Rollen, Schnittstellen und den konkreten Intended Use trägt.
Je stärker eine Funktion kundenspezifisch verändert wird, desto weniger kann der Nachweis allein aus Standarddokumentation abgeleitet werden. Deshalb gehört die Unterscheidung zwischen Standard, Konfiguration, Erweiterung und Integration bereits in die Validierungsstrategie.
Die Testtiefe sollte aus dem möglichen Schaden eines Fehlers und der Fähigkeit abgeleitet werden, diesen Fehler vor seiner Auswirkung zu erkennen. Eine Funktion, die lediglich einen internen Bericht formatiert, hat ein anderes Risikoprofil als eine Funktion, die einen gesperrten Bestand freigibt oder eine qualitätsrelevante Entscheidung steuert.
Ein praktikables Schema ist: Prozesskritikalität bestimmen, Fehlermodus beschreiben, vorhandene Kontrollen bewerten und daraus Testtiefe sowie Nachweisform festlegen.
Viele Validierungsprojekte konzentrieren sich auf fachliche Funktionen und unterschätzen Security. Wenn nur bestimmte Rollen Qualitätsstatus ändern, Stammdaten freigeben oder kritische Transaktionen buchen dürfen, ist das Berechtigungskonzept Teil der kontrollierten Lösung.
Zu testen sind deshalb nicht nur positive Prozesse, sondern auch unerlaubte Aktionen: Kann ein Benutzer ohne passende Rolle eine gesperrte Charge freigeben? Kann eine kritische Konfiguration ohne Genehmigung geändert werden?
Ein Prozess kann in Dynamics 365 korrekt funktionieren und trotzdem fehlschlagen, wenn Daten aus QMS, LIMS, MES, EUDAMED-nahen Anwendungen oder anderen Systemen falsch übertragen werden. Für kritische Schnittstellen sollten Datenmapping, Fehlerbehandlung, Wiederanlauf und Monitoring nachvollziehbar sein.
Besonders wichtig ist die Frage, welches System für einen Wert führend ist. Eine Schnittstelle darf nicht dazu führen, dass zwei Anwendungen denselben regulatorisch relevanten Wert unabhängig pflegen.
Bei einer Einführung oder Migration müssen nicht nur Datensätze übertragen, sondern ihre Bedeutung erhalten werden. Für aktive Chargen, Seriennummern, qualitätsrelevante Historie und kritische Stammdaten braucht es definierte Abgleich- und Akzeptanzkriterien.
Eine erfolgreiche technische Migration ist kein ausreichender Nachweis, wenn nicht gezeigt werden kann, dass relevante Daten vollständig und korrekt im Zielsystem angekommen sind.
Dynamics 365 verändert sich nach dem Go-live weiter. Deshalb muss das Validierungskonzept einen wiederholbaren Change-Prozess enthalten. Release Notes, eigene Konfigurationsänderungen, Erweiterungen und Schnittstellenänderungen werden gegen den validierten Scope bewertet. Daraus folgt der notwendige Regressionstest.
Weiter: Wann braucht ein Dynamics-365-Update Revalidierung?
Ein Hersteller nutzt Dynamics 365 für chargengeführte Materialien. Der Wareneingang erzeugt eine Qualitätsprüfung und nicht freigegebene Ware wird gesperrt. In diesem Szenario sind unter anderem der Trigger der Prüfung, die Ergebnislogik, die Sperrwirkung, die Rollen für Freigabe und die Rückverfolgbarkeit der Charge kritisch. Ein allgemeiner Finanzbericht auf derselben Plattform kann dagegen außerhalb dieses Scopes liegen.
Ist GAMP 5 eine gesetzliche Vorschrift?
Nein. GAMP 5 ist eine etablierte Good-Practice-Guidance. Die regulatorische Pflicht ergibt sich aus dem jeweiligen Einsatz und den anwendbaren Anforderungen, nicht aus dem Namen der Guidance.
Muss jede Dynamics-365-Funktion getestet werden?
Nein. Der Umfang sollte dem Intended Use und Risiko folgen. Nicht verwendete oder nicht relevante Funktionen benötigen nicht dieselbe Testtiefe wie kritische Prozessfunktionen.
Kann Standardsoftware validiert werden?
Der Hersteller validiert den eigenen Einsatz der Software für den vorgesehenen Zweck. Standardsoftware liefert eine Basis, ersetzt aber nicht die Bewertung von Konfiguration, Prozessen, Daten und Verantwortlichkeiten.
Was ist wichtiger: viele Testfälle oder gute Traceability?
Beides hängt zusammen. Entscheidend ist, dass kritische Anforderungen und Risiken durch passende Tests nachgewiesen werden und der Zusammenhang nachvollziehbar bleibt.
ISPE: GAMP
ISO/TR 80002-2:2017
AENUMA: Update Governance
Stand: 17. August 2026.
Validierung vertiefen:
Intended Use und Scope
Validierungsplan für Dynamics 365
Traceability Matrix
CSV vs. CSA
