Validierung
Der wichtigste Satz einer Validierungsstrategie steht oft nicht im Testplan, sondern ganz am Anfang: Wofür wird das System eingesetzt? Der Intended Use beschreibt den beabsichtigten Einsatz einer Software im konkreten Unternehmen. Erst daraus lässt sich ableiten, welche Prozesse, Funktionen, Daten und Schnittstellen in den Validierungsscope gehören.
Dynamics 365 Validierung bei AENUMA · GAMP 5 bei Dynamics 365
Dynamics 365 ist keine einzelne Fachanwendung. Dieselbe Plattform kann Finanzbuchhaltung, Einkauf, Fertigung, Chargenrückverfolgung, Qualitätsprüfungen, Reklamationen, Serviceprozesse oder regulatorische Daten unterstützen. Deshalb ist die Aussage „Dynamics 365 muss validiert werden“ zu pauschal.
ISO/TR 80002-2:2017 adressiert Software, die im Qualitätsmanagementsystem, in Produktion und Service oder für Überwachung und Messung eingesetzt wird. Die FDA stellt in ihrer finalen CSA-Guidance von Februar 2026 ebenfalls den Intended Use an den Anfang ihres risikobasierten Frameworks.
Ein Microsoft-Datenblatt beschreibt, was die Software technisch kann. Der Intended Use beschreibt dagegen, welche Rolle eine konkrete Funktion im eigenen Prozess übernimmt. Genau diese Trennung ist entscheidend.
| Zu allgemein | Besserer Intended Use |
|---|---|
| „Dynamics 365 wird für Einkauf genutzt.“ | „Dynamics 365 unterstützt die Bestellung chargengeführter Materialien und stellt den Bezug zwischen Lieferant, Wareneingang und Charge her.“ |
| „Business Central verwaltet Lager.“ | „Business Central führt Serien- und Chargeninformationen für freigegebene Bestände und unterstützt die Rückverfolgung bis zum Kunden.“ |
| „Power Apps wird für Qualität genutzt.“ | „Die Power App dokumentiert die Freigabe eines qualitätsrelevanten Stammdatensatzes und übergibt den genehmigten Status an Dynamics 365.“ |
1. Welche Entscheidung oder Kontrolle unterstützt die Funktion?
Je näher eine Funktion an Produktqualität, Rückverfolgbarkeit, Freigabe, regulatorischen Daten oder einem qualitätsrelevanten Nachweis liegt, desto eher gehört sie in den Scope.
2. Was passiert, wenn die Funktion falsch arbeitet?
Ein Formatierungsfehler in einem internen Finanzbericht hat ein anderes Risiko als eine fehlerhafte Freigabe gesperrter Ware.
3. Gibt es eine unabhängige Kontrolle?
Wenn ein Fehler vor seiner Auswirkung zuverlässig erkannt wird, kann das Risiko geringer sein. Fehlt eine solche Kontrolle, steigt typischerweise der notwendige Assurance- und Testaufwand.
| Prozess | Möglicher Scope | Begründung |
|---|---|---|
| Debitorenbuchhaltung | häufig außerhalb | Reiner Finanzprozess ohne Einfluss auf Produktqualität oder QMS. |
| Chargenrückverfolgung | typisch innerhalb | Fehler können Rückruf, Ursachenanalyse und Produkthistorie beeinträchtigen. |
| Qualitätsstatus / Sperrbestand | typisch innerhalb | System steuert, ob Material verwendet oder ausgeliefert werden darf. |
| UDI-/Produktdaten | abhängig vom Einsatz | Relevant, wenn das System regulatorische Daten erzeugt, freigibt oder überträgt. |
| Field Service | teilweise | Relevant, wenn Servicehistorie oder Reklamationsdaten in qualitätsrelevante Prozesse einfließen. |
Cloud-Software ändert an diesem Grundprinzip nichts. Die FDA nennt in ihrer CSA-Guidance ausdrücklich auch SaaS, PaaS und IaaS im Zusammenhang mit Produktions- und QMS-Software. Der Anbieter verantwortet die Plattform, der Hersteller bleibt aber dafür verantwortlich, den eigenen Einsatz, die Konfiguration, Daten, Rollen und Prozesse zu beherrschen.
Das ist gerade für Dynamics 365 wichtig: Microsoft testet den Standard und betreibt die Cloud. AENUMA beziehungsweise der Hersteller muss trotzdem nachvollziehbar machen, wie die konkrete Lösung im eigenen Prozess eingesetzt wird.
Ein einziger Satz wie „Dynamics 365 unterstützt unsere Geschäftsprozesse“ ist für die Scope-Entscheidung kaum nutzbar. Praktischer ist eine strukturierte Liste je Prozess oder Funktionsgruppe.
Der Intended Use beschreibt das Warum und Wofür. Anforderungen beschreiben danach, was das System konkret leisten muss. Beispiel: Der Intended Use lautet, dass Dynamics 365 gesperrte Chargen von der Verwendung ausschließen soll. Daraus können Anforderungen an Statuslogik, Berechtigungen, Buchungsverhalten und Reporting entstehen.
Diese Trennung macht die spätere Traceability deutlich stärker, weil jede kritische Anforderung auf einen klar beschriebenen Einsatz und ein Risiko zurückgeführt werden kann.
Nicht jede Funktion derselben Anwendung muss validiert werden. Auch wenn ein Unternehmen Finance, Supply Chain, Sales und Field Service auf einer Plattform nutzt, kann der regulatorische Scope nur ausgewählte Prozesse umfassen.
Genau hier liegt der Nutzen einer sauberen Scope-Matrix: Sie verhindert sowohl Untervalidierung als auch unnötige Volltests der kompletten Plattform.
Muss für jede einzelne Dynamics-Funktion ein eigener Intended Use geschrieben werden?
Nein. Sinnvoll ist eine Granularität, mit der Risiko und Scope nachvollziehbar entschieden werden können. Häufig reicht die Ebene Prozess oder Funktionsgruppe.
Ist ein Finanzprozess immer außerhalb des Scopes?
Nein. Entscheidend ist der konkrete Einsatz. Wenn ein Finanzprozess eine qualitätsrelevante Kontrolle auslöst oder beeinflusst, kann er relevant werden.
Wer sollte den Intended Use festlegen?
Typischerweise gemeinsam Process Owner, System Owner und Quality beziehungsweise Validation. IT allein sollte die fachliche Relevanz nicht bestimmen.
Muss der Intended Use nach Änderungen aktualisiert werden?
Wenn sich der beabsichtigte Einsatz oder der Scope verändert, sollte die Beschreibung angepasst und die Auswirkung auf Anforderungen, Risiko und Tests bewertet werden.
Sobald der Intended Use steht, können Anforderungen und Risiken strukturiert aufgebaut werden. Danach entsteht die Verbindung zur Konfiguration und zu den Tests.
Nächster Schritt: Dynamics 365 validieren oder Validation Health Check.
Weiterlesen: Traceability Matrix für Dynamics 365
Weiterlesen: GAMP 5 bei Dynamics 365
Weitere Fachbeiträge zur Validierung von Dynamics 365
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.
