Compliance-Software: Funktionen prüfen, Lösungen vergleichen

Den benötigten Funktionsumfang abgrenzen

Der erste Auswahlentscheid betrifft den Auftrag an die Software. Soll sie Änderungen einschlägiger Vorschriften zugänglich machen? Soll sie die Umsetzung interner Vorgaben koordinieren? Oder soll sie bei einer konkreten Handlung prüfen, ob deren Voraussetzungen erfüllt sind? Diese Aufgaben hängen zusammen, benötigen aber unterschiedliche Funktionen und Daten.

Ein Compliance-Managementsystem umfasst zudem mehr als seine technische Unterstützung. ISO 37301 behandelt den Aufbau, die Umsetzung, Bewertung und Weiterentwicklung eines solchen Managementsystems innerhalb einer Organisation. Der Kauf einer Anwendung ist damit nicht gleichzusetzen. ^[1]

Für die Beschaffung ist eine kurze Beschreibung des betrieblichen Problems hilfreicher als „Wir brauchen mehr Compliance“. Beispielsweise: Ein Hersteller möchte verhindern, dass Material verwendet wird, solange eine festgelegte Prüfung noch offen ist. Er benötigt eine Verbindung zwischen Materialidentität, Prüfergebnis und zulässiger Verwendung. Ein anderer Betrieb möchte zunächst seine standortbezogenen Verpflichtungen erfassen und Verantwortliche benennen. Hier liegt der Schwerpunkt auf der Organisation dieser Verpflichtungen.

Die Ausgangslage sollte gemeinsam mit den Menschen beschrieben werden, die den Ablauf ausführen, fachlich verantworten und technisch betreuen. Dabei gehört auch auf den Tisch, was bereits zuverlässig funktioniert. Ein bestehendes System muss nicht ersetzt werden, wenn die fehlende Funktion sinnvoll ergänzt werden kann.

Bevor ein Betrieb Software auswählt, muss er festlegen, welchen Ablauf in der Produktion er zuerst digitalisieren will. Ob ein Fall geeignet ist, ist dabei von seiner Priorität zu trennen: Häufigkeit, Fehlerfolgen und verfügbare Informationen bestimmen mit, wo sich der Einstieg lohnt.

Der Leitfaden des US-Justizministeriums zur Bewertung betrieblicher Compliance-Programme unterscheidet zwischen Konzeption, ausreichenden Ressourcen und Wirksamkeit in der Praxis. Er bewertet im US-Strafverfolgungskontext das Programm des Unternehmens, keine Softwarezertifizierung. Für die Softwareauswahl lässt sich daraus eine Prüffrage ableiten: Lassen sich die vorgesehenen Kontrollen im tatsächlichen Ablauf nachweisen? ^[2]

Compliance-Tools unterscheiden sich nach ihrem Einsatzzweck

Unter der Bezeichnung Compliance-Management-Software werden Lösungen mit unterschiedlichen Schwerpunkten angeboten. Für eine erste Vorauswahl hilft die folgende Einordnung. Sie zeigt, welche Aufgaben verschiedene Compliance-Tools übernehmen können; einzelne Produkte können mehrere Aufgaben verbinden.

Für chargenbezogene Fertigungsprozesse ist ein Electronic Batch Record System ein konkreter Systemtyp: Entscheidend ist, ob je Charge ein vollständiger Ausführungsrecord mit Review und Freigabe entsteht.

Die unterschiedlichen Schwerpunkte lassen sich auch in Herstellerbeschreibungen erkennen: Dort werden beispielsweise Rechtskataster, die Verwaltung von Genehmigungen und die Organisation von Prüfungen beschrieben. Andere Angebote verbinden konfigurierbare Workflows mit Aufgaben, Formularen und Freigaben. Solche Angaben helfen, den angebotenen Umfang einzuordnen. Ob die Funktionen im eigenen Betrieb geeignet sind, bleibt durch konkrete Nachweise zu prüfen.

Eine passende Lösung darf dabei einen begrenzten Auftrag haben. Wenn die Bewertung rechtlicher Änderungen bereits anderweitig erfolgt, kann eine Anwendung zur betrieblichen Umsetzung die richtige Ergänzung sein. Soll beides zusammengeführt werden, müssen Anbieter zeigen, wie eine geänderte Anforderung tatsächlich in den betroffenen Abläufen ankommt.

Von betrieblichen Anforderungen zu prüfbaren Auswahlkriterien

Für regulierte Märkte beginnt eine belastbare Vorauswahl mit dem konkreten Produkt, der Tätigkeit, dem Standort und dem vorgesehenen Einsatz. Die Bezeichnung „für regulierte Branchen“ beantwortet noch nicht, welche fachlichen Regeln und Nachweise eine angebotene Konfiguration abdeckt.

Bei Arzneimitteln, Cannabis, Betäubungsmitteln und anderen kontrollierten Stoffen sind die jeweilige Produkt- und Tätigkeitskonstellation gesondert zu bestimmen. Dasselbe gilt für Tabak, Kosmetik, Lebensmittel und Futtermittel sowie für Biozide und Pflanzenschutzmittel. Ähnliche betriebliche Abläufe begründen keinen gemeinsamen Satz rechtlicher Anforderungen. Auch innerhalb eines Marktes können Herstellung, Lagerung und Abgabe unterschiedliche Auswahlfragen auslösen.

Die Anforderungsliste sollte deshalb beschreiben, was im eigenen Betrieb beobachtbar funktionieren muss. Als redaktionelles Beispiel dient hier ein Hersteller, der eingehendes Material erst nach einer intern festgelegten Prüfung zur Verarbeitung zulassen will. Daraus lässt sich eine kleine Auswahlmatrix ableiten:

Diese Einstufung ist keine allgemeine Rangfolge. Für einen anderen Betrieb kann die Anbindung an das Bestandssystem das wichtigste Ausschlusskriterium sein. Funktionen sollten deshalb vor der Anbieterdemo nach ihrer Bedeutung für den konkreten Einsatz eingeordnet werden.

Zu jedem Muss-Kriterium gehören eine verantwortliche Person und eine vereinbarte Form des Nachweises. Die Aussage „wird unterstützt“ bleibt unvollständig, solange nicht klar ist, ob die Funktion unmittelbar verfügbar ist, eingerichtet werden muss oder erst entwickelt werden soll.

Für computergestützte Systeme bei GMP-Tätigkeiten konkretisiert Annex 11 der Europäischen Kommission (Fassung 2011) die Anforderungsbeschreibung: Benötigte Funktionen sollen risikobasiert festgelegt und über den Lebenszyklus nachvollziehbar bleiben. Auch Lieferantenbewertung und geeignete Testszenarien werden angesprochen. Das ist ein branchenspezifischer Bezug für Auswahlkriterien, keine allgemeine Vorgabe für sämtliche hier genannten Märkte. ^[3]

MHRA Abschnitt 6.19 verdeutlicht für GMP-Systeme, dass die Validierung für den vorgesehenen Zweck ein Verständnis der Systemfunktion im Prozess voraussetzt. Lieferantentests dürfen nicht losgelöst von Konfiguration, beabsichtigter Nutzung und der IT-Umgebung des Anwenders übernommen werden.^[5] Für die Auswahl sollten Anbieter deshalb erklären, welche Nachweise die geplante M-62-Konfiguration abdecken und welche Prüfungen im eigenen Betrieb verbleiben. Eine allgemeine Aussage „validiert“ beantwortet diese Frage nicht.

PIC/S bezieht Datenmanagement und Datenintegrität im GMP/GDP-Umfeld bereits auf die Beschaffung. Die Anforderungen sollen in den Spezifikationen stehen; der Umfang der Validierung von Datenintegritätskontrollen richtet sich nach der Kritikalität von System und Prozess sowie dem Risiko für die Produktqualität. Ergänzend zur Validierung sind administrative und physische Kontrollen sowie Anwenderschulung erforderlich.^[6] Für den Vergleich heißt das, kritische Kontrollen, verbleibende Prüfungen und Beiträge von Anbieter und Betrieb vor dem Kostenvergleich festzuhalten. Daraus folgt kein identisches Prüfprogramm für alle hier angesprochenen Märkte.

Den Arbeitsvorgang über die Eingabemaske hinaus abbilden

Eine Eingabemaske ist zunächst eine Oberfläche. Sie kann Daten sammeln, einen geregelten Ablauf auslösen oder Teil einer eng mit dem Betrieb verbundenen Anwendung sein. Ihr Aussehen sagt wenig darüber aus, was die Software nach dem Speichern bewirkt.

Für automatisierte Compliance-Nachweise muss die Software erfasste Ergebnisse mit der ausgeführten Tätigkeit und dem betroffenen Gegenstand verbinden. Fehlt dieser Zusammenhang, müssen die Beteiligten ihn später für die Prüfung manuell rekonstruieren.

Für den Vergleich ist daher zu prüfen, welche Verbindung zwischen der erfassten Angabe und der betroffenen Arbeit besteht:

