Warenwirtschaft mit Add-ons vs. Compliance by Design

Wer im pharmazeutischen Großhandel, in der Medizinprodukte-Distribution oder im Cannabis-Vertrieb eine Software-Entscheidung trifft, steht meistens vor derselben Architekturfrage — auch wenn sie selten so benannt wird. Sie lautet: Nehme ich eine etablierte generische Warenwirtschaft und ergänze sie mit Modulen für die regulatorischen Anforderungen? Oder wähle ich eine Plattform, die diese Anforderungen von Anfang an im Datenmodell trägt?

Beide Wege funktionieren. Beide werden täglich erfolgreich gegangen. Aber sie verhalten sich unter der Oberfläche unterschiedlich — im Aufbau, in der Wartung und vor allem im Audit. Dieser Artikel benennt, wo die Unterschiede liegen, ohne den einen oder anderen Weg pauschal abzuwerten.

Was beide Ansätze versprechen

Eine generische Warenwirtschaft mit GDP-, MDR- oder securPharm-Modulen klingt nach dem pragmatischen Mittelweg: bewährte Basis, ergänzt um die regulatorischen Teile, die man braucht. Implementierungspartner sind verfügbar, die Standardprozesse für Einkauf und Buchhaltung sind erprobt, und die Module schließen genau die Lücken, die das Basissystem offenlässt.

Eine Compliance-by-Design-Plattform geht den umgekehrten Weg: Sie ist von vornherein für die regulierten Prozesse entwickelt, und die kaufmännischen Funktionen sind in derselben Datenbasis verankert. Quarantäne ist kein Modul, sondern ein Bestandsstatus. Der Audit-Trail ist kein Add-on, sondern Teil des Datenmodells. securPharm ist nicht angebunden, sondern integriert.

Auf der Ebene der Funktionslisten sehen beide Ansätze oft identisch aus. Der Unterschied beginnt unter der Oberfläche — und genau dort, wo ein generisches System eine GDP-Warenwirtschaft wird oder eben nicht.

Die fünf Nahtstellen

Wer regulierte Aufstellungen langfristig betreibt, kennt die fünf Punkte, an denen die Add-on-Architektur typischerweise unter Last gerät. Sie sind selten ein Showstopper im ersten Jahr. Sie werden zum Thema, sobald das System gelebt wird.

1. Der Audit-Trail an Modul-Grenzen

EU-GMP Annex 11 verlangt einen lückenlosen Audit-Trail — jede Aktion mit Nutzer, Zeitstempel, Wert vor und nach der Änderung, unveränderlich, für die geforderte Aufbewahrungsfrist lesbar. In einer Compliance-by-Design-Plattform ist das ein einziges Log. In einer Add-on-Architektur sind es typischerweise vier oder fünf: das Basissystem, das Lagermodul, das securPharm-Modul, das Buchhaltungsmodul, gegebenenfalls ein separates Dokumentenmanagement.

Im Tagesgeschäft ist das kein Problem. Im Audit wird es zum zentralen Punkt. Ein Inspektor fragt nicht „Zeigen Sie mir den Audit-Trail Ihres securPharm-Moduls", sondern „Zeigen Sie mir die vollständige Spur einer bestimmten Charge vom Wareneingang bis zur letzten Auslagerung." Diese Spur muss über alle Module hinweg konsistent, zeitgleich aufgelöst und nicht editierbar zusammensetzbar sein. Wenn schon die Zeitstempel der Module um Sekunden auseinanderlaufen, beginnt die unangenehme Diskussion. Ein fehlender oder brüchiger Audit-Trail gehört zu den häufigsten Beanstandungen einer GDP-Inspektion, und die Annex-11-Revision rückt diese Erwartung weiter nach vorn.

2. Validierung als Multiplikator

GAMP 5 fordert eine risikobasierte Computer-System-Validierung. Bei einer monolithischen Plattform ist das eine Validierungsanstrengung, mit einem Lieferanten-Dossier, einem Test-Skript, einer IQ/OQ/PQ-Dokumentation. Bei einer Add-on-Architektur ist es eine pro Modul, plus die Validierung der Schnittstellen zwischen den Modulen.

Diese Multiplikation ist nicht nur initial spürbar. Sie wiederholt sich bei jedem Update. Bekommt das Basissystem ein Major-Release und müssen drei Module dafür nachgezogen werden, ist das nicht ein Validierungs-Vorgang, sondern eine Validierungs-Kette. Wer das ernsthaft macht, bindet schnell einen erheblichen jährlichen Aufwand allein für die Erhaltung des Validierungs-Zustands. Wer es nicht ernsthaft macht, riskiert ein Finding bei der nächsten Inspektion. Dass eine risikobasierte Validierung auch für KMU wirtschaftlich darstellbar bleibt, hängt wesentlich an dieser Architekturfrage.

3. Das Datenmodell-Problem bei Quarantäne

Das ist der unauffälligste, aber technisch wichtigste Punkt. In einem generischen System gibt es typischerweise „Bestand" mit einem Lagerort und einer Menge. Quarantäne wird über ein zusätzliches Feld oder eine separate Lagerzone abgebildet. Das funktioniert — aber jede Operation, die mit Bestand arbeitet (Kommissionierung, Inventur, Verfügbarkeitsprüfung), muss das zusätzliche Feld korrekt berücksichtigen. In der Praxis tut sie das nicht immer.

Wir haben in mehreren Aufstellungen gesehen, dass eine Charge in Quarantäne stand und gleichzeitig in der Verfügbarkeitsprüfung des Verkaufs auftauchte, weil zwei Komponenten den Status unterschiedlich interpretierten. Das ist kein Programmierfehler. Es ist die Konsequenz daraus, dass Quarantäne nachträglich in der DNA des Systems verankert wurde.

