Inhaltsverzeichnis
Das Wichtigste vorab
Wie bleibt ein iterativ entwickelter Funktionsstand mit Anforderungen und Nachweisen verbunden?
Verbinden Sie jedes nutzbare Inkrement mit einem identifizierbaren Funktionsstand, den betroffenen Anforderungen und passenden Nachweisen. Bewerten Sie Änderungen einschließlich ihrer Auswirkungen auf bereits belegte Funktionen und vorhandene Daten. Die Nutzungsentscheidung bezieht sich auf diesen konkreten Stand und bekannte offene Punkte. Agile Entwicklung erfordert kein starres Dokumentpaket je Sprint, entbindet im GMP-Scope aber nicht von begründeter Validierung, Änderungssteuerung und nachvollziehbarer Evidenz.
- Arbeitsstand, geprüften Stand und erlaubte Nutzung eindeutig unterscheiden.
- Übernommene Evidenz anhand tatsächlicher Änderungswirkungen begründen.
- Offene Befunde und nicht aktivierte Funktionen im Release sichtbar halten.
1. Beginnen Sie mit dem vorgesehenen Einsatz
Agil beschreibt zunächst die Arbeitsweise. Ob eine Funktion GMP-relevant ist, richtet sich dagegen nach ihrer Verwendung und Wirkung. Schreiben Sie deshalb auf, welcher Prozess unterstützt wird, welche Daten entstehen und welche Entscheidung davon abhängt. Das Beispiel dieses Artikels setzt Humanarzneimittel-GMP voraus; andere Einsatzbereiche brauchen eine eigene Anforderungszuordnung.
Die öffentliche ISPE-Beschreibung der zweiten GAMP-5-Ausgabe unterstützt iterative und inkrementelle Ansätze. Daraus folgt keine Pflicht zu einer bestimmten Sprintlänge oder einem bestimmten Werkzeug. Annex 11 verlangt im einschlägigen Einsatz einen begründeten Lebenszyklus und geeignete Validierungsnachweise. Beide Perspektiven sind vereinbar, wenn Änderungen und Nachweisstände beherrscht werden.
2. Definieren Sie eine prüfbare Grundlage pro Inkrement
Eine prüfbare Grundlage muss erkennen lassen, was getestet wurde. Dazu können Softwareversion, Konfiguration, relevante Stammdaten, Schnittstellenstand und Testumgebung gehören. Die notwendige Tiefe hängt vom System ab. Eine Versionsnummer allein genügt nicht, wenn Einstellungen das fachliche Verhalten unabhängig davon verändern.
Halten Sie außerdem fest, welche Anforderungen für dieses Inkrement gelten und welche Funktionen noch nicht zur Nutzung vorgesehen sind. Ein Team darf an späteren Funktionen arbeiten, während ein früherer Stand genutzt wird. Es muss dann aber klar sein, welche Artefakte zu welcher Grundlage gehören. Ein wechselnder Link auf „aktuell“ ist für diese Zuordnung ohne erhaltene Historie zu schwach.
Quellen: [2]
3. Illustrativer Fall: zwei Stände eines Probenimports
Ein fiktives Labor führt eine Schnittstelle für Probenaufträge ein. Inkrement A importiert Aufträge und weist doppelte Auftragskennungen zurück. Inkrement B ergänzt eine Änderungsfunktion für bereits angelegte Aufträge. Die fachliche Annahme lautet: Ein Auftrag darf durch eine Änderung nicht unbemerkt ein zweites Mal entstehen. Die Tabelle beschreibt geplante Sollnachweise, keine ausgeführten Tests.
Für A sind zwölf Fälle vorgesehen: acht neue Aufträge und vier wiederholte Übertragungen. Erwartet werden acht Aufträge und vier erkennbare Zurückweisungen. Für B kommen sechs Änderungsfälle hinzu: vier erlaubte Änderungen und zwei unzulässige Änderungen. Die endgültige Auftragszahl bleibt im Beispiel acht; eine Änderung erzeugt keinen zusätzlichen Auftrag.
| Stand | Verhalten und Grundlage | Geplanter Nachweis | Erwartete Entscheidung |
|---|---|---|---|
| A: Erstimport | Neue Kennung anlegen; gleiche Kennung zurückweisen | 8 neue + 4 wiederholte Übertragungen = 12 Fälle | 8 Aufträge; Wiederholungen erkennbar, Erstimport beurteilen |
| B: Änderung | Bestehenden Auftrag gezielt ändern; unzulässige Änderung ablehnen | 4 erlaubte + 2 unzulässige Änderungen = 6 zusätzliche Fälle | Weiterhin 8 Aufträge; Änderungsstand nachvollziehbar |
| B: Wechselwirkung | Änderung beeinflusst die Dublettenprüfung möglicherweise | Betroffene A-Fälle erneut auswählen und prüfen | B erst für vorgesehenen Umfang beurteilen, wenn Wechselwirkung geklärt |
| B: Nichtumfang | Automatische Löschung bleibt deaktiviert | Einstellung und Berechtigung kontrollieren | Keine Freigabe einer nicht vorgesehenen Löschfunktion |
Quellen: [2]
4. Verknüpfen Sie Anforderungen und Ergebnisse gezielt
Eine User Story kann eine fachliche Anforderung enthalten, muss aber ausreichend eindeutig sein. „Als Nutzer möchte ich Aufträge ändern“ lässt offen, wer welche Felder unter welchen Bedingungen ändern darf. Ergänzen Sie die entscheidenden Regeln und erwarteten Fehlerreaktionen. Akzeptanzkriterien sind besonders hilfreich, wenn sie eine überprüfbare fachliche Grenze formulieren.
Verknüpfen Sie die Anforderung mit dem konkreten Prüfziel und Ergebnis. Bereits vorhandene Nachweise dürfen weiterverwendet werden, wenn ihre Gültigkeit für den neuen Stand begründet ist. Eine reine Anzahl von verlinkten Testfällen sagt dagegen wenig über die Abdeckung. Im Beispiel braucht die neue Änderungsfunktion einen Bezug zur bestehenden Dublettenregel, obwohl deren Anforderungstext unverändert bleibt.
Quellen: [2]
5. Entscheiden Sie über Übernahme, Ergänzung und Wiederholung
Die eigene Entscheidungsmatrix ordnet unterschiedliche Veränderungen ein. Sie schreibt keine feste Mindestzahl von Regressionstests vor. Der Ausgangspunkt ist jeweils, welche bisherige Aussage durch die Änderung unsicher wird. Auch eine Konfigurationsänderung ohne neuen Programmcode kann eine wesentliche fachliche Wirkung haben.
Begründen Sie ausdrücklich, wenn ein alter Nachweis unverändert weiter gilt. Das ist nützlicher als pauschal alle Tests zu wiederholen oder pauschal nur neue Tickets zu prüfen. Bei unklarer Abhängigkeit muss zunächst die Unsicherheit geklärt werden; ein fehlender technischer Überblick ist kein Beleg dafür, dass keine Auswirkung besteht.
| Änderung | Betroffene Aussage | Geeignete Handlung | Begründung festhalten |
|---|---|---|---|
| Neues Änderungsfeld | Nur erlaubte Felder sind veränderbar | Neue Positiv- und Negativfälle | Berechtigung und fachliche Folgen |
| Gemeinsame Importlogik geändert | Dubletten werden erkannt | Betroffene Erstimportfälle wiederholen | Abhängigkeit zwischen A und B |
| Unveränderte Hilfeanzeige | Keine veränderte Datenverarbeitung erkennbar | Auswirkung prüfen; passende vorhandene Evidenz übernehmen | Beleg, weshalb kritische Funktionen unberührt bleiben |
| Unbekannter Lieferantenpatch | Auswirkung noch nicht bestimmbar | Änderungsinformation beschaffen; Restlücke prüfen | Keine pauschale Übernahme bei unklarer Grundlage |
6. Lassen Sie offene Befunde nicht im Backlog verschwinden
Ein Backlogeintrag kann eine technische Aufgabe darstellen, ersetzt aber nicht die Bewertung eines Fehlers für die geplante Nutzung. Ordnen Sie den Befund dem betroffenen Stand zu. Beschreiben Sie seine Auswirkung, gegebenenfalls eine wirksame Begrenzung und die Entscheidung, ob der vorgesehene Einsatz vertretbar ist.
Im Beispiel wäre eine doppelte Auftragsanlage bei Wiederholung kein bloß kosmetischer Befund. Eine manuelle Kontrolle könnte nur dann zur Entscheidung beitragen, wenn ihr Ablauf, ihre Reichweite und Wirksamkeit ausreichend belegt sind. „Wird später behoben“ beschreibt weder eine Kontrolle noch eine zulässige Nutzung. Korrekturen müssen anschließend mit dem ursprünglichen Befund und geeigneten Nachweisen verbunden bleiben.
7. Verbinden Sie Entwicklung und Betrieb am Übergabepunkt
Für die Nutzungsentscheidung sollten Fachprozess, technische Bereitstellung und Qualitätsanforderungen zusammengeführt werden. Das bedeutet keine universelle Unterschriftenkombination. Legen Sie in Ihrer Organisation fest, wer den fachlichen Umfang beurteilt, wer die konkrete Bereitstellung verantwortet und wer mit welcher Befugnis über den Einsatz entscheidet.
Ein erfolgreicher automatisierter Lauf belegt nur die darin enthaltenen Prüfungen unter den jeweiligen Bedingungen. Zusätzlich können Migration, Berechtigungen, Arbeitsanweisungen oder Support relevant sein. Gerade kleine Teams profitieren von einer kurzen Übergabenotiz: bereitgestellter Stand, erlaubte Funktionen, verwendete Nachweise, offene Punkte und Maßnahmen bei Problemen. Diese Notiz darf auf erhaltene Detailnachweise verweisen.
Quellen: [2]
8. Checkliste für das nächste nutzbare Inkrement
Prüfen Sie die Vollständigkeit anhand einer konkreten Folgeentscheidung, nicht anhand der Zahl erzeugter Dokumente. Könnte ein späterer Bearbeiter erkennen, warum Stand B eingesetzt werden durfte und welche Nachweise aus A weiterhin galten? Wenn dafür mündliches Projektwissen nötig ist, fehlt ein wichtiger Zusammenhang.
Die Checkliste ist eine eigene Arbeitshilfe. Sie kann in ein vorhandenes Releaseverfahren integriert werden; ein zusätzliches paralleles Validierungsarchiv ist nicht automatisch erforderlich. Entscheidend sind kontrollierte Zuordnung, Verfügbarkeit und ein nachvollziehbarer Entscheidungsverlauf.
- Intended Use und erlaubter Funktionsumfang stehen fest.
- Software, Konfiguration und relevante Datenbasis sind identifizierbar.
- Anforderungen und Prüfziele sind dem Inkrement zugeordnet.
- Auswirkungen auf frühere Funktionen und vorhandene Daten sind bewertet.
- Übernommene Evidenz und zusätzliche Prüfungen sind begründet.
- Befunde einschließlich wirksamer Begrenzungen sind entschieden.
- Betriebsbereitschaft und konkrete Nutzungsentscheidung sind dokumentiert.
Quellen: [2]
Häufige Fragen zu GAMP 5: Agile Validierung über Inkremente nachvollziehbar
Erlaubt GAMP 5 agile Entwicklung?
Die öffentliche Beschreibung der zweiten Ausgabe unterstützt iterative und inkrementelle Vorgehensweisen. Sie legt damit keine bestimmte agile Methode verbindlich fest. Für den GMP-Einsatz bleibt entscheidend, dass Anforderungen, Risiken, Änderungen und Nachweise über den Lebenszyklus nachvollziehbar behandelt werden.
Müssen wir nach jedem Sprint vollständig neu validieren?
Nicht pauschal. Prüfen Sie zunächst, ob ein Stand überhaupt zur regulierten Nutzung vorgesehen ist und welche Funktionen sich verändert haben. Der Nachweisumfang richtet sich nach der Auswirkung. Unveränderte passende Evidenz kann weiter beitragen; relevante Wechselwirkungen dürfen dabei nicht übersehen werden.
Quellen: [2]
Kann eine User Story eine Anforderung ersetzen?
Sie kann eine Anforderung tragen, wenn fachlicher Zweck, Regeln und Grenzen ausreichend beschrieben sind. Ein kurzer Wunsch ohne prüfbare Akzeptanzkriterien reicht häufig nicht. Wichtig ist die durchgängige Zuordnung zu den relevanten Nachweisen, nicht die Überschrift des verwendeten Dokuments.
Quellen: [2]
Welche Baseline brauchen wir bei konfigurierbarer Software?
Erfassen Sie die Merkmale, die das geprüfte Verhalten bestimmen. Dazu können neben der Programmversion Konfiguration, Berechtigungen, Schnittstellen und relevante Stammdaten gehören. Der Umfang ist systemspezifisch. Eine Versionsnummer reicht nicht, wenn wesentliche Einstellungen unabhängig davon verändert werden können.
Quellen: [2]
Dürfen frühere Tests für ein neues Inkrement gelten?
Ja, wenn ihre Aussage für den neuen Stand weiterhin trägt. Begründen Sie das anhand der Änderung und ihrer Abhängigkeiten. Im Beispiel kann eine unveränderte Dublettenanforderung trotzdem neue Prüfungen brauchen, weil die neue Änderungsfunktion denselben technischen Verarbeitungsweg nutzt.
Ist ein Sprint-Review bereits eine GMP-Freigabe?
Nicht automatisch. Ein Sprint-Review kann wichtige fachliche Erkenntnisse liefern. Ob es zugleich eine Nutzungsentscheidung trägt, hängt von geregelter Befugnis, vorhandenem Nachweis und bewerteten offenen Punkten ab. Die Bezeichnung einer Besprechung sagt nichts über diese Voraussetzungen aus.
Quellen: [2]
Wie behandeln wir eine deaktivierte neue Funktion?
Dokumentieren Sie, dass sie nicht zum erlaubten Einsatz gehört, und prüfen Sie die wirksame Begrenzung. Relevant ist auch, ob die Funktion trotz Deaktivierung andere Abläufe beeinflusst. Eine spätere Aktivierung braucht eine eigene Auswirkungs- und Nutzungsentscheidung auf geeigneter Grundlage.
Quellen: [2]
Sind alle offenen Fehler vor jeder Nutzung zu schließen?
Eine pauschale Aussage wäre zu grob. Bewerten Sie Bedeutung und verbleibendes Risiko für den vorgesehenen Einsatz. Kritische ungeklärte Auswirkungen können die Nutzung verhindern. Eine vertretbare Einschränkung muss konkret, wirksam und dokumentiert sein; ein späterer Backlogtermin allein genügt nicht.
Belegt eine grüne Pipeline die fachliche Eignung?
Sie belegt zunächst, dass die eingerichteten automatisierten Prüfungen unter den Laufbedingungen erfolgreich waren. Ob deren Umfang und Ergebnis die fachliche Nutzung tragen, muss beurteilt werden. Nicht erfasste Berechtigungen, Migrationen oder Arbeitsabläufe werden durch die grüne Anzeige nicht mitgeprüft.
Quellen: [2]
Wie halten kleine Teams den Aufwand überschaubar?
Nutzen Sie vorhandene Werkzeuge und eindeutige Verknüpfungen. Eine kompakte Entscheidung mit erhaltenen Detailnachweisen ist oft hilfreicher als doppelte Dokumentation. Vereinfachen Sie die Ablage, ohne die Verbindung zwischen Anforderung, Stand, Befund und zulässiger Nutzung zu verlieren.
Quellen & fachlicher Stand
Quellenstand 7. Oktober 2026. Behördenvorschriften, Leitlinien und Branchenmethodik sind getrennt einzuordnen. Tabellen, Zahlen und Fälle sind eigene illustrative Arbeitshilfen; keine ausgeführten Produktprüfungen oder Kundenergebnisse.
- ISPE: GAMP 5 Guide, 2nd EditionÖffentliche Herausgeberbeschreibung und Editionsangabe; kein Zugriff auf kostenpflichtigen Volltext.
- EU-GMP Annex 11 – Computerised SystemsRevision Januar 2011; im Humanarzneimittelabschnitt gelistet. Principle, §§1–17.
- EMA: ICH Q9(R1) – Quality Risk Management, Corr.2EMA-Fassung 23.01.2025, Corr.2; fachlich R1, EU-Anwendung seit 26.07.2023. §§1–6, besonders 4.3,5.1–5.3.
Zuletzt fachlich geprüft am 07.10.2026.
Daniel Herrmann Consulting
Den konkreten Nachweisprozess gemeinsam bearbeiten
Wir helfen Ihrem Team, Entwicklungsarbeit, fachliche Prüfung und Nutzungsentscheidungen über mehrere Inkremente zusammenzuführen.
- 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.