Diese Gegenüberstellung beschreibt Prüffragen und keine Rangliste von Softwareklassen. Für eine reine Erhebung kann die strukturierte Eingabe vollkommen ausreichen. Soll die Anwendung jedoch die Verwendung eines gesperrten Materials begrenzen, muss sie die dafür maßgebliche Handlung erreichen. Eine sichtbare Meldung allein ist dafür kein Nachweis.

Bei Freigaben hilft die fachliche Trennung zwischen bearbeitetem Dokument und erlaubter Verwendung. Ein Approval Workflow macht diese Entscheidungsbezüge im Prozess sichtbar. Für die Softwareauswahl genügt es nicht, dass irgendwo ein Freigabefeld existiert: Der Anbieter sollte dessen konkrete Wirkung im vereinbarten Ablauf vorführen.

Ein realer Betriebsfall als Test für die Produktdemo

Eine Präsentation zeigt häufig den vorgesehenen Normalablauf. Für die Auswahl sollten alle Anbieter zusätzlich denselben, vom Unternehmen vorbereiteten Fall bearbeiten. So lassen sich Unterschiede an einem gemeinsamen Gegenstand beurteilen.

Im illustrativen Beispiel trifft Materiallos M-62 ein. Es ist erfasst, aber noch nicht zur Verwendung zugelassen. Ein Dokument D-62 liegt vor; die zuständige Prüfung fehlt. Der Betrieb möchte anschließend 12,5 Kilogramm für Produktionsauftrag P-84 bereitstellen. Diese Angaben bilden ein frei gewähltes Testszenario, keine branchenspezifische Freigabevorschrift.

Die Vorführung umfasst vier Schritte:

1. Den ungeklärten Zustand prüfen. Eine ausführende Person versucht, das Material bereitzustellen. Der Anbieter zeigt, ob der Vorgang zurückgewiesen wird, nur eine Warnung erscheint oder eine begründete Ausnahme vorgesehen ist. Das Ergebnis wird mit der zuvor formulierten Anforderung verglichen.
2. Den fachlichen Vorgang bearbeiten. Die zuständige Person prüft die vorliegenden Informationen. Die Demo muss erkennen lassen, welchen Bearbeitungsstand sie bewertet und ob ihre Entscheidung die vorgesehene Materialverwendung tatsächlich ermöglicht.
3. Den Systemübergang beobachten. Falls ein Bestandssystem angebunden werden soll, wird die Übertragung gezielt unterbrochen. Welche Seite zeigt welchen Status? Wer erkennt den Fehler? Wie wird verhindert, dass eine Wiederholung dieselbe Bereitstellung mehrfach ausführt?
4. Den Fall an eine unbeteiligte Person übergeben. Sie erhält die vorgesehene Ansicht oder einen Export und soll erkennen können, welches Material betroffen war, was entschieden wurde und ob die Bereitstellung erfolgreich war. Fehlender Kontext wird als Prüfbefund festgehalten.

Die Aussagekraft liegt nicht in einer fehlerfreien Inszenierung. Sie liegt darin, dass Anforderungen, beobachtete Ergebnisse und offene Punkte dokumentiert werden. Eine zugesagte Anpassung zählt dabei nicht als bereits bestandener Test. Aus einer erfolgreichen Demo folgt außerdem noch keine vollständige Abnahme des späteren Systems.

Im Auswahlfall ist außerdem zu prüfen, ob die rollenbasierte Prozesssteuerung eine unzulässige Handlung tatsächlich verhindert. Im Audit Trail müssen relevante Änderungen und ihre Prüfung nachvollziehbar bleiben. Eine angezeigte Rolle oder eine bloße Liste von Zeitstempeln belegt diese Wirkungen noch nicht.

Bedienung dort erproben, wo die Arbeit stattfindet

Zum Auswahlfall gehört der tatsächliche Arbeitsplatz. Handschuhe, Umgebungsgeräusche, wechselnde Geräte und die verfügbare Verbindung können darüber entscheiden, ob eine Bedienung im Alltag funktioniert. Eine gut lesbare Desktopansicht beantwortet diese Fragen noch nicht.

Smartglasses können Arbeitshinweise im Sichtfeld bereitstellen. Anbieter beschreiben den Einsatz von Datenbrillen für Anweisungen sowie für die Dokumentation von Inspektions- und Wartungsaufgaben. Das ist eine am Markt angebotene Bedienform, kein Nachweis ihrer Eignung für jeden Arbeitsplatz.

Als weitere Integrationsmöglichkeit lässt sich Spracheingabe im eigenen Auswahlfall prüfen: Eine Person spricht etwa eine Beobachtung ein, kontrolliert die erkannte Eingabe und ordnet sie dem geöffneten Vorgang zu. Für Sprachsteuerung ist zusätzlich festzulegen, welche Aktionen ein Befehl auslösen darf und wann eine bewusste Bestätigung erforderlich ist. Zu prüfen sind auch Fehlerkennung, gemeinsam genutzte Geräte, Rückmeldung und ein alternativer Bedienweg.