In einer Compliance-by-Design-Plattform ist Quarantäne ein primärer Bestandsstatus auf Datenmodell-Ebene. Jede Komponente, die auf Bestand zugreift, sieht denselben Status. Eine versehentliche Auslagerung aus Quarantäne ist nicht eine Frage der korrekten Konfiguration — sie ist technisch nicht möglich. Im durchgängig scan-geführten Wareneingang zeigt sich dieser Unterschied am deutlichsten.

4. Verantwortung im Fehlerfall

Läuft in einer Add-on-Architektur etwas schief — ein securPharm-Alarm wird nicht korrekt eskaliert, eine Charge trotz Sperre versendet, ein Audit-Trail-Eintrag fehlt — beginnt eine Diskussion zwischen den Beteiligten: Basissystem-Anbieter, Modul-Anbieter, Schnittstellen-Dienstleister, hausinterne IT. Jeder hat Argumente. Die Inspektion interessiert sich für keines davon. Sie sieht das Finding bei Ihnen.

Bei einer einzigen Plattform liegt die Verantwortung bei einem Anbieter. Das ist nicht nur kommunikativ einfacher, es ist regulatorisch sauberer. Die GDP-Leitlinie fordert, dass ausgelagerte Tätigkeiten unter einem qualifizierten und überwachten Vertragsverhältnis stehen. Drei Software-Verträge mit drei unterschiedlichen Service-Zusagen und drei unterschiedlichen Validierungs-Zuständen sind eine schwer zu verteidigende Position.

5. Die Geschwindigkeit regulatorischer Anforderungen

Die E-Rechnung wird gestaffelt verpflichtend. Die Anforderungen an die UDI-Verwaltung für Medizinprodukte-Distributoren verschärfen sich. Der Cannabis-Großhandel ist ein junger regulatorischer Raum mit absehbaren Anpassungen. Re-Importeure stehen unter wachsendem Druck im EMVO-Upload-Bereich.

Eine Compliance-by-Design-Plattform aktualisiert die regulatorische Logik im selben Release-Zyklus wie ihre operativen Funktionen. Eine Add-on-Architektur ist auf die Synchronisation zwischen Modulanbietern angewiesen, die unterschiedliche Roadmaps verfolgen. Wer schon einmal darauf gewartet hat, dass das ZUGFeRD-Update des Buchhaltungsmoduls mit dem Stammdaten-Modell des Basissystems wieder kompatibel ist, kennt die Mechanik.

Wann Add-ons trotzdem die richtige Wahl sind

Es wäre unredlich, die Add-on-Architektur pauschal zu disqualifizieren. Es gibt Konstellationen, in denen sie überlegen ist.

Wer auf einer bestehenden, operativ ausgereiften Investition aufsetzt, die über unternehmensweite Standards getragen wird, hat einen anderen Ausgangspunkt als ein Greenfield-Aufbau. Wer in einem Konzern mit vielen Tochtergesellschaften nur eine einzige Sparte regulierter Distribution betreibt, kann den Modul-Weg sinnvoll wählen. Und wer hochspezifische Nischen-Anforderungen hat, für die kein Standard existiert, wird ohnehin mit Spezial-Software arbeiten.

Die ehrliche Faustregel: Je größer der Anteil der regulierten Tätigkeit am Gesamtgeschäft, je kleiner das Unternehmen und je näher die nächste Inspektion, desto deutlicher kippt die Rechnung zugunsten von Compliance by Design. Im pharmazeutischen Großhandel des KMU-Segments, in der Medizinprodukte-Distribution, im Cannabis-Vertrieb und im Re-Import liegt die Schwelle aus unserer Erfahrung niedriger, als die meisten Anbieter zugeben.

Was die Entscheidung praktisch leichter macht

Wer vor der Wahl steht, kann sich an vier Fragen orientieren, die nicht das Marketing klären kann, sondern nur die eigene Architektur.

Erstens: Wie viele Module müssen für eine vollständige Audit-Spur einer Charge zusammen abgefragt werden? Ist es mehr als eines, ist die Add-on-Architektur eine implizite Entscheidung.

Zweitens: Wer trägt die Validierungs-Verantwortung für die Schnittstellen? Lautet die Antwort „wir intern", ist das eine kalkulierbare, aber substanzielle Kostenposition.

Drittens: Wie lange braucht das System, um eine Frage zu beantworten, die quer durch Wareneingang, Quarantäne, Kommissionierung und Versand geht — so, wie ein Prüfer sie in einer Behördeninspektion stellt? Lautet die Antwort „länger als zehn Minuten", ist die Architektur das Problem, nicht die Mitarbeiter.

Viertens: Wer entscheidet im Konfliktfall, ob ein Software-Verhalten regulatorisch akzeptabel ist? Lautet die Antwort „drei Anbieter, die sich abstimmen müssen", ist die Position im Audit schwierig.

Fazit

Compliance by Design ist kein Marketing-Begriff. Es ist eine Architektur-Entscheidung, die im Datenmodell beginnt und sich durch Validierung, Audit-Trail und Verantwortlichkeit zieht. Add-ons sind ein legitimer Weg, aber sie haben ihren Preis, der oft erst im dritten oder vierten Jahr sichtbar wird — und am unangenehmsten am Tag der Inspektion.

Die Frage ist nicht, welcher Weg „besser" ist. Die Frage ist, welcher Weg zu Ihrem Geschäft, Ihrer Risikolage und Ihrer regulatorischen Realität passt — und ob Sie diese Frage einmal ehrlich gestellt haben, bevor ein Inspektor sie für Sie stellt.