Validierungsstrategie
Ein Validierungsplan ist kein Dokument, das nach der Implementierung beschreibt, was ohnehin passiert ist. Er legt vorab fest, wie der Nachweis für den vorgesehenen Einsatz von Dynamics 365 aufgebaut wird: Scope, Rollen, Risikoansatz, Dokumente, Teststrategie, Abweichungen, Freigabe und späterer Betrieb.
Dynamics 365 Validierung bei AENUMA · Intended Use und Scope
Wenn die Validierungsstrategie erst kurz vor UAT formuliert wird, sind zentrale Entscheidungen längst gefallen: Prozesse wurden designt, Rollen eingerichtet, Schnittstellen gebaut und Testfälle geschrieben. Dann bleibt nur noch, Dokumentation rückwirkend an die Lösung anzupassen.
Ein früher Validierungsplan dreht diese Reihenfolge um. Er schafft Regeln dafür, wie kritische Anforderungen identifiziert, Risiken bewertet und Nachweise während des Projekts erzeugt werden.
| Frage | Inhalt |
|---|---|
| Was wird validiert? | Systeme, Prozesse, Schnittstellen, Daten und organisatorische Grenzen. |
| Warum? | Intended Use, QMS-Bezug und risikorelevante Nutzung. |
| Wer ist verantwortlich? | Process Owner, System Owner, Quality/Validation, IT und Implementierungspartner. |
| Wie tief wird getestet? | Risikobasierte Teststrategie nach Kritikalität und Umsetzungsart. |
| Welche Nachweise entstehen? | Anforderungen, Risiko, Konfiguration, Tests, Abweichungen, Traceability und Freigabe. |
| Wie bleibt der Zustand erhalten? | Change Control, Update Governance und periodische Bewertung. |
Der Plan sollte nicht nur den Produktnamen „Dynamics 365“ nennen. Relevanter ist die konkrete Lösungslandschaft: Business Central oder Finance & Supply Chain, Dataverse, Power Apps, Power Automate, Schnittstellen, ISV-Lösungen und gegebenenfalls Field Service oder andere Komponenten.
Für jede Komponente sollte klar sein, ob und warum sie in den validierten Scope fällt.
Der Validierungsplan beschreibt, nach welchem Prinzip der Test- und Dokumentationsaufwand abgeleitet wird. Der Intended Use bildet dafür den Ausgangspunkt. Je höher die potenzielle Auswirkung eines Fehlers auf Produktqualität, Datenintegrität, Rückverfolgbarkeit oder Compliance, desto höher typischerweise die notwendige Assurance-Tiefe.
Damit wird ausdrücklich vermieden, jede Standardfunktion gleich zu behandeln.
Validierung ist keine Aufgabe, die vollständig an IT oder einen Implementierungspartner delegiert werden kann. Der fachliche Owner muss entscheiden, ob ein Prozess für den vorgesehenen Zweck geeignet ist. Quality beziehungsweise Validation definiert den Rahmen und prüft die Nachweise. IT und Implementierungspartner liefern technische Umsetzung und Evidenz.
| Rolle | Typische Verantwortung |
|---|---|
| Process Owner | Anforderungen, fachliche Akzeptanz, Risiko |
| System Owner | Systembetrieb, Konfiguration, Lifecycle |
| Quality / Validation | Validierungsstrategie, Compliance-Rahmen, Review |
| IT / Partner | Design, Build, technische Dokumentation, Testunterstützung |
| Tester / Key User | Verifikation der vorgesehenen Prozesse |
Ein pragmatisches Validierungspaket muss nicht aus möglichst vielen Dokumenten bestehen. Es muss die relevanten Entscheidungen und Nachweise kontrolliert abbilden.
Wie diese Artefakte konkret heißen, hängt vom eigenen QMS ab. Entscheidend ist ihre Funktion, nicht die Überschrift.
Der Plan sollte vorab definieren, wie zwischen Standard, Konfiguration, Erweiterung und Integration unterschieden wird. Eine kundenspezifische Schnittstelle mit kritischen Daten braucht typischerweise einen tieferen eigenen Nachweis als eine unveränderte Standardfunktion mit geringer Prozesskritikalität.
Auch negative Tests gehören bewusst in die Strategie: Darf ein unberechtigter Benutzer eine Charge freigeben? Wird eine fehlerhafte Schnittstellennachricht erkannt? Kann gesperrter Bestand tatsächlich nicht verwendet werden?
Bei einer ERP-Einführung oder Migration kann die Datenübernahme selbst ein kritischer Teil des Validierungsscope sein. Für aktive Chargen, Seriennummern, Qualitätsstatus, kritische Stammdaten oder regulatorische Produktinformationen müssen Akzeptanzkriterien definiert sein.
Der Plan sollte festlegen, wie Vollständigkeit und Richtigkeit geprüft werden und wie mit Abweichungen umgegangen wird.
Nicht jeder Test muss im ersten Lauf bestehen. Entscheidend ist ein kontrollierter Umgang mit Abweichungen. Der Validierungsplan sollte deshalb definieren, wie Findings klassifiziert, bewertet, korrigiert und geschlossen werden.
Vor Go-live muss klar sein, welche offenen Punkte akzeptabel sind, wer das entscheidet und wie Restrisiken dokumentiert werden.
Dynamics 365 verändert sich nach dem Go-live. Deshalb ist ein Validierungsplan unvollständig, wenn er mit der initialen Freigabe endet. Change Control, Microsoft-Updates, eigene Releases und Regressionstests gehören zum Lifecycle-Konzept.
Ein Validation Master Plan beschreibt häufig übergeordnete Prinzipien für mehrere Systeme oder einen organisatorischen Bereich. Ein system- oder projektspezifischer Validierungsplan konkretisiert diese Prinzipien für die jeweilige Dynamics-365-Lösung.
Ob beide Dokumente benötigt werden, hängt von QMS und Organisationsgröße ab. Für kleinere Organisationen kann ein klarer systembezogener Plan ausreichend sein, wenn die übergeordneten Regeln darin enthalten sind.
Muss der Validierungsplan vor Projektstart final sein?
Nicht zwingend. Er sollte jedoch früh genug stehen, um Design, Dokumentation und Teststrategie zu steuern. Änderungen am Plan sollten kontrolliert erfolgen.
Braucht jede Dynamics-App einen eigenen Plan?
Nicht automatisch. Mehrere Komponenten können in einer gemeinsamen Validierungsstrategie betrachtet werden, wenn Scope, Verantwortlichkeiten und Nachweise eindeutig bleiben.
Wer genehmigt den Validierungsplan?
Das hängt vom QMS ab. Typischerweise sind System-/Process Owner und Quality beziehungsweise Validation beteiligt.
Kann der Implementierungspartner den Plan schreiben?
Ja, unterstützen oder erstellen. Die Verantwortung für den eigenen Intended Use und die Freigabe des validierten Einsatzes verbleibt jedoch beim Hersteller.
Ein guter Validierungsplan sorgt dafür, dass der Nachweis parallel zum Projekt entsteht. Dadurch sinkt der Aufwand am Ende und kritische Lücken werden sichtbar, bevor sie den Go-live blockieren.
Nächster Schritt: Validation Health Check oder Dynamics 365 Validierung.
Weiterlesen: Traceability Matrix
Weiterlesen: CSV vs. CSA
Weitere Beiträge zu Validierungsplanung und Betrieb
ISO: ISO/TR 80002-2:2017
FDA: Computer Software Assurance, Final Guidance, Februar 2026
Stand: 17. August 2026. Organisatorische und technische Einordnung, keine rechtliche Einzelfallprüfung.
