„Inspektionsbereit ab Tag eins“: Was dieser Anspruch operativ wirklich bedeutet

Der Satz ist im pharmazeutischen Software-Markt verbreitet. Fast jede Warenwirtschaft, jedes ERP-Modul, jede Branchenlösung wirbt mit GDP-Konformität, mit Inspektionsfähigkeit, mit Compliance ab Tag eins. Die Realität in vielen pharmazeutischen Mittelständlern sieht anders aus: Zwischen Vertragsabschluss und der ersten Inspektion liegen sechs bis zwölf Monate Validierung, Customizing, Schulung, SOP-Anpassung, Excel-Migration, IT-Projekt — und am Ende dieser Strecke ist das System nicht „inspektionsbereit", sondern „theoretisch geeignet, wenn alles funktioniert hat".

Dieser Beitrag zerlegt, was der Anspruch „Inspektionsbereit ab Tag eins" tatsächlich bedeutet, wenn man ihn ernst meint. Er benennt die sechs Eigenschaften, die ein Warenwirtschaftssystem ab der ersten produktiven Nutzung tragen muss, die typischen Lücken zwischen Versprechen und Realität, und die strukturellen Voraussetzungen, ohne die der Anspruch ein Marketing-Slogan bleibt.

Was „Tag eins" konkret heißt

„Tag eins" ist nicht der Tag der Vertragsunterzeichnung. Er ist der Tag, an dem im System die erste reale GDP-relevante Buchung erfolgt — ein Wareneingang einer realen Lieferung, einer realen Charge, eines realen Lieferanten, an einem realen Lagerort. Dieser Tag ist der frühestmögliche Termin, an dem eine anlassbezogene Inspektion erscheinen könnte. Eine Behörde hat keine Geduld für Validierungsfristen oder Schulungsphasen. Wenn ein securPharm-Verdacht vorliegt, wenn ein Lieferant Auffälligkeiten produziert hat, wenn ein Mitbewerber-Finding den Aufsichtsfokus auf eure Branche gerichtet hat — dann steht die Inspektion am Tag drei nach Echtbetrieb. Nicht am Tag 90+.

Inspektionsbereit ab Tag eins bedeutet damit: Ab dem Moment, in dem das System produktiv die ersten Daten führt, müssen sechs Eigenschaften belastbar sein. Nicht im Roadmap-Punkt, nicht in der Konfigurations-Anleitung, nicht in der nächsten Validierungsphase — sondern hier und jetzt, sichtbar, auditierbar, im Datenmodell verankert.

Die sechs Eigenschaften, die ab Tag eins tragen müssen

Die folgenden sechs Punkte sind nicht aus einer Checkliste abgeleitet. Sie sind die Punkte, an denen Inspektionen in den ersten zwölf Monaten nach Echtbetrieb regelmäßig hängen bleiben.

1. Quarantäne als realer Bestandsstatus, nicht als Aufkleber

Quarantäne darf am Tag eins kein organisatorisches Konstrukt sein. Sie muss ein primärer Bestandsstatus im Datenmodell sein. Jede Bestandsoperation — Verfügbarkeitsprüfung, Kommissionierung, Inventur, Reservierung — sieht den Status nativ. Eine Auslagerung aus Quarantäne ist nicht eine Frage der Disziplin oder der korrekten Konfiguration, sondern technisch ausgeschlossen. Die Freigabe-Entscheidung der Verantwortlichen Person ist eine signierte Handlung mit Zeitstempel, Nutzer und Wert vor und nach der Entscheidung. Wie sich dieser Unterschied im scan-geführten Wareneingang zeigt, ist am ersten Tag des Echtbetriebs sofort sichtbar.

Was die Inspektion am Tag eins prüft: „Zeigen Sie mir bitte den Bestand, den Sie heute Morgen vereinnahmt, aber noch nicht freigegeben haben." Wer auf diese Frage drei Sekunden braucht statt drei Minuten, hat den Punkt geliefert.

2. Ein einziger, vollständiger Audit-Trail

