Validierungsnachweis
Eine Traceability Matrix ist kein Selbstzweck und keine Excel-Tabelle, die kurz vor dem Audit gefüllt wird. Sie beantwortet eine einfache Frage: Können wir für eine kritische Anforderung nachvollziehbar zeigen, warum sie existiert, wie sie umgesetzt wurde und welcher Test den Nachweis liefert?
Dynamics 365 Validierung bei AENUMA · Intended Use und Scope
In einer regulierten Dynamics-365-Lösung entstehen Anforderungen aus Prozessen, Risiken, regulatorischen Vorgaben und internen Kontrollen. Während der Implementierung werden diese Anforderungen in Standardfunktionen, Konfiguration, Power-Platform-Komponenten, Schnittstellen oder Erweiterungen umgesetzt.
Die Traceability verbindet diese Ebenen. Sie macht sichtbar, ob eine kritische Anforderung tatsächlich umgesetzt und angemessen verifiziert wurde.
| Ebene | Beispielfrage |
|---|---|
| Intended Use | Wofür wird der Prozess eingesetzt? |
| Anforderung | Was muss das System leisten? |
| Risiko | Was passiert, wenn die Funktion versagt? |
| Umsetzung | Welche Standardfunktion, Konfiguration oder Erweiterung erfüllt die Anforderung? |
| Test | Welcher Nachweis zeigt, dass die Anforderung erfüllt ist? |
| Ergebnis | Bestanden, Abweichung oder offene Maßnahme? |
Angenommen, ein Medizinproduktehersteller nutzt Dynamics 365, um nicht freigegebene Chargen zu sperren. Der Intended Use beschreibt, dass nur freigegebenes Material für weitere operative Prozesse verwendet werden darf.
Daraus entsteht beispielsweise die Anforderung: „Das System muss verhindern, dass eine gesperrte Charge in einem Produktionsauftrag verbraucht wird.“ Das Risiko wäre die Verwendung nicht freigegebenen Materials. Die Umsetzung kann über Qualitätsstatus, Blocking-Logik, Rollen und Prozesskonfiguration erfolgen. Der Test muss dann nicht nur zeigen, dass eine freigegebene Charge funktioniert, sondern auch, dass eine gesperrte Charge tatsächlich blockiert wird.
Eine gute Traceability macht diesen Zusammenhang ohne Interpretationsarbeit sichtbar.
Eine Matrix mit 500 Anforderungen ist nicht automatisch besser als eine mit 80. Entscheidend ist die Qualität der Anforderungen und die Risikoorientierung. Kritische Funktionen benötigen eine belastbare Kette. Für nichtkritische Standardfunktionen kann der Nachweis schlanker ausfallen.
Das entspricht dem Grundgedanken eines risikobasierten Validierungsansatzes: Der Aufwand konzentriert sich dort, wo ein Fehler Produktqualität, Datenintegrität, Rückverfolgbarkeit oder Compliance beeinflussen kann.
Für Dynamics-365-Projekte reicht häufig eine kompakte Struktur:
Weitere Felder können sinnvoll sein, wenn sie einen echten Zweck erfüllen. Eine Traceability Matrix sollte nicht zum Ersatz für Design-, Risiko- oder Testdokumente werden.
Bei Dynamics 365 ist es hilfreich, in der Umsetzungsreferenz sichtbar zu machen, wie die Anforderung realisiert wurde. Eine Standardfunktion benötigt eine andere Dokumentationstiefe als eine kundenspezifische Erweiterung.
| Umsetzung | Typischer Nachweis |
|---|---|
| Microsoft-Standard | Funktionsreferenz, relevante Konfiguration, risikobasierter Prozessnachweis |
| Konfiguration | Konfigurationsentscheidung, Parameter, Rollen, Test |
| Power Platform | Lösungskomponente, Logik, Schnittstellen, Berechtigungen, Test |
| Custom Extension | Design, Code-/Build-Kontrolle, technische und fachliche Verifikation |
| Schnittstelle | Mapping, Fehlerbehandlung, Monitoring, End-to-End-Test |
In vielen Projekten wird Traceability auf die Beziehung „Anforderung → Testfall“ reduziert. Für komplexere oder kritische Prozesse ist die Verbindung zum Risiko mindestens genauso wichtig. Sonst kann zwar gezeigt werden, dass etwas getestet wurde, aber nicht, warum genau diese Testtiefe angemessen war.
Eine stärkere Kette lautet deshalb: Intended Use → Anforderung → Risiko → Umsetzung → Test → Ergebnis.
Die Traceability Matrix ist auch für den Cloud-Betrieb wertvoll. Wenn Microsoft ein Update veröffentlicht oder eine eigene Konfiguration geändert wird, kann das Impact Assessment gezielt prüfen, welche Anforderungen betroffen sind. Daraus lassen sich die relevanten Testfälle ableiten.
Genau deshalb sollte die Matrix nicht nur zum Go-live existieren. Sie ist ein Werkzeug für Change Control und Revalidierung.
Weiter: Wann ist Revalidierung nötig?
Am effizientesten entsteht die Matrix während der Implementierung. Anforderungen werden vor oder während des Designs nummeriert. Konfiguration und Build referenzieren diese IDs. Testfälle werden direkt auf die relevanten Anforderungen zurückgeführt.
Dadurch muss der Zusammenhang am Projektende nicht rekonstruiert werden. Gleichzeitig wird früh sichtbar, wenn eine kritische Anforderung noch keinen Nachweis besitzt.
Braucht jede Anforderung einen eigenen Testfall?
Nein. Ein Testfall kann mehrere zusammenhängende Anforderungen abdecken, wenn die Zuordnung eindeutig bleibt. Umgekehrt kann eine kritische Anforderung mehrere Tests benötigen.
Muss die Matrix in Excel geführt werden?
Nein. Entscheidend ist die kontrollierte, nachvollziehbare Beziehung. Das kann in Excel, einem ALM-Tool, Azure DevOps oder einem anderen geeigneten System erfolgen.
Gehören nichtkritische Anforderungen in die Matrix?
Das hängt vom Validierungskonzept ab. Kritische Anforderungen sollten zuverlässig tracebar sein. Für weniger relevante Funktionen kann eine schlankere Dokumentation angemessen sein.
Muss die Matrix nach jedem Update angepasst werden?
Nur wenn sich Anforderungen, Umsetzung oder relevante Tests ändern. Das Impact Assessment sollte entscheiden, ob eine Aktualisierung notwendig ist.
Eine gute Traceability Matrix reduziert nicht nur Auditaufwand. Sie hilft dem Projektteam, Lücken früh zu erkennen und später gezielt zu entscheiden, welche Tests nach einer Änderung erneut benötigt werden.
Nächster Schritt: Validation Health Check oder Dynamics 365 Validierung.
Weiterlesen: Validierungsplan für Dynamics 365
Weiterlesen: GAMP 5 bei Dynamics 365
Mehr Beiträge zu Validierung und Nachweisführung
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.