Diese Möglichkeiten sind sinnvoll, wenn sie den Arbeitsablauf erleichtern und den Bezug zum Vorgang erhalten. Werden darüber digitale Arbeitsanweisungen bereitgestellt, muss die zur Tätigkeit passende Fassung am Arbeitsplatz erreichbar und nutzbar sein. Bei der Vorführung ist deshalb zu prüfen, ob der vorgesehene Zugang unter den tatsächlichen Arbeitsbedingungen zuverlässig funktioniert.

Einführung, laufender Betrieb und Folgekosten

Der Vergleichspreis sollte sich auf denselben Leistungsumfang und einen gemeinsam festgelegten Nutzungszeitraum beziehen. Neben der Lizenz gehören Einrichtung, Datenübernahme, Schnittstellen, Endgeräte, Schulung, Support und spätere Änderungen in die Betrachtung. Auch der Aufwand der eigenen Mitarbeiter zählt.

Besonders aufschlussreich ist die Frage, wer nach dem Start eine betriebliche Änderung umsetzt. Kann eine fachlich zuständige Person eine Anpassung innerhalb des vorgesehenen Konfigurationsrahmens vorbereiten? Muss der Anbieter tätig werden? Wie wird die Änderung geprüft, bevor sie den laufenden Betrieb erreicht? Ein geringer Einstiegspreis sagt darüber wenig aus.

Für jeden Anbieter sollten mindestens folgende Punkte schriftlich vergleichbar sein:

• Leistungsumfang: Welche Anforderungen sind im Angebot enthalten, welche optional und welche noch offen?
• Einführung: Welche Arbeiten und Daten muss der Kunde bereitstellen, und wer übernimmt Einrichtung und Prüfung?
• Betrieb: Wer betreut Zugänge, Aktualisierungen, Sicherungen und Störungen? Welche Leistungen sind vereinbart?
• Erweiterung und Ausstieg: Was kosten zusätzliche Standorte oder Nutzer, und wie werden Daten samt benötigtem Zusammenhang herausgegeben?

Beim letzten Punkt reicht ein vorhandener Exportknopf als Auswahlbeleg nicht aus. Der Export muss für den vorgesehenen Zweck nutzbar sein; dabei ist Datenintegrität für die Verlässlichkeit der ausgegebenen Informationen entscheidend. Der Aufwand für eine gegebenenfalls erforderliche Validierung oder andere formale Nachweise ist anhand des konkreten Einsatzes gesondert einzuplanen.

Eine pauschale Antwort auf die Frage nach der besten Lösung für den Mittelstand wäre deshalb wenig hilfreich. Maßgeblich sind neben den Muss-Kriterien auch die verfügbaren Menschen und Fähigkeiten: Wer kann die Anwendung einführen, betreuen und bei Veränderungen fachlich beurteilen?

Bei der anschließenden Einführung von Workflow-Software werden Datenübergaben, Ersatzbetrieb und betriebliche Übergabe zunächst im Pilotumfang erprobt. Die Auswahl muss deshalb auch erkennen lassen, welche Voraussetzungen der Betrieb dafür noch schaffen muss.

Aufsichtsbefund

Befund: Die FDA beanstandete bei einem Arzneimittelhersteller, dass Administratorrechte zum Ändern und Löschen von Dateien im Labordatensystem nicht angemessen kontrolliert waren.^[4]

Einordnung: Für die Softwareauswahl folgt daraus eine konkrete Prüfaufgabe: Berechtigungen sind in der vorgesehenen Konfiguration zu testen. Eine Rollenbeschreibung oder eine Liste verfügbarer Sicherheitsfunktionen zeigt noch nicht, welche Handlungen ein bestimmter Zugang tatsächlich erlaubt. Der Befund betrifft die Arzneimittel-CGMP; daraus folgt keine pauschale Vorgabe für alle hier angesprochenen Märkte.

Prüffrage: Kann der Anbieter mit einem Testzugang vorführen, dass unzulässige Änderungen und Löschungen in der vereinbarten Konfiguration verhindert werden?

Schreiben vom 22.08.2025 · Quelle geprüft am 18.09.2026.

Dargestellt ist der ausgewählte Behördenbefund zum Zeitpunkt des Schreibens. Unternehmensantworten und spätere Entwicklungen werden hier nicht bewertet; die Darstellung beschreibt keinen aktuellen Compliance-Status.