EU-GMP Annex 11 verlangt einen lückenlosen Audit-Trail. Am Tag eins muss dieser Audit-Trail nicht aus drei Modulen zusammengeführt werden, sondern aus einer Quelle abrufbar sein — mit Nutzer, Zeitstempel, Wert vor und nach der Änderung, unveränderlich, exportierbar, über die gesamte Aufbewahrungsfrist lesbar. Wenn das System Audit-Logs schreibt, die nur über die IT extrahiert werden können oder zwischen Komponenten zeitlich auseinanderlaufen, ist das eine strukturelle Schwäche, die am Tag eins nicht mehr zu reparieren ist. Ein 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.

3. securPharm und MSV3 im System — nicht in Sub-Systemen und Schnittstellen

Verifikation am Übergabepunkt und MSV3-Datenfluss sind keine Add-ons. Sie sind Bestandteil der täglichen Bewegung im pharmazeutischen Großhandel. Am Tag eins muss eine securPharm-Verifikation im System sichtbar sein, ein Alarm im System bewertet werden können, ein MSV3-Vorgang im System dokumentiert sein. Wer am Tag eins parallel ein securPharm-Tool und eine separate MSV3-Bridge betreibt, hat zwei Quellen, zwei Audit-Trails und zwei Verantwortungsbeziehungen — das ist nicht inspektionsbereit, das ist eine Aufstellung mit verteilten Risiken.

4. Temperatur- und Lagerbedingungs-Logik im System

Lagerbedingungs-Logik am Tag eins bedeutet: Im System ist hinterlegt, welche Produkte unter welchen Bedingungen gelagert werden dürfen — und welche Lagerplätze diese Bedingungen erfüllen. Das betrifft nicht nur die Temperatur (Kühlware in die Kühlzone, Raumtemperaturware in die entsprechende Zone, tiefkühlpflichtige Ware in den Tiefkühlbereich), sondern jede Eigenschaft, die die Produktqualität beeinträchtigen kann: lichtempfindliche Ware, die vor Licht geschützt lagern muss, feuchteempfindliche Ware mit Vorgaben an die Luftfeuchte, und weitere produktspezifische Lagerungsvorgaben. Bei jeder Einlagerung prüft das System diese Zuordnung und unterbindet eine Buchung, die die Lagervorgaben des Produkts verletzen würde. Die Einhaltung der Lagerbedingungen ist damit kein organisatorischer Appell an die Mitarbeiter, sondern eine Regel im Datenmodell, die eine falsche Einlagerung gar nicht erst zulässt.

Was die Inspektion am Tag eins prüft: „Was passiert, wenn jemand kühlpflichtige Ware auf einen Raumtemperatur-Platz oder lichtempfindliche Ware auf einen ungeschützten Platz buchen will?" Wer darauf antworten kann „Das System lässt die Buchung nicht zu", hat den Punkt geliefert. Wer antworten muss „Das wäre ein Bedienfehler, der nachträglich auffällt", hat eine organisatorische statt einer technischen Absicherung.

5. Rückruf-Funktion sofort einsatzfähig

Die GDP-Leitlinie verlangt, dass ein Rückrufsystem den verfügbaren Bestand und die Lieferketten innerhalb kurzer Frist erfassen kann. Am Tag eins heißt das: Eine dringende AMK-Schnellinformation zu einer beliebigen Charge wird in unter drei Minuten beantwortet — welche Bestände wo lagern, welche Kunden welche Mengen erhalten haben, welche Vorgänge dokumentiert sind. Diese Funktion muss am ersten Tag testbar sein, nicht erst nach einer „Rückruf-Übung im dritten Quartal". Wer das nicht sofort vorführen kann, hat eine theoretische Compliance ohne operative Belastbarkeit.

6. VP-Workflow signiert, nicht per E-Mail

Die Verantwortliche Person trifft Entscheidungen, die im System dokumentiert sein müssen: Freigabe aus Quarantäne, Bewertung von securPharm-Alarmen, Freigabe von Rückrufen, Bestätigung von Reklamationsbearbeitungen. Am Tag eins müssen diese Entscheidungen als signierte Handlungen im System erfolgen, mit Audit-Trail-Eintrag und ohne Möglichkeit zur nachträglichen Modifikation. Eine VP, die ihre Entscheidungen weiterhin per E-Mail bestätigt, ist regulatorisch nicht eingebunden — sie ist nominell präsent.

