Inhaltsverzeichnis
Das Wichtigste vorab
Welche Angaben braucht ein aktuelles Systeminventar nach Annex 11?
Annex 11 § 4.3 sieht ein aktuelles Inventar relevanter Systeme und ihrer GMP-Funktionalität vor. Beginnen Sie deshalb beim tatsächlichen Prozess und erfassen Sie identifizierbare Anwendungen, Verantwortlichkeiten und relevante Abhängigkeiten. Verlinken Sie weiterführende Nachweise, statt sie vollständig in die Liste zu kopieren. Welche zusätzlichen Felder und Pflegeauslöser zweckmäßig sind, hängt von Ihrem Bestand ab; eine fest vorgeschriebene Tabellenstruktur enthält die Passage nicht.
- GMP-Funktion und tatsächliche Nutzung machen einen Eintrag verständlich.
- Abhängigkeiten müssen auffindbar sein, ohne jeden Server zur eigenen Anwendung zu erklären.
- Ein Inventar bleibt nur brauchbar, wenn Änderungen einen verantwortlichen Pflegeweg auslösen.
1. Was die Inventaranforderung tatsächlich umfasst
Der hier behandelte Rahmen ist die EU-GMP-Leitlinie für computergestützte Systeme in der Herstellung von Humanarzneimitteln. Am 7. Oktober 2026 führt EudraLex weiterhin Annex 11 Januar 2011. Die Inventaranforderung betrifft relevante Systeme samt GMP-Funktionalität. Der anschließende Satz über eine detaillierte Systembeschreibung ist ausdrücklich auf kritische Systeme bezogen.
Daraus folgt für die praktische Gestaltung: Halten Sie den Einstieg verständlich und ermöglichen Sie den Weg in die Tiefe. Ein Inventar muss weder sämtliche technischen Eigenschaften enthalten noch selbst alle Validierungsentscheidungen begründen. Es sollte aber erkennen lassen, wo diese Entscheidungen liegen und welche ungeklärten Einträge noch bearbeitet werden.
2. Prozesse abgehen statt nur Lizenzen auswerten
Gehen Sie mit dem Fachbereich einen tatsächlichen Ablauf durch: Wo entstehen Daten, wer verarbeitet sie weiter und welches Ergebnis führt zu einer Entscheidung? Fragen Sie dabei nach Dateien, lokalen Rechnern, Geräteprogrammen und manuellen Übergaben. Beschaffung und IT-Verzeichnis liefern nützliche Startinformationen, erfassen aber nicht zwingend jede selbst erstellte Auswertung.
Eine Tabellenmappe kann beispielsweise ein freizugebendes Ergebnis berechnen, obwohl sie nicht als beschaffte Software erscheint. Umgekehrt kann eine große Unternehmensanwendung im betrachteten Bereich nur Terminplanung unterstützen. Die Einordnung braucht den konkreten Einsatz. Ungeklärte Nutzung wird als offen markiert und einer Person zur Klärung zugewiesen; sie verschwindet nicht still aus dem Register.
3. Welche Angaben einen Eintrag handlungsfähig machen
Als eigene Arbeitshilfe empfiehlt sich ein stabiler Schlüssel pro abgegrenztem System. Ergänzen Sie eine verständliche Bezeichnung, Standort oder Nutzungsbereich, GMP-Funktion, verantwortliche Rolle, Betriebszustand und Verweise auf Bewertung und Dokumentation. Bei mehreren getrennt betriebenen Instanzen muss erkennbar bleiben, welche Konfiguration der Eintrag beschreibt.
Nicht jeder zusätzliche Detailwert gehört dauerhaft ins Inventar. Für wechselnde technische Komponenten kann ein gepflegter Verweis auf die IT-Dokumentation besser sein als eine zweite, schnell veraltende Kopie. Entscheidend ist, dass der Verweis tatsächlich zum richtigen Bestand führt und auch bei Umbenennung oder organisatorischem Wechsel erhalten bleibt.
| Angabe | Beispiel | Frage, die damit beantwortet wird |
|---|---|---|
| Systemkennung | SYS-017 / Labor-Auswertung | Welches abgegrenzte System meinen wir? |
| GMP-Funktion | Berechnet den berichteten Wirkstoffgehalt | Welche Qualitätsentscheidung hängt daran? |
| Nutzung und Verantwortung | Labor Standort Nord / Laborleitung | Wer bestätigt den tatsächlichen Einsatz? |
| Abhängigkeiten | Waagenexport, Dateiablage, Identitätsdienst | Welche Änderungen können mitwirken? |
| Nachweisverweis | Bewertung B-017; Beschreibung D-017 | Wo liegen Begründung und Detailstand? |
4. Infrastruktur und Schnittstellen passend zuordnen
Der Grundsatz des Annex 11 unterscheidet validierte Anwendung und qualifizierte IT-Infrastruktur. Für das Register heißt das nicht, dass Sie zwei unverbundene Welten verwalten sollten. Eine Laboranwendung kann vom Verzeichnisdienst für Rechte und von einem Speicherdienst für die Verfügbarkeit ihrer Daten abhängen. Diese Verbindung bleibt relevant, auch wenn beide Dienste mehrere Anwendungen bedienen.
Vermeiden Sie sowohl die pauschale Ausklammerung gemeinsamer Dienste als auch eine unübersichtliche Wiederholung sämtlicher Komponenten in jeder Zeile. Ein referenziertes Abhängigkeitsverzeichnis kann genügen, wenn Richtung und Zweck nachvollziehbar sind. Für Schnittstellen beschreiben Sie zunächst Quelle, Ziel und fachlichen Gegenstand; detaillierte Mappingregeln gehören in die passende System- oder Schnittstellendokumentation.
5. Illustrativer Bestand: drei Anwendungen, verschiedene Nachweisfragen
Das folgende Beispiel ist vollständig konstruiert. Ein Betrieb nutzt eine Laboranwendung, eine Berechnungsvorlage und ein Dokumentensystem. Die Vorlage übernimmt einen Wert aus dem Laborbericht manuell. Alle drei verwenden dieselbe Identitätsverwaltung; die Vorlage liegt auf einer zentralen Ablage. Die Zahlen und Kennungen bezeichnen keine Kundensituation.
Der praktische Gewinn besteht nicht in einer möglichst hohen Systemzahl. Der Eintrag der Vorlage macht einen sonst leicht übersehenen Übergang sichtbar: Die Richtigkeit der manuellen Übernahme und die freigegebene Vorlagenversion müssen im passenden Verfahren betrachtet werden. Eine gemeinsame Anmeldung allein belegt weder diese Kontrolle noch die fachliche Eignung der Berechnung.
| Eintrag | Funktion und Verbindung | Dokumentierter Klärungsbedarf |
|---|---|---|
| SYS-017 Laboranwendung | Erzeugt Ergebnisbericht; zentrale Anmeldung | Bewertung und Beschreibung vorhanden, Stand abgleichen |
| SYS-018 Berechnungsvorlage | Übernimmt Ergebnis manuell; zentrale Ablage | Verantwortung, Versionslenkung und Eingabekontrolle klären |
| SYS-019 Dokumentensystem | Stellt freigegebene Arbeitsanweisung bereit | Nutzung der richtigen Revision prüfen |
| INF-003 Identitätsdienst | Gemeinsame technische Abhängigkeit | Verweis auf Rechte- und Betriebsnachweise sichern |
6. Status so führen, dass Lücken sichtbar bleiben
Ein einziges Feld „validiert: ja“ kann wesentliche Unterschiede verbergen. Halten Sie auseinander, ob ein System produktiv genutzt wird, welche Bewertung vorliegt und ob wesentliche Aufgaben offen sind. Die konkrete Statuslogik ist eine Gestaltungsentscheidung; Annex 11 schreibt dafür keine universelle Ampel oder feste Zahl von Zuständen vor.
Ein noch nicht vollständig bewertetes Altsystem wird deshalb mit seiner tatsächlichen Nutzung und der offenen Aufgabe geführt. Die Aufnahme ist keine Freigabe. Für stillgelegte Systeme bleibt sichtbar, wo weiterhin benötigte Daten und Zugriffsmöglichkeiten liegen. Entfernen Sie nicht ausgerechnet den Verweis, über den eine spätere Untersuchung die historische Datenumgebung finden kann.
7. Pflege an reale Änderungen anschließen
Benennen Sie, wer Änderungen meldet und wer den Eintrag fachlich bestätigt. Typische Auslöser sind eine neue Schnittstelle, ein zusätzlicher Standort, geänderte Nutzung, eine andere Betriebsform oder Stilllegung. Ein Versionswechsel muss nicht immer sämtliche Textfelder ändern; er muss aber auf seine Auswirkungen für den beschriebenen Stand geprüft werden.
Verbinden Sie diese Aufgabe mit vorhandenen Beschaffungs-, Änderungs- und Reviewverfahren. So entsteht kein isolierter Kalendertest, der zwischen zwei Terminen blind bleibt. Bei einer periodischen Bewertung kann die Liste mit tatsächlichen Nutzern, Verträgen und Betriebsinformationen abgeglichen werden. Umfang und Häufigkeit dieser Gegenprüfung sollten zur Veränderungsdynamik passen.
8. Mit einem prüfbaren Ausschnitt beginnen
Für einen gewachsenen Bestand ist ein gemeinsamer Durchgang durch einen entscheidenden Prozess oft ergiebiger als das sofortige Versenden einer langen Blankotabelle. QA bringt die Qualitätsentscheidung ein, der Fachbereich die tatsächliche Arbeit und IT die technischen Verbindungen. Offene Punkte erhalten einen Verantwortlichen und einen nachvollziehbaren Bearbeitungsstand.
Die folgende Checkliste unterstützt diesen Einstieg. Sie ist keine Vollständigkeitsgarantie. Ihr Ergebnis sollte ein verwendbarer Registerausschnitt sein, aus dem ein Dritter die betroffenen Anwendungen findet und die nächsten Nachweisfragen versteht. Erst danach lässt sich entscheiden, ob zusätzliche Felder wirklich helfen oder lediglich Pflegeaufwand erzeugen.
- GMP-Prozess und verwendete Anwendungen gemeinsam benannt.
- Lokale Dateien, Hilfsprogramme und ausgelagerte Dienste ausdrücklich abgefragt.
- GMP-Funktion und Verantwortlichkeit je Eintrag verständlich beschrieben.
- Wesentliche Abhängigkeiten und Dokumentverweise auf Erreichbarkeit geprüft.
- Offene Einordnungen mit Bearbeitungsverantwortung sichtbar gemacht.
- Änderungs-, Stilllegungs- und Überprüfungsanlässe vereinbart.
Häufige Fragen zu Systeminventar
Ist das Systeminventar dasselbe wie eine IT-Assetliste?
Nein. Eine Assetliste beschreibt häufig Geräte, Lizenzen oder technische Komponenten. Das GMP-Inventar muss die relevante Funktion im Prozess erkennen lassen. Sie können vorhandene Daten weiterverwenden und verlinken, sollten dabei aber die fachliche Nutzung und Systemgrenze ergänzen.
Muss jede Excel-Datei einen eigenen Eintrag erhalten?
Nicht allein aufgrund des Dateiformats. Prüfen Sie Funktion, Nutzung und organisatorische Abgrenzung. Eine gelenkte Vorlage mit vielen erzeugten Aufzeichnungen kann anders erfasst werden als mehrere unabhängig gepflegte Berechnungsanwendungen. Die Begründung muss den tatsächlich kontrollierten Bestand erkennen lassen.
Gehören reine kaufmännische Anwendungen hinein?
Bewerten Sie ihren tatsächlichen Einfluss und ihre Abhängigkeiten. Ein Etikett „kaufmännisch“ schließt GMP-Relevanz nicht automatisch aus, wenn beispielsweise relevante Stammdaten weitergegeben werden. Eine nachvollziehbar nicht relevante Anwendung muss nicht künstlich zum GMP-System erklärt werden.
Quellen: [1]
Wer soll das Inventar verantworten?
Die konkrete Rolle legt Ihr Betrieb fest. Sinnvoll ist eine benannte Pflegeverantwortung mit fachlicher Bestätigung durch Prozess- oder Systemverantwortliche. IT allein kennt möglicherweise nicht jede lokale Nutzung; QA allein kennt nicht jede technische Abhängigkeit. Die Zusammenarbeit muss funktionieren.
Quellen: [1]
Braucht jedes System sofort eine detaillierte Beschreibung?
Der entsprechende Satz in Annex 11 § 4.3 bezieht sich auf kritische Systeme. Das aktuelle Inventar relevanter Systeme ist davon zu unterscheiden. Zusätzliche Beschreibungen können fachlich sinnvoll sein, sollten aber nicht als undifferenzierte Forderung für jeden Eintrag dargestellt werden.
Quellen: [1]
Wie erfassen wir gemeinsam genutzte Cloud-Dienste?
Verknüpfen Sie den eigenen Anwendungsfall mit dem identifizierten Dienst, der Betriebsform und den relevanten Verantwortlichkeiten. Ein gemeinsamer Anbietername reicht nicht. Zugleich müssen Sie gemeinsame Infrastruktur nicht in jeder Anwendungszeile vollständig duplizieren, wenn verlässliche Referenzen bestehen.
Darf ein unbewertetes Altsystem im Inventar stehen?
Es sollte mit seinem tatsächlichen Zustand erkennbar sein. Die Aufnahme ersetzt weder Bewertung noch Freigabe. Kennzeichnen Sie offene Fragen und die verantwortliche Bearbeitung, damit eine vermeintlich saubere Liste nicht gerade die Systeme ausblendet, deren Nachweislage noch geklärt werden muss.
Schreibt Annex 11 eine jährliche Inventur vor?
§ 4.3 verlangt einen aktuellen Bestand, nennt aber keine jährliche Einheitsfrist. Legen Sie Pflegeanlässe und ergänzende Überprüfungen passend zur Änderungshäufigkeit fest. Eine Jahresroutine allein genügt als Methode nicht, wenn wesentliche Änderungen zwischenzeitlich unberücksichtigt bleiben.
Quellen: [1]
Kann das Inventar in einer Tabelle geführt werden?
Das Format allein entscheidet die Eignung nicht. Zugriff, Änderungslenkung, Verantwortlichkeit und nutzbare Verweise müssen zum Zweck passen. Prüfen Sie zudem, ob die eingesetzte Lösung selbst kritische Informationen verarbeitet oder Entscheidungen automatisiert; dann sind ihre eigenen Kontrollbedürfnisse zu bewerten.
Womit beginnen wir bei sehr vielen offenen Einträgen?
Wählen Sie einen relevanten Prozess, gehen Sie dessen Datenweg gemeinsam durch und bearbeiten Sie konkrete Unklarheiten nach Risiko. Verwenden Sie die gewonnenen Definitionen anschließend konsistent im übrigen Bestand. Die Reihenfolge der Bearbeitung darf offene Systeme sichtbar lassen, ohne ihren Zustand zu beschönigen.
Quellen & fachlicher Stand
Quellenstand 07.10.2026. Maßgeblich ist hier der Humanarzneimittel-GMP-Bereich. EudraLex führt Annex 11 und Chapter 4 in der Fassung Januar 2011; der konsultierte Entwurf von 2025 wird nicht als geltende Vorgabe verwendet. Die ausgefüllten Beispiele und Tabellen sind eigene Arbeitshilfen, keine behördlichen Mustervorlagen.
- EU-GMP Annex 11: Computerised SystemsRevision Januar 2011; Anwendungsdatum 30.06.2011; Abruf 07.10.2026. Fundstellen: Principle; §§1–2, 4.3, 10–11, 17
- EU-GMP Chapter 4: DocumentationRevision Januar 2011; Anwendungsdatum 30.06.2011; Abruf 07.10.2026. Fundstellen: §§4.1, 4.5, 4.10
- PIC/S PI 041-1: Good Practices for Data Management and IntegrityPI 041-1, 01.07.2021; Abruf 07.10.2026. Fundstellen: §§9.1.1–9.1.6, 9.1.10; §9.3
- Europäische Kommission: EudraLex Volume 4Status am 07.10.2026: Humanarzneimittelabschnitt führt Annex 11 Januar 2011 und Chapter 4 Januar 2011; Abruf 07.10.2026. Fundstellen: Human medicines / Part I / Annex 11
- Europäische Kommission: Konsultation 2025 zu Chapter 4, Annex 11 und Annex 22Status am 07.10.2026: geschlossen; 07.07.–07.10.2025. Fundstellen: Details; Revision of Annex 11; Links ausdrücklich Draft guidelines. Dient allein der Statusabgrenzung, nicht als geltende Anforderungsquelle.
Zuletzt fachlich geprüft am 07.10.2026.
Daniel Herrmann Consulting
Den konkreten Kontroll- und Nachweisbedarf bearbeiten
Daniel Herrmann Consulting unterstützt Sie dabei, diesen Ablauf auf Ihren Systembestand zu übertragen, Lücken zu bewerten und passende Nachweise vorzubereiten. Umfang und Mitwirkung richten sich nach Ihrem tatsächlichen Prozess.
- IT-GxP-Audit →
Anforderungen, vorhandene Nachweise und relevante Lücken beurteilen.
- IT-GxP-Consulting →
Vereinbarte Bewertungs-, Dokumentations- und Testarbeit im Projekt bearbeiten.
- IT-GxP-Coaching →
Ihr Team bei konkreten Entscheidungen und der Anwendung eigener Verfahren begleiten.
- IT-GxP-Compliance-Programm →
Passende interne Verfahren, Vorlagen und Schulung aufbauen.