Ist ein ERP-System out of the box konform?

Nein. Microsoft Dynamics 365 Business Central ist out of the box nicht GxP-konform. Konformität entsteht durch risikobasierte Konfiguration, Kontrollen und Computer System Validation (CSV) gegen dokumentierte Anforderungen – nicht durch die Software allein. Diese Checkliste umfasst die Schritte, die eine Einführung im Audit belastbar machen.

Wann sollte die Validierung in einem ERP-Projekt beginnen?

Die Validierungsplanung beginnt in der Anforderungsphase, nicht nach dem Go-live. Die User Requirements Specification (URS) ist der Anker: Testprotokolle verweisen auf sie zurück, und eine frühe GxP-Risikobewertung bestimmt den Validierungsaufwand je Funktion (risikobasierter CSA-Ansatz nach GAMP 5).

Was ist der Unterschied zwischen konform und audit-ready?

Ein konformes System erfüllt die Anforderungen; ein audit-readtes System kann den Konformitätsnachweis in einer Inspektion schnell und klar vorlegen. Viele Findings entstehen nicht, weil Anforderungen unerfüllt sind, sondern weil der Nachweis nicht auffindbar ist. Beides ist Teil dieser Checkliste.

Gilt diese Checkliste für Business Central Cloud (SaaS)?

Ja. Derselbe Validierungslebenszyklus gilt für Business Central online. Der Aufwand für Lieferanten- und Infrastrukturqualifizierung verschiebt sich auf die Bewertung der dokumentierten Kontrollen von Microsoft und die SaaS-Release-Kadenz, aber Datenintegrität, Audit Trail, Zugriffskontrolle und Change Control erfordern weiterhin Konfiguration und Validierung auf Ihrer Seite.

ERP-Einführungs-Checkliste für regulierte Hersteller

Die Einführung eines ERP-Systems in einer regulierten Fertigungsumgebung ist kein Standard-Rollout. Das System hält Daten, die regulatorisches und Patientenrisiko tragen – die Einführung muss deshalb nicht nur ein funktionierendes System liefern, sondern den dokumentierten Nachweis, dass es unter Kontrolle spezifiziert, gebaut und getestet wurde. Microsoft Dynamics 365 Business Central ist out of the box nicht konform – Konformität entsteht durch risikobasierte Konfiguration und Computer System Validation (CSV) gegen dokumentierte Anforderungen. Diese Checkliste führt phasenweise durch das, was eine Einführung für einen regulierten Hersteller abdecken muss.

Wie Sie diese Checkliste nutzen

Arbeiten Sie die Phasen in Reihenfolge ab; jede erzeugt Nachweise, auf denen die nächste aufbaut. Die Tiefe je Punkt sollte einer Risikobewertung folgen – eine kritische, GxP-relevante Funktion (Chargenfreigabe, elektronische Signaturen, Audit Trail) verlangt mehr Sorgfalt als ein risikoarmer Report. Das ist der risikobasierte CSA-Ansatz, den GAMP 5 (Second Edition) erwartet: validieren, was zählt, und dokumentieren, warum der Rest weniger zählt.

Phase 1 — Scope und Anforderungen

Regulatorischen Scope festlegen: welche Regularien gelten (EU GMP Annex 11, 21 CFR Part 11, Annex 22 für KI, GAMP 5) und welche Prozesse GxP-relevant sind.
Eine von QA freigegebene User Requirements Specification (URS) erstellen – funktionale, Datenintegritäts-, Sicherheits- und regulatorische Anforderungen.
GxP-Risikobewertung je Prozessbereich durchführen, um den Validierungsaufwand zu bestimmen (CSA / risikobasiert).
Intended Use und Systemgrenzen dokumentieren, einschließlich Integrationen (LIMS, QMS, WMS, MES).

Phase 2 — Lieferanten- und Systemqualifizierung

Lieferanten bewerten: für Business Central online die dokumentierten Qualitäts- und Sicherheitskontrollen von Microsoft bewerten, statt das Rechenzentrum selbst zu auditieren.
System und Erweiterungen gegen die GAMP-5-Softwarekategorien klassifizieren.
Infrastruktur qualifizieren (oder die Nutzung der qualifizierten SaaS-Plattform dokumentieren).
Release-/Update-Kadenz verstehen und kontrollieren (SaaS-Updates sind ein Change-Control-Input, keine Überraschung).

Phase 3 — Design, Konfiguration und Datenintegrität

Audit Trail so konfigurieren, dass GxP-relevante Änderungen erfasst, zuordenbar und manipulationssicher sind (ALCOA+).
Zugriffskontrolle nach Least Privilege gestalten: rollenbasierte Rechte, Funktionstrennung, keine geteilten Konten.
Elektronische Signaturen konfigurieren, wo erforderlich, mit dokumentierter Bedeutung der Signatur.
Datenintegritätskontrollen über den Datensatz-Lebenszyklus definieren – Erstellung, Änderung, Archivierung, Aufbewahrung.
Jede Konfigurationsentscheidung so dokumentieren, dass sie auf eine Anforderung zurückverfolgt werden kann.

Phase 4 — Validierung (IQ / OQ / PQ)

Validierungsprotokolle (IQ, OQ, PQ) schreiben, die auf die URS verweisen.
Protokolle ausführen und die ausgeführten Nachweise aufbewahren.
Jede Abweichung protokollieren, bewerten und vor der Freigabe schließen.
Einen von QA freigegebenen Validation Summary Report (VSR) erstellen, der die Eignung für den Intended Use bestätigt.
Eine Traceability-Matrix von Anforderungen zu Tests pflegen.

Phase 5 — Go-live und Betrieb

Change Control vor dem Go-live etablieren – keine Änderung am validierten System ohne Bewertung.
Anwender schulen und die Schulung als Nachweis dokumentieren.
Periodic Review planen, um den validierten Zustand aktuell zu halten.
Prozess für SaaS-Updates unter Change Control definieren (Impact Assessment, Regressionstests wo sinnvoll).

Weiterführend

Computer-System-Validierung Schritt für Schritt — der Validierungslebenszyklus im Detail.
Audit-Bereitschaft für Business Central — die begleitende Checkliste für den Nachweis in der Inspektion.
GxP-Validierung für Business Central — der regulatorische Rahmen hinter diesen Schritten.

Eine Checkliste ist ein Ausgangspunkt, kein Validierungsplan. Wenn Sie eine Einführung in einer regulierten Umgebung scopen, kann ein kurzes Beratungsgespräch klären, wo die realen Risiken liegen, bevor das Projekt startet.