Was zwischen Vertragsabschluss und Tag eins passieren muss — und was nicht

Inspektionsbereit ab Tag eins ist kein Versprechen, dass am Tag der Vertragsunterzeichnung alles fertig ist. Es ist ein Versprechen, dass die Strecke zwischen Vertrag und produktiver Nutzung vom Anbieter mitgeliefert wird, nicht in den Kunden ausgelagert.

Was ein Kunde in dieser Strecke nicht selbst tun sollte:

• Die Annex-11-Konformität nachträglich auditieren müssen. Sie ist Voraussetzung der Software, nicht ein Konfigurations-Ergebnis.
• Den Audit-Trail nachträglich aktivieren oder konfigurieren. Er ist Datenmodell, nicht Feature.
• Schnittstellen zu securPharm, EMVS oder MSV3 selbst entwickeln oder bezahlen. Sie sind Standard, nicht Customizing.

Die formale Validierungs-Dokumentation — Lieferanten-Dossier, IQ/OQ-Protokolle, Validierungs-Matrix — lässt sich als optionale Zusatzleistung beziehen, sodass sie nicht aus dem Nichts selbst erstellt werden muss. Weil die regulatorischen Funktionen bereits als native Integrationen im System verankert sind, fällt der Validierungsaufwand ohnehin schlank aus.

Was der Kunde tatsächlich tun muss: die Stammdaten befüllen — das ist eine Sache von etwa einer Stunde —, eigene Lieferanten-Dossiers aufbauen (Lieferantenbeziehungen kann niemand außer dem Kunden bewerten), Mitarbeiter schulen, die Verantwortliche Person formell einbinden und die Räumlichkeiten und Temperaturzonen abnehmen. Diese Tätigkeiten lassen sich in wenigen Tagen erledigen, nicht in Monaten — wenn das System sie nicht zusätzlich erschwert.

Die typischen Lücken zwischen Versprechen und Realität

Ein Warenwirtschaftssystem, das „GDP-konform" auf der Website hat, kann trotzdem die folgenden Lücken aufweisen, die am Tag eins relevant werden:

Validierung verlangt sechs Monate Vorlauf. Wenn die Validierungs-Matrix beim Kunden liegt und jedes Modul einzeln getestet werden muss, ist das System am Tag eins juristisch in einer Grauzone.

Quarantäne ist ein zusätzliches Feld. Wenn der Bestand „verfügbar" und „in Quarantäne" über zwei Felder oder zwei Lagerzonen abgebildet ist, statt als primärer Status, wird die Verfügbarkeitsprüfung das Feld im Tagesgeschäft scheinbar zu 100 % korrekt berücksichtigen — und genau in dem einen Fall nicht, in dem es darauf ankommt.

securPharm läuft in einem separaten Tool. Das funktioniert im Tagesgeschäft. Es bricht am Tag der Inspektion, wenn der Inspektor die Brücke zwischen Verifikations-Ereignis und Vorgang nachvollzogen sehen will.

Lagerbedingungen werden organisatorisch statt technisch abgesichert. Wenn das System nicht prüft, ob ein Produkt überhaupt auf einen Lagerplatz mit dessen Temperatur-, Licht- und Feuchtebedingungen gebucht werden darf, verlässt sich die Einhaltung der Lagerbedingungen auf die Aufmerksamkeit der Mitarbeiter. Eine falsch eingelagerte kühlpflichtige oder lichtempfindliche Charge fällt dann erst auf, wenn jemand sie sucht — oder ein Inspektor danach fragt.

Audit-Trail ist nicht exportierbar. Wenn der Audit-Trail technisch existiert, aber nicht in einem inspektorenfreundlichen Format ausgegeben werden kann, ist er regulatorisch nur bedingt wertvoll.

