Cloud-Betrieb
Cloud-Software ändert sich kontinuierlich. Daraus folgt aber nicht, dass nach jedem Microsoft-Update das komplette System neu validiert werden muss. Entscheidend ist, ob eine Änderung den validierten Scope berührt und welches Risiko daraus entsteht.
Update Governance bei AENUMA · Release Wave 2 2026 im validierten Betrieb
Finance und Supply Chain Management erhalten vier Service Updates pro Jahr; Microsoft verlangt, dass Kunden mindestens zwei davon übernehmen. Customer-Engagement-Apps und Power Platform haben zwei große Release-Zyklen pro Jahr und zusätzliche Service Updates. Business Central online hat zwei große Updatezyklen sowie monatliche Minor Updates.
Für regulierte Betreiber ist deshalb nicht eine einzelne „Release Wave“ das Problem. Entscheidend ist ein wiederholbarer Prozess, der jede relevante Änderung bewertet.
Vor dem Test steht die Frage: Was hat sich tatsächlich geändert? Ein Update kann eine neue Funktion enthalten, eine bestehende Funktion verändern, einen Fehler beheben oder nur technische Komponenten betreffen. Der erste Schritt ist deshalb die Zuordnung zur eigenen Lösung und zum validierten Scope.
| Frage | Konsequenz |
|---|---|
| Berührt die Änderung unseren Scope? | Wenn nein: Entscheidung dokumentieren. |
| Ist eine kritische Funktion betroffen? | Risiko und Testbedarf bewerten. |
| Ändert sich Konfiguration oder Prozess? | Change Control und ggf. Dokumentation anpassen. |
| Gibt es abhängige Schnittstellen? | End-to-End-Auswirkungen berücksichtigen. |
1. Kein eigener Test notwendig. Die Änderung betrifft den validierten Scope nicht oder hat nachweislich keine Auswirkung. Dann reicht eine dokumentierte Bewertung.
2. Gezielter Regressionstest. Eine relevante Funktion ist betroffen, aber das Risiko ist klar eingegrenzt. Dann werden die kritischen Szenarien und Schnittstellen getestet.
3. Erweiterte Revalidierung. Kritische Logik, Datenmodell, Prozesssteuerung oder umfangreiche Erweiterungen ändern sich. Dann kann eine breitere Test- und Dokumentationsaktualisierung erforderlich sein.
Automatisierte Regressionstests können wiederkehrende Kernprozesse schnell prüfen. Sie beantworten aber nicht automatisch die regulatorische Frage, ob eine Änderung relevant ist. Dafür braucht es Prozesswissen, Systemkenntnis und einen dokumentierten Entscheidungsweg.
In Audits ist ein nachvollziehbarer, risikobasierter Prozess meist belastbarer als pauschale Volltests. Entscheidend ist, dass sichtbar wird, warum eine Änderung als nicht relevant, gering riskant oder testpflichtig eingestuft wurde.
Grundlage: GAMP 5 bei Dynamics 365
Nächster Schritt: Update Governance für Dynamics 365 oder Validation Health Check.
Weitere Beiträge zu Validierung und Cloud-Betrieb
Microsoft beschreibt Änderungen in Release-Plänen und Service-Update-Dokumentation. Für den regulierten Betrieb reicht das Lesen der Release Notes aber nicht aus. Die Änderung muss gegen die eigene Lösung, Konfiguration, Erweiterungen und den validierten Scope bewertet werden.
Eine Funktion kann global relevant wirken und für die eigene Organisation trotzdem keine Auswirkung haben. Umgekehrt kann eine scheinbar kleine Änderung kritisch sein, wenn sie genau einen qualitätsrelevanten Prozess oder eine kundenspezifische Erweiterung berührt.
Dynamics 365 ist keine einzelne Anwendung mit einem einheitlichen Update-Modell. Customer-Engagement-Apps und Power Platform arbeiten mit zwei großen Release-Wellen pro Jahr und laufenden Service Updates. Finance und Supply Chain folgen ihrem eigenen Service-Update-Modell. Business Central hat ebenfalls eigene Major- und Minor-Updatezyklen.
Für die Governance bedeutet das: Der Prozess sollte an der tatsächlich eingesetzten Anwendung ausgerichtet sein und nicht an einer pauschalen Aussage wie „Dynamics wird zweimal im Jahr aktualisiert“.
Ein dokumentiertes Impact Assessment sollte mindestens prüfen, ob sich eine Änderung auf kritische Funktionen, Datenmodelle, Rollen, Schnittstellen, Berichte oder Benutzerabläufe auswirkt. Zusätzlich sollte bewertet werden, ob eine kundenspezifische Erweiterung oder ein ISV-Produkt betroffen ist.
| Kriterium | Beispielfrage |
|---|---|
| Prozess | Ändert sich ein qualitätsrelevanter Ablauf? |
| Daten | Ändern sich Felder, Validierungen oder Datenflüsse? |
| Security | Ändern sich Rollen, Berechtigungen oder Freigaben? |
| Integration | Sind Schnittstellen oder APIs betroffen? |
| Customizing | Kann eine Erweiterung durch die Änderung beeinflusst werden? |
Microsoft stellt für verschiedene Dynamics-Anwendungen Möglichkeiten bereit, Änderungen vor Produktion in einer Sandbox oder Testumgebung zu prüfen. Für regulierte Prozesse sollte diese Vorlaufzeit bewusst genutzt werden.
Die Testumgebung muss dafür repräsentativ genug sein: relevante Konfiguration, aktuelle Lösungskomponenten und ausreichend realistische Daten oder Testszenarien. Ein leerer Sandbox-Mandant liefert wenig Sicherheit über den tatsächlichen Produktionsprozess.
Nach dem Impact Assessment wird der Testumfang festgelegt. Wenn nur eine klar abgegrenzte, nichtkritische Oberfläche betroffen ist, kann ein begrenzter Test reichen. Wenn eine Änderung dagegen Materialfreigabe, Traceability, Produktionssteuerung oder eine kritische Schnittstelle berührt, sollte die Regression entsprechend tiefer gehen.
Der entscheidende Punkt ist die Begründung: Warum wurden genau diese Szenarien getestet und andere nicht?
Wiederkehrende Kernprozesse eignen sich gut für automatisierte Regressionstests. Dazu können beispielsweise Auftragserfassung, Wareneingang, Chargenfluss oder zentrale Integrationen gehören. Automatisierung reduziert wiederkehrenden Aufwand und erhöht die Vergleichbarkeit.
Sie ersetzt jedoch nicht das Impact Assessment. Ein automatisierter Test kann bestätigen, dass ein Prozess noch funktioniert, aber nicht entscheiden, ob eine neue Funktion regulatorisch relevant ist.
Viele Organisationen trennen Microsoft-Updates und eigene Changes organisatorisch. Für den validierten Zustand sollten beide dennoch in einem konsistenten Change-Control-Modell zusammenlaufen. Ein Update kann mit einer eigenen Konfigurationsänderung interagieren; eine Erweiterung kann auf einem neuen Microsoft-Verhalten anders reagieren.
Deshalb sollte die Freigabe immer den resultierenden Systemzustand betrachten.
Ein Update verändert die Darstellung eines nichtkritischen Finance-Berichts. Nach Bewertung besteht keine Auswirkung auf den validierten Scope. Die Entscheidung wird dokumentiert, ein eigener Regressionstest ist nicht erforderlich.
Ein anderes Update verändert dagegen eine Funktion, die im Wareneingang Qualitätsprüfungen auslöst. Hier sind Prozess, Sperrlogik und möglicherweise Schnittstellen betroffen. Das Impact Assessment führt zu gezielten Regressionstests und einer dokumentierten Freigabe.
Muss nach jedem Microsoft-Update revalidiert werden?
Nein. Jede relevante Änderung sollte bewertet werden. Der notwendige Nachweis richtet sich nach Auswirkung und Risiko.
Reicht ein Smoke Test?
Nur wenn das Impact Assessment zeigt, dass damit die betroffenen Risiken angemessen abgedeckt werden. Für kritische Änderungen kann ein tieferer Regressionstest notwendig sein.
Wer sollte das Impact Assessment durchführen?
Typischerweise gemeinsam System Owner, Process Owner, Quality/Validation und bei Bedarf IT oder Implementierungspartner. Die konkrete Verantwortung sollte im Governance-Modell definiert sein.
Müssen Release Notes archiviert werden?
Entscheidend ist, dass die Bewertung der relevanten Änderung und die daraus abgeleitete Entscheidung nachvollziehbar dokumentiert werden. Welche Originalunterlagen archiviert werden, hängt vom eigenen Verfahren ab.
Microsoft Learn: Dynamics 365 Service Updates
Microsoft Learn: Business Central Updates
ISPE: GAMP
Stand: 17. August 2026.
Validierung vertiefen:
Intended Use und Scope
Validierungsplan für Dynamics 365
Traceability Matrix
CSV vs. CSA
