Inhaltsverzeichnis
Das Wichtigste vorab
Wie wird Odoo im GMP-Umfeld validiert?
Odoo validieren bedeutet, die Eignung der tatsächlich eingesetzten Anwendungen und Datenwege für den vorgesehenen GMP-Prozess nachzuweisen. Dazu gehören Edition, Betriebsform, Erweiterungen, Rechte sowie die korrekte Verbindung von Artikel, Los, Menge und Qualitätsentscheidung. Ein stimmiger Gesamtbestand genügt nicht. Anforderungen, Fehlerfolgen und vorhandene Belege bestimmen, welche Konfigurationen, Übergänge und Fehlerfälle geprüft werden müssen.
- Community und Enterprise sind Editionen; Online, Odoo.sh und On-Premise beschreiben unterschiedliche Betriebsformen.
- Nachträgliche Loszuordnung benötigt belastbare Herkunftsbelege zusätzlich zum Mengenabgleich.
- Ein bestandener Quality-Check belegt nur die definierte Prüfung, keine vollständige Chargenfreigabe.
- Mehrere JSON-2-Aufrufe bilden nicht automatisch eine gemeinsame Transaktion.
Zuerst Edition, Hosting und Erweiterungen auseinanderhalten
Die Frage „Welche Odoo-Version nutzen Sie?“ reicht für den Nachweis nicht aus. Erfassen Sie Kernversion, Edition, Hosting, Anwendungen und Zusatzmodule gemeinsam. Zwei Installationen mit derselben Hauptversion können Buchungen oder Prüfentscheidungen unterschiedlich verarbeiten. Auch ein Implementierungspartner kann Änderungen eingebracht haben, die in der allgemeinen Anwenderdokumentation nicht vorkommen.
Odoo unterscheidet Community und Enterprise. Die Hostingübersicht ordnet Online der Enterprise-Edition zu; On-Premise kann mit beiden Editionen betrieben werden. Die Anleitung für Odoo.sh verlangt eine passende Enterprise-Subscription. Eigene Module unterstützt Online laut Dokumentation nicht. Daraus folgt jedoch kein pauschales Verbot anderer Konfigurationen. Ebenso wenig ist der Funktionsumfang der Quality-Anwendung für jede Community-Konstellation belegt.
Die folgende Arbeitshilfe hält diese Ebenen getrennt. Sie ersetzt weder eine Lizenzprüfung noch den Nachweis für Ihre Installation. Für jede relevante Erweiterung sollte erkennbar sein, wer sie pflegt und welcher geprüfte Stand tatsächlich produktiv läuft.
| Ebene | Festzuhaltender Stand | Entscheidende Nachweisfrage |
|---|---|---|
| Edition und Anwendungen | Community/Enterprise; installierte Apps und Lizenzen | Welche beschriebenen Funktionen sind tatsächlich verfügbar? |
| Online | Kern-/Zwischenversion und verwendete Konfiguration | Welche Änderungen kommen vom Anbieter, welche vom eigenen Team? |
| Odoo.sh | Subscription, Repository, Modulstände und Datenbankstand | Entspricht die geprüfte Kombination dem Produktivstand? |
| On-Premise | Edition, Infrastruktur und Betreiberzuständigkeit | Wer verantwortet Betrieb, Sicherung und Updates? |
| Erweiterungen und Datenwege | Eigene/fremde Module und konkrete Schnittstellen | Welche Eingriffe verändern den regulierten Prozess? |
Welche Odoo-Prozesse fallen in den GMP-Nachweis?
Dieser Artikel betrachtet Odoo innerhalb der Herstellung von Humanarzneimitteln. Annex 11 ist die einschlägige EU-GMP-Leitlinie für computergestützte Systeme in GMP-regulierten Tätigkeiten. Der aktuelle EudraLex-Index führt weiterhin die Revision von Januar 2011. Konsultationsentwürfe werden hier nicht als geltende Anforderungen verwendet.
Beschreiben Sie den konkreten Einfluss: Steuert Odoo die Verwendbarkeit eines Ausgangsmaterials, übermittelt es eine Chargenidentität oder bewahrt es entscheidungsrelevante Aufzeichnungen auf? Ein ausschließlich kaufmännischer Vorgang und ein qualitätsrelevanter Lagerprozess benötigen nicht automatisch denselben Prüfumfang. Die Abgrenzung darf jedoch keine indirekten Auswirkungen ausblenden, etwa ein gemeinsames Stammdatenfeld.
Die Anwendung zu validieren und die eingesetzte IT-Infrastruktur angemessen zu qualifizieren sind unterschiedliche Nachweisfragen. Aus dem Produktnamen folgen weder eine feste Softwarekategorie noch eine allgemeine GxP-Zulassung. Anforderungen anderer Bereiche, etwa Medizinprodukte, reiner Großhandel oder FDA-regulierte Aufzeichnungen, sind für den jeweiligen Einsatz gesondert zu bestimmen.
Anforderungen am erlaubten Prozess formulieren
Eine hilfreiche Anforderung beschreibt eine Entscheidung: „Material mit ungeklärter Losidentität darf nicht in den vorgesehenen Herstellprozess gelangen.“ Erst danach legen Sie fest, welche Kombination aus Softwarekontrolle, Lagerorganisation und befugter Entscheidung dieses Ziel erfüllt. Die bloße Anforderung „Chargenverwaltung vorhanden“ lässt entscheidende Ausnahmen offen.
Verfolgen Sie einen typischen Vorgang vom Wareneingang bis zur Verwendung. Fragen Sie an jedem Übergang nach Identität, Menge, Einheit, Status und Verantwortlichem. Ein falscher Losname bei richtiger Menge kann andere Folgen haben als ein fehlender, sofort sichtbarer Datensatz. Die Testtiefe sollte diese Unterschiede widerspiegeln.
Vorhandene Lieferantenbelege können einen Teil der Fragen beantworten. Ordnen Sie jeden verwendeten Beleg dem passenden Funktions- und Versionsstand zu. Offen bleiben häufig die eigene Konfiguration und die angeschlossenen Systeme. Unbekanntes Verhalten wird als Unsicherheit dokumentiert; fehlende Informationen begründen keine niedrige Risikoeinstufung.
Nachträgliche Loszuordnung: Herkunft vor Buchung klären
Odoo beschreibt für bereits vorhandenen Bestand einen besonderen Übergang: Wird die Verfolgung nach Losen oder Seriennummern erst später aktiviert, können inkonsistente Datensätze entstehen. Die Dokumentation 20.0 erläutert dazu zwei Bestandskorrekturen, welche unzugeordnete Mengen durch zugeordnete Mengen ersetzen. Dabei sind alle betroffenen Lagerorte zu berücksichtigen.
Das ist eine technische Funktionsbeschreibung, keine Freigabe für ungeprüfte Produktivkorrekturen. Vor einer Umstellung benötigen Sie einen bekannten Ausgangsbestand und unabhängige Belege zur tatsächlichen Losidentität. Ein Lieferschein allein genügt beispielsweise nicht, wenn sich seine Mengen nicht mehr dem vorhandenen Material zuordnen lassen. Ungeklärte Herkunft wird nicht durch eine nachträglich eingetragene plausible Nummer geheilt.
Für den geplanten Übergang sollten Lager und QA festlegen, wie offene Bewegungen, Reservierungen und nicht eindeutig zuordenbare Mengen behandelt werden. Erproben Sie das Vorgehen in einer geeigneten Testumgebung. Bewahren Sie Vorherbestand, Zuordnungsgrundlage, Änderungsgrund und Ergebnis zusammen auf. Erst mit bewerteten Abweichungen und einer befugten Entscheidung lässt sich der produktive Ablauf festlegen.
Prüfbeispiel: 100 Stück sind noch kein korrekter Losbestand
Das folgende Beispiel ist konstruiert; es beschreibt keinen Kundenfall und keinen ausgeführten Odoo-Test. In einer isolierten Testumgebung liegen 100 Stück eines Artikels zunächst ohne Loszuordnung vor. Unveränderte, unabhängige Lagerbelege weisen 60 Stück Los A am Platz P1 und 40 Stück Los B am Platz P2 nach. Mengenänderungen durch andere Vorgänge sind während des Versuchs ausgeschlossen.
Im festgelegten Soll darf nur Los A verwendet werden; für B ist die Qualitätsentscheidung offen. Jeder Tabellenfall startet separat mit dem beschriebenen Ausgangszustand. Im Herkunftsfehlerfall erlaubt ein abweichender fiktiver Belegsatz für fünf Stück am Platz P2 keine eindeutige Zuordnung. Die Erwartung lautet dann 60 eindeutig A, 35 eindeutig B und 5 ungeklärte Stück, zusammen weiterhin 100.
Die Mengenrechnung ist unabhängig: 60 + 40 = 100. Auch eine falsche Zuordnung von 40 zu A und 60 zu B ergibt 100. Erst der Einzelvergleich zeigt −20 bei A und +20 bei B. Dokumentieren Sie im Test tatsächliche Datensätze und Reaktionen neben diesem vorab festgelegten Soll; ein nachträglich angepasster Sollwert wäre kein unabhängiger Vergleich.
| Prüffall | Kontrollierte Eingabe | Unabhängige Erwartung | Zu sichernder Beleg |
|---|---|---|---|
| Korrekte Zuordnung | 60 zu A/P1 und 40 zu B/P2 übernehmen | A = 60; B = 40; Gesamt = 100 | Vorher-/Nachherbestand mit ursprünglicher Zuordnungsgrundlage |
| Vertauschte Mengen | Im Ziel 40 zu A/P1 und 60 zu B/P2 zuordnen; Originalbelege erhalten | Gesamt 100, aber Abweichung −20/+20; Zuordnung nicht akzeptieren | Einzelvergleich je Los und Lagerplatz; bewerteter Befund |
| Herkunft unklar | Für 5 der 40 Stück am P2 fehlt ein belastbarer Losbeleg | 60 A + 35 B + 5 ungeklärt = 100; keine erfundene Zuordnung | Klärungsbedarf und Entscheidung über betroffene Menge |
| Verwendung von B | B über einen tatsächlich genutzten Weiterverarbeitungsweg anfordern | Keine Verwendung vor befugter Entscheidung gemäß festgelegtem Kontrollkonzept | Reaktion und Wirksamkeit der vorgesehenen Kontrolle |
| Doppelte Übernahme | Erste Übernahme 60/40 abschließen; denselben Umstellungsdatensatz erneut anbieten | Endbestand bleibt 100; Wiederholung erzeugt keine zweite reguläre Bestandsmenge | Identität des Eingangs, Verarbeitungsstatus und Endbestand |
Quality-Check und Verwendungsentscheidung verbinden
Odoo Quality beschreibt Pass-Fail-Prüfungen, die einzeln oder über Quality Control Points entstehen. Sie können Bestands-, Fertigungs- oder Arbeitsaufträge betreffen. Ein Qualitätscheck bestätigt zunächst das darin definierte Kriterium. Ob daraus eine Reservierung, Entnahme oder Auslieferung zulässig wird, ist eine eigene Prozessfrage.
Prüfen Sie deshalb den Zusammenhang in Ihrer Konfiguration: Welcher Check gehört zu welcher Menge? Wer darf das Ergebnis erfassen oder ändern? Was geschieht nach Fail? Die Anleitung beschreibt einen möglichen Quality-Alert-Schritt, belegt aber keine universelle Sperre aller weiteren Datenwege. Im Shop-Floor-Ablauf nennt sie außerdem eine Checkbox, über die ein Check direkt als bestanden abgeschlossen werden kann. Dieser alternative Bedienweg gehört in die Bewertung, wenn er verwendet werden kann.
Eine betriebliche Materialentscheidung ist von der Zertifizierung einer Fertigproduktcharge zu unterscheiden. Annex 16 beschreibt im EU-Kontext die QP-Zertifizierung und den anschließenden Übergang in verkaufsfähigen Bestand. Das Wort „bestanden“ in Odoo ersetzt diese Entscheidung und ihre Nachweise nicht.
JSON-2: erfolgreiche Aufrufe können einen unvollständigen Ablauf ergeben
Die Dokumentation 20.0 beschreibt JSON-2 als seit Version 19.0 eingeführte Schnittstelle. Verfügbare Modelle und Methoden hängen von der konkreten Datenbank ab. Der dokumentierte Preisplanhinweis nennt externe API-Nutzung für Custom und grenzt Standard sowie One App Free ab. Prüfen Sie diese Bedingung für Ihren Vertrag; sie ist keine vollständige Aussage zu jeder selbst betriebenen Community-Installation.
Technisch entscheidend: Jeder JSON-2-Aufruf läuft in einer eigenen SQL-Transaktion. Mehrere aufeinanderfolgende Aufrufe lassen sich darüber nicht automatisch zu einer gemeinsamen Transaktion verbinden. Liest eine Integration zuerst einen Bestand und führt später eine Änderung aus, können zwischenzeitliche Vorgänge den Ausgangszustand verändert haben.
Definieren Sie daher die fachlich zusammengehörige Operation und den erwarteten Fehlerweg. Unterbrechen Sie im Test zwischen den tatsächlich verwendeten Aufrufen. Prüfen Sie anschließend den gespeicherten Zustand, die Meldung an den Absender und einen erneuten Versuch. Eine erfolgreiche HTTP-Antwort für einen Teilaufruf beantwortet nicht, ob der gesamte Lagerprozess korrekt abgeschlossen wurde. Die Wahl einer passenden atomaren Methode oder anderer wirksamer Kontrollen muss zur realen Integration passen.
Berechtigungen und nachvollziehbare Änderungen konkret prüfen
Die JSON-2-Dokumentation verweist auf Benutzerrechte, Datensatzregeln und Feldzugriffe. Für dauerhafte Integrationen empfiehlt Odoo eigene technische Benutzer. Daraus lässt sich jedoch keine vollständige Historie jeder qualitätsrelevanten Änderung ableiten. Ermitteln Sie für Ihre Daten, welche Information tatsächlich protokolliert wird und wer sie lesen oder verändern kann.
Ein geeigneter Prüfauftrag beginnt mit einer konkreten Änderung: Ein Benutzer korrigiert die Loszuordnung, ein anderer ändert das Prüfergebnis. Kann der Reviewer ursprünglichen und neuen Inhalt, handelnde Identität, Zeitpunkt und erforderliche Begründung nachvollziehen? Sind die betroffenen Mengen eindeutig zu erkennen? Berücksichtigen Sie auch einen Integrationsbenutzer; dessen technischer Name erklärt noch nicht die vorgelagerte fachliche Entscheidung.
Legen Sie außerdem fest, welche Aufzeichnungen über welchen Zeitraum benötigt werden und wie sie zusammen auffindbar bleiben. Eine Bestandsliste ohne Zuordnungsgrundlage kann für einen aktuellen Überblick genügen, aber den historischen Entscheidungsweg unzureichend erklären. Die Eignung von Export, Historienansicht und ergänzenden Belegen wird an diesem Zweck geprüft.
Updates, Modulwechsel und Wiederherstellung mit demselben Prozess verbinden
Ein Update kann den beschriebenen Nachweis an verschiedenen Stellen berühren: neue Kernversion, geändertes Zusatzmodul, andere Datensatzregel oder angepasste Schnittstelle. Vergleichen Sie den betroffenen Prozess mit der vorhandenen Evidenz. Daraus ergeben sich gezielte neue Prüfungen; weder automatische Vollwiederholung noch ungeprüfte Übernahme alter Ergebnisse ist angemessen.
Bei einem Hostingwechsel sind technische und fachliche Übergänge gemeinsam zu betrachten. Die Odoo.sh-Anleitung unterscheidet Hauptversionen von Online-Zwischenversionen und beschreibt einen Import, der vorhandene Branch-Daten überschreibt. Klären Sie Kompatibilität und Rückfall vor der Durchführung. Ein erfolgreicher Import belegt noch nicht die richtige Zuordnung aller Daten und Dateien.
Für die Wiederherstellung wählen Sie einen Datensatz mit aussagekräftiger Historie: beispielsweise eine korrigierte Loszuordnung mit zugehörigem Prüfbeleg. Zeigen Sie nach Wiederherstellung, dass Identität, Menge und erforderlicher Kontext wieder verfügbar sind. Die organisatorische Zuständigkeit des Hosters ersetzt nicht die Prüfung, ob Ihr Prozess damit ausreichend unterstützt wird.
Was Ihr Team vorbereitet und was den Aufwand bestimmt
Der Umfang hängt weniger von der Zahl der Menüpunkte ab als von den unterschiedlichen Datenwegen und offenen Nachweisfragen. Lager und QA liefern den erlaubten Ablauf und belastbare Zuordnungsbelege. IT und Implementierungspartner beschreiben Komponenten, Rechte und technische Übergaben. Die befugten Verantwortlichen bewerten offene Befunde und entscheiden über die Verwendung.
Eine Standardinstallation mit gut belegtem Prozess ist anders zu bearbeiten als ein gewachsener Bestand mit mehreren Erweiterungen. Zusätzlichen Aufwand verursachen vor allem unklare Herkunft, fehlende Versionsstände, alternative Buchungswege und eine unrepräsentative Testumgebung. Beginnen Sie mit dieser Checkliste, bevor Sie Testfälle bestellen oder eine Umstellung terminieren.
- Edition, Hosting, Versionen und betroffene Module sind eindeutig erfasst.
- Der GMP-relevante Prozess und die erlaubten Ausnahmen sind beschrieben.
- Losidentität, Menge, Einheit und Lagerort haben unabhängige Sollbelege.
- Ungeklärte Mengen erhalten einen befugten Entscheidungsweg.
- Quality-Status und tatsächliche Verwendung sind über relevante Wege geprüft.
- API-Abbruch, Wiederholung und konkurrierende Änderung haben klare Erwartungen.
- Historie, Rollen und Aufbewahrung beantworten die erforderlichen Reviewfragen.
- Änderungsbewertung, Wiederherstellung und offene Befunde sind berücksichtigt.
Häufige Fragen zu Odoo
Kann Odoo Community im GMP-Umfeld eingesetzt werden?
Die Edition allein beantwortet die Eignungsfrage nicht. Entscheidend sind der vorgesehene Prozess, die tatsächlichen Funktionen und wirksame Kontrollen. Übertragen Sie Enterprise- oder Quality-Beschreibungen nicht ungeprüft auf Community. Stellen Sie zunächst Module, Betreiber und verfügbare Nachweise zusammen. Offene Anforderungen können eine andere Konfiguration oder Lösung nötig machen; sie werden durch den Open-Source-Status weder automatisch erfüllt noch ausgeschlossen.
Müssen wir bei Odoo das gesamte ERP validieren?
Bestimmen Sie den Umfang anhand des GMP-Einflusses und der Abhängigkeiten. Ein kaufmännischer Ablauf kann außerhalb des relevanten Anwendungsumfangs liegen, während ein gemeinsam verwendetes Materialfeld berücksichtigt werden muss. Dokumentieren Sie diese Grenze und ihre Begründung. Eine bloße Liste ausgeschlossener Apps reicht nicht, wenn Rechte, Stammdaten oder Schnittstellen den regulierten Prozess dennoch verändern.
Wie gehen wir mit Bestand ohne bekannte Loszuordnung um?
Trennen Sie vorhandene Menge von belegter Herkunft. Nutzen Sie geeignete unveränderte Lager- und Lieferbelege zur Zuordnung. Wenn diese für einen Teilbestand nicht reichen, bleibt die Herkunft offen und benötigt eine befugte Bewertung. Tragen Sie keine plausible Losnummer ein, nur damit die Datenstruktur vollständig aussieht. Eine technische Bestandskorrektur erzeugt keine historische Evidenz.
Genügt der Gesamtbestand nach einer Umstellung als Prüfkriterium?
Nein. Prüfen Sie zusätzlich die Zuordnung je Artikel, Los, Einheit und relevantem Lagerort. Im Beispiel ergeben sowohl 60/40 als auch 40/60 zusammen 100 Stück. Der Summenabgleich übersieht die Vertauschung. Legen Sie das Soll aus unabhängigen Unterlagen vor dem Test fest und sichern Sie die ursprünglichen Unterlagen auch dann, wenn die Übernahme korrigiert werden muss.
Sperrt ein fehlgeschlagener Quality-Check automatisch die Lieferung?
Das lässt sich aus der verwendeten Pass-Fail-Anleitung nicht allgemein zusagen. Sie beschreibt Checks und einen möglichen Quality Alert, keine universelle Sperre sämtlicher Vorgänge. Prüfen Sie den tatsächlich konfigurierten Folgeprozess einschließlich alternativer Bedienwege und Integrationen. Entscheidend ist, ob das definierte Kontrollkonzept eine unzulässige Verwendung wirksam verhindert oder rechtzeitig beherrscht.
Warum braucht eine JSON-2-Integration einen Abbruchtest?
Weil mehrere Aufrufe getrennte Transaktionen bilden. Ein früher Aufruf kann erfolgreich gespeichert sein, während ein späterer scheitert. Prüfen Sie an einer geeigneten Unterbrechungsstelle den verbleibenden Zustand und die Wiederaufnahme. Die erwartete Behandlung muss zur fachlichen Operation passen. Eine allgemeine Erfolgsmeldung des Connectors ersetzt weder den Abgleich der Buchung noch den Nachweis, dass eine Wiederholung keine doppelte Menge erzeugt.
Ist ein Integrationsbenutzer gleichzeitig ein ausreichender Audit Trail?
Nein. Ein eigener Benutzer hilft bei der Zuordnung technischer Zugriffe, belegt aber nicht automatisch frühere Feldwerte, Änderungsgründe oder die vorgelagerte Entscheidung. Prüfen Sie die tatsächlich gespeicherte Historie der relevanten Objekte. Der Reviewer muss den erforderlichen Zusammenhang rekonstruieren können. Fehlende Informationen sind hinsichtlich ihrer Bedeutung zu bewerten und durch ein geeignetes Gesamtkonzept zu behandeln.
Können wir Online ohne Weiteres nach Odoo.sh übernehmen?
Die Dokumentation nennt Versionsgrenzen: Odoo.sh unterstützt Hauptversionen, nicht beliebige Online-Zwischenversionen. Zusätzlich müssen Module, Datenbank und Dateien zur Zielumgebung passen. Klären Sie deshalb zuerst den tatsächlichen Ausgangsstand und den vorgesehenen Migrationsweg. Prüfen Sie den Übergang kontrolliert einschließlich Rückfall und Datenzuordnung. Ein technisch gelungener Import ist noch keine fachliche Freigabe.
Erfordert jedes Modulupdate eine vollständige Revalidierung?
Nein, der Prüfumfang folgt den Auswirkungen. Ermitteln Sie, welche Anforderungen, Datenwege und Kontrollen durch die Änderung berührt werden. Passende bestehende Belege können weiter nutzbar sein. Für neue oder nicht mehr ausreichend abgedeckte Risiken benötigen Sie ergänzende Nachweise. Dokumentieren Sie auch, warum angrenzende Prozesse unverändert bleiben oder gezielt erneut geprüft werden.
Was sollten QA und IT vor einer Aufwandsschätzung bereitstellen?
Benötigt werden System- und Modulliste, Prozessabgrenzung, verfügbare Lieferantenbelege, Rollen und Schnittstellen sowie die vorhandene Bestands- und Loshistorie. Ergänzen Sie bekannte Abweichungen und den verfügbaren Testaufbau. Damit lässt sich unterscheiden, ob hauptsächlich vorhandene Evidenz zugeordnet werden muss oder zunächst ungeklärte Prozesse und Datenbestände zu bereinigen sind. Eine seriöse Schätzung folgt diesen tatsächlichen Aufgaben.
Quellen & fachlicher Stand
Stand 6. Oktober 2026. Herstellerbezug: Odoo-Dokumentation 20.0 und öffentliche Hostingübersicht. App-, Lizenz- und Kundenkonfigurationen sind gesondert zu bestätigen. Die regulatorische Einordnung betrifft Humanarzneimittel-GMP; andere Geltungsbereiche werden nicht pauschal übertragen. Tabellen und Sollwerte sind eigene illustrative Arbeitshilfen, keine ausgeführten Produkt- oder Kundentests.
- Odoo Hosting Types
- Create a project — Odoo 20.0 documentation
- Reassign lot/serial numbers — Odoo 20.0 documentation
- Pass - Fail quality check — Odoo 20.0 documentation
- External JSON-2 API — Odoo 20.0 documentation
- Europäische Kommission: EudraLex Volume 4
- EU-GMP Annex 11: Computerised Systems
- EU-GMP Kapitel 4: Dokumentation
- EMA: ICH Q9(R1), Step 5, Corr.2
- EU-GMP Annex 16: Certification by a Qualified Person and Batch Release
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Die entscheidenden Odoo-Datenwege gezielt prüfen
Wir unterstützen Sie dabei, den regulierten Umfang abzugrenzen, vorhandene Belege zu bewerten und passende Tests für Loszuordnung, Qualitätsentscheidungen und Schnittstellen auszuarbeiten.
- IT-GxP-Audit →
Vorhandene Nachweise und entscheidungsrelevante Lücken im tatsächlichen Odoo-Prozess bewerten.
- IT-GxP-Consulting →
Anforderungen, Prüfbeispiele und kontrollierte Änderungen gemeinsam umsetzen.