Validierung der Schnittstellen liegt beim Kunden. Modul-Architekturen verlagern die Validierung der Schnittstellen zwischen Komponenten typischerweise auf den Kunden. Das ist nicht „GDP-konforme Software" — das ist „eine Software, die zusammen mit einer eigenen Validierungs-Anstrengung GDP-konform betrieben werden kann". Wann eine Add-on-Architektur trotzdem die richtige Wahl ist, hängt von der eigenen Aufstellung ab — die Validierungs-Frage gehört in jedem Fall vor die Entscheidung.

Wer einen Anbieter beim Wort nimmt, kann diese Punkte vor der Auswahl prüfen. Wer es nicht tut, lernt sie zwischen Tag eins und Tag zweihundert kennen.

Die strukturelle Voraussetzung: Compliance im Datenmodell

Inspektionsbereit ab Tag eins ist keine Frage der Konfiguration. Es ist eine Frage der Architektur. Wenn die regulatorischen Anforderungen im Datenmodell verankert sind — Quarantäne als Status, Audit-Trail als integraler Bestandteil, securPharm und MSV3 als native Operationen, Lagerbedingungen als erzwungene Buchungsregel — dann ist das System am Tag eins inspektionsbereit, weil es gar nicht anders sein kann. Wenn diese Anforderungen über Module, Add-ons und Schnittstellen ergänzt sind, ist das System am Tag eins so inspektionsbereit, wie die schwächste Schnittstelle es zulässt. Diese Compliance-by-Design-Logik einer GDP-Warenwirtschaft ist der eigentliche Hebel hinter dem Versprechen.

Diese Unterscheidung ist nicht akademisch. Sie wird im Audit operativ relevant. Sie wird im ersten Rückruf operativ relevant. Sie wird bei der ersten Fehleinlagerung in einen falschen Lager- oder Temperaturbereich operativ relevant. Und sie ist am Tag der Vertragsunterzeichnung bereits entschieden — auch wenn die Konsequenzen erst Monate später sichtbar werden.

Eine pragmatische Faustregel für die Auswahl

Wer vor einer Software-Auswahl steht und den Anspruch „Inspektionsbereit ab Tag eins" prüfen will, kann sich an einer einfachen Frage orientieren:

Wie viele Tage liegen typischerweise zwischen Vertragsabschluss und der ersten produktiven GDP-relevanten Buchung beim Kunden?

Wenn die Antwort „mehr als zehn Tage" lautet, hat das System Strecke gewonnen, in der sich nicht der Kunde verändert, sondern erst das System an den Kunden angepasst werden muss. Ein auf Standard-Vollständigkeit ausgelegtes System kommt mit deutlich weniger aus: Das Befüllen der Stammdaten ist eine Sache von etwa einer Stunde, und weil die regulatorischen Funktionen — Quarantäne, Audit-Trail, securPharm, MSV3 — als native Integrationen bereits Teil des Systems sind, bleibt für die Validierung nur ein sehr kurzer Zeitraum. Die Tätigkeit des Kunden geschieht dann in einer Konfiguration, nicht in einer Neuentwicklung.

Das ist keine perfekte Metrik, aber sie ist ehrlich. Sie deckt auf, ob die Compliance des Systems im Lieferumfang liegt — oder im Projektaufwand des Kunden. Dieselbe Frage stellt sich ein Prüfer in der Behördeninspektion sinngemäß, nur rückblickend.

Fazit

„Inspektionsbereit ab Tag eins" ist ein operativer Anspruch, nicht eine Marketing-Aussage. Er bedeutet, dass sechs strukturelle Eigenschaften ab der ersten produktiven Buchung im System belastbar sind: Quarantäne als realer Status, vollständiger Audit-Trail, native securPharm- und MSV3-Integration, temperatur- und lagerbedingungsgeführte Lagerplatz-Logik, sofort einsatzfähiges Rückrufsystem, signierter VP-Workflow.

Wer diesen Anspruch ernst meint, verankert ihn im Datenmodell, nicht in der Konfiguration. Und wer ihn als Kunde prüft, schaut nicht in die Funktionsliste, sondern in die Strecke zwischen Vertragsabschluss und erstem realen Wareneingang. Diese Strecke ist die Wahrheit hinter dem Versprechen.