Wie Agilität und GAMP 5® zusammenfinden
GxP-Richtlinien sind eine zentrale Konstante in der Branche. Doch längst müssten viele der Standards an zeitgemäße Entwicklungen im IT-Projektgeschäft angepasst werden. Insbesondere bei der Einführung von digitalen Neuerungen herrscht in den Unternehmen daher Unsicherheit: Darf man dieses oder jenes überhaupt?
Egal, ob Sie Ihr ERP-System ersetzen, Laborsysteme erneuern oder Track & Trace für neue Zielregionen einführen: Agile, in Sprints aufgeteilte Projektmethoden sorgen für Effizienz. Dabei wird für die einzelnen, aufeinander folgenden Sprints definiert, welche der initialen Anforderungen in den iterativen Zyklus aufgenommen werden. So hält man sich jederzeit die Option offen, auch noch während des Projekts neue Anforderungen in den Scope aufzunehmen – scheinbar ein fundamentaler Bruch mit GAMP® 5, der exemplarisch ein V-Modell zur Erläuterung heranzieht. Ist es also verboten, Projekte agil zu gestalten oder lässt sich das Vorgehen adaptieren?
Agiles Vorgehen nach GAMP 5®
Weit verbreitet ist die Meinung, dass die Validierung von Computersystemen den V-Modell-Ansatz mit einer Wasserfall-Methodik gleichsetzt. Was bedeuten würde, dass allen Anforderungen zugestimmt werden muss, bevor in das Design fortgeschritten werden kann – und im Folgenden das gesamte Design abgezeichnet werden muss, bevor das System gebaut werden kann. So setzt sich das fort, bis zur Freigabe des Systems in den Betrieb.
Die gute Nachricht aber lautet: Solche Projekte lassen sich zugleich agil und GAMP®5-konform validieren. Solange alle notwendigen Dokumentationen vorliegen und aktuell gehalten werden, ist die schwierige Frage nicht „ob es geht“, sondern viel mehr „wie es geht“. Hier ein Überblick:
Der Fokus der Validierung im agilen Projekt liegt darauf, welche Dokumente und Freigaben zu welchen Zeitpunkten benötigt werden. Denn die eigentlichen Arbeitsschritte verändern sich gegenüber der Wasserfall-Methodik nicht wesentlich, sondern werden nur in der Reihenfolge marginal verschoben – ohne dass sie mit GAMP® 5 brechen. Die durchgehende Redundanz von Sprint-Zyklen sollte Validierungsexpert*innen dabei nicht nervös machen.
In Etappen zum Validierungsreport
Benutzeranforderungen können schrittweise gesammelt und die Software in Etappen gebaut werden. Wenn Stakeholder bestimmte Dinge anders wünschen als ursprünglich angedacht, lassen sich die entsprechenden funktionalen und technischen Anforderungen jederzeit aktualisieren. Nach der Anpassung der Software an geänderte Vorgaben sollte eine neue Testrunde folgen. Auf diese Weise lässt sich ein Softwarepaket über aufeinanderfolgende V-Zyklen aufbauen.
Abb.: Konsekutive V-Modelle analog zu Sprint-Zyklen
Die Abbildung zeigt, wie im ersten Schritt „Initial Build“ auch das System qualifiziert wird. Da es anschließend nicht verändert wird, bleibt bei den folgenden Changes auch die IQ (Installationsqualifikation) unberührt. Die OQ (funktionale Qualifikation) und PQ (Leistungsqualifikation) werden um den Grad der Änderung nachvalidiert. Ein typisches Schaubild für eine Softwareproduktentwicklung im validierten Umfeld.
So erzeugt das Team die Validierungsdokumentation, während die Erstellung des Softwarepakets voranschreitet. Neue Erkenntnisse, die sich zwangsläufig ergeben, können in der Validierungsdokumentation untergebracht werden, ohne das gesamte Paket erneut zu validieren. Nur der inkrementelle Teil, der zu ändern ist, muss neu validiert werden, ebenso jene Teile, die von den Änderungen betroffen sein könnten.
Grundsätzlich werden Entwicklungs- und Testsysteme schon vor den Sprints bereitgestellt und die notwendigen Qualifikationen bereits vor den Sprints abgeschlossen. Auch die finalen Trainings lassen sich bereits auf diesen Systemen vollziehen. Häufig kann das Team die IQ aber erst nach den Trainings beenden, wenn das Produktivsystem fertig und verfügbar ist. Mit diesem letzten System (in einer 3-Tier-Architecture) ist die Validierung vollständig abgeschlossen – und die Antwort gefunden, wie agile Validierung nach GAMP 5® funktioniert.
Der agile Ansatz erscheint komplexer, ist mit der richtigen Software-Unterstützung aber nicht komplizierter. Vielmehr kann auch das Life-Science-Umfeld von den Vorteilen agiler Projektmethoden profitieren – soweit man diese passend einsetzt.
Möchten Sie mehr über den Einsatz agiler Methoden zur GAMP-konformen Validierung von IT-Systemen erfahren? Interessieren Sie sich für digitale Möglichkeiten, die Supply Chain reaktionsschnell und die Fertigung personalisierter aufzustellen? Dann empfehlen wir Ihnen den vollständigen Beitrag im ersten Teil unseres E-Books zur Blogreihe:
