11 Mrz Kommen wir aus verschiedenen Welten?

Posted at 11:36h in Qualitätsmanagement by

Wie passen die Ansätze des Agilen Manifests (der Ursprung des agilen Projektmanagements) mit den Strukturen der Computersystem-Validierung zusammen?

Aktueller könnte das Thema kaum sein: Im neu hinzugekommenen Anhang D8 – Agile Software Development der GAMP5 2nd Edition wird erläutert, wie die bereits gut entwickelten agilen Prozesse genutzt werden können, um Software für GxP Applikationen bereitzustellen – es geht explizit nicht darum, Agilität für GxP anzupassen.

Daher betrachten wir hier zunächst die vier Kernaussagen des agilen Manifests:

  • Individuen und Interaktionen stehen über Prozessen und Werkzeugen
  • Funktionierende Software steht über umfassender Dokumentation
  • Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
  • Eingehen auf Veränderung steht über dem Befolgen eines Plans

Im Gegensatz dazu sind die Strukturen und Prozesse im Rahmen von Computersystem-Validierungen (CSV) in regulierten Unternehmen (Pharmazie und Medizintechnik) fester gesetzt. Hier wurde über Jahrzehnte nach dem V-Modell gearbeitet. Das V-Modell ist, wie das Wasserfallmodell, starrer und nicht so flexibel.

Aufgrund der vermehrten Benutzung computergestützter Systeme mit höherer Komplexität bzw. Spezialisierung, stellt sich also die Frage, wie sich zwei Ansätze, die zunächst diametral zueinander erscheinen, Validierung und Agilität, miteinander verbinden lassen.

Grundsätzlich sollten wir kurz klären, über welche Systeme wir sprechen.

Der GAMP 5 unterteilt computergestützte Systeme nach Risiko in Kategorien. Für uns interessant ist zum einen die Kategorie 5: Kundenspezifische Applikationen, d.h. Software, die kundenspezifisch entwickelt wird. Aber auch Systeme der Kategorie 4 mit kundenspezifischen Modulen (= Komponenten der Kategorie 5) sind relevant, also Systeme, die weitgehend kundenspezifisch konfiguriert werden, in Teilen aber auch kundenspezifisch entwickelte Software enthalten. In beiden Fällen erfolgt das Vorgehen und die Dokumentation nach der höchsten Kategorie 5. 

Genau hier stellt sich jetzt die Frage, wie der damit einhergehende, hohe Aufwand aus dem GAMP 5 mit agilen Teams bewältigt werden kann.

Arbeiten in agilen Teams im V-Modell aus dem GAMP5
In vielen Fällen wird die Entwicklung von kundenspezifischen Systemen bzw. Modulen ausgelagert und von agilen Teams durchgeführt, die die hohen Anforderungen der regulierten Betriebe nicht oder kaum kennen. Viele Dokumente, die in der agilen Entwicklung eine untergeordnete Rolle spielen, müssen dementsprechend erstmals erzeugt und von internen Fachexperten abgenommen werden. Meist wird deshalb nur bis kurz vor der Testphase agil gearbeitet. Es entsteht ein grober Validierungsplan mit ein bis zwei Go-Live Meilensteinen. Spezifikationen werden oft erst kurz vor der Testwoche erstellt, geprüft und genehmigt, um dann mit den funktionalen Tests zu starten. Wenn während der Tests Spezifikationsdokumente angepasst werden müssen (Implementierung hat nicht wie geplant funktioniert und muss daher anders umgesetzt werden) stellt man sich als Quality-Experte manchmal die Frage, ob wirklich die Spezifikation getestet wurde oder ob die Spezifikation an den Test angepasst worden ist („Testing into compliance“).

In solchen „agilen“ Projekten verändert sich der ursprüngliche Scope, weil die Ausmaße bzgl. der Umsetzungsmöglichkeiten erst im Rahmen des agilen Arbeitens deutlich werden. Oft muss geprüft werden, ob bestimmte Module auch später implementiert werden können, da Business-kritische Funktionen Vorrang haben. Validierungsphasen vermehren sich und Abweichungen vom Validierungsplan müssen aufwendig verständlich erklärt und nachvollziehbar dokumentiert werden. Je weiter das Validierungsprojekt fortschreitet, und je mehr ursprünglich geplante Anforderungen auf spätere Validierungsphasen verschoben werden, desto schwieriger wird es den Überblick zu behalten und z.B. ursprüngliche aber verschobene Anforderungen von Changes aus der Hypercare-Phase zu unterscheiden.

Im Vergleich zum klassischen V-Modell könnte man diese Arbeitsweise am besten mit „Parallele / Gestaffelte V-Modelle“ beschreiben. Schematisch dargestellt sieht das dann so aus. Links (Abbildung 1) die ursprüngliche Planung, die im Validierungsplan beschrieben ist. Rechts (Abbildung 2) die reale Durchführung.

Jetzt schauen wir uns das Ganze als agiles Modell mit den wichtigsten Herausforderungen an.

Agile Validierung
Agile Entwicklung sieht kleinteilige Entwicklungsabschnitte vor, die die Zusammenarbeit zwischen Lieferanten und Kunden fördern sollen. In der agilen Entwicklungsmethode Scrum werden diese Entwicklungsabschnitte „Spints“ genannt. Das Ergebnis dieser Sprints ist jeweils eine (wenn auch z.T. rudimentäre) fertig implementierte und getestete Software, d.h. nach dem agilen Verständnis schließt ein Sprint die Validierung und damit den dokumentierten Nachweis, dass das System sich spezifikationskonform verhält, mit ein.

Daher sollten neue agile Dokumentationsweisen etabliert werden, statt auf altbekannten Formaten zu beharren. Regressionstests mithilfe von automatisierten Testtools sollten am Ende jedes Sprints eingebunden sein, ganz so wie es auch der GAMP 5 empfiehlt. Wir erkennen somit, dass alle aus dem GAMP 5 bekannten Aktivitäten des V-Modells, von der Planung über die Spezifizierung, Entwicklung und Verifizierung in den Sprints integriert werden sollten. Entsprechend des definierten Minimum Viable Products (MVP) können dann Go-live Akzeptanzkriterien beschlossen werden, die agil über das Projekt abgearbeitet werden. Außerhalb der Sprints sollte der Bedarf von zusätzlichen Validierungsaktivitäten, u.a. Trainings und deren Wiederholungen, entsprechend genau analysiert werden.

Die frühzeitige Planung unter Einbeziehung aller Stakeholder ist entscheidend, da das Validierungsmodell muss von allen Stakeholdern mit getragen werden muss und deren vermehrte Verfügbarkeit über das ganze Projekt notwendig macht.

(Gegensatz zum V-Modell, wo der Benutzer nur am Anfang beim Erstellen der Anforderungen und am Ende beim Benutzer-Akzeptanz-Test involviert ist.)

Die schematische Darstellung in Abbildung 3 ist noch sehr nah an das Modell „Parallele / Gestaffelte V-Modelle“ angelehnt. Darunter, in Abbildung 4, sieht man eine bessere Darstellung, die durch die kreisförmige bzw. spiralförmigen Sprints dem agilen Modell aus der Software-Entwicklung näherkommt.

Da wir nun dargelegt haben, dass alle Phasen der klassischen Validierung auch im Rahmen agiler Methodologie durchgeführt werden, nur kleinteiliger und in vielen Iterationen, kann man sich nun gut vorstellen, wie Agilität und Validierung zusammenpassen und werden hier die Vor- und Nachteile der verschiedenen Modelle vorstellen.

Vor- und Nachteile der vorgestellten Modelle

Vorteile vom agilen Modell – agile Validierung

  • Frühzeitiges Einbinden der User führt dazu, dass man die Fehler schneller erkennt. Schnelle Reaktion auf Anforderungsänderungen sind so möglich.
  • Ordentlich innerhalb der Sprints durchgeführte Tests führen dazu, dass am Ende weniger getestet werden muss
  • Benutzer werden kontinuierlich in den Entwicklungsprozess mit eingebunden und arbeiten dadurch intensiver mit dem System (und können sich evtl. dadurch auch mehr damit identifizieren)
  • Das Personal ist ständig mit der Validierung konfrontiert und passt seine Arbeitsweise entsprechend an.
  • Verzögerungen aufgrund von nicht ausreichenden Trainings sind seltener.
    Die Validierung wird als Teil des Systems verstanden und nicht als „Phase“ wahrgenommen, die aus regulatorischen Gründen „überstanden“ werden muss.
  • Das System bleibt durch stetige Weiterentwicklung aktuell
  • Findings aus dem aktuellen System können einfacher eingeplant und implementiert werden
  • Bei einem täglich genutzten System können mehrere, kleinere Änderungen besser in den Alltag der Benutzer eingebaut werden.


Nachteil agiles Modell – agile Validierung

  • Kontinuierliche Dokumentation, deren Überprüfung und Genehmigung mehr Zeit kosten kann (dies kann und sollte mit elektronischen Dokumentationssystemen abgefangen werden)
  • Testen der Änderungen mit Auswirkungen auf die bisherigen Entwicklungsergebnisse kann mehr Zeit kosten (dies kann mit Testautomatisierungen, sowie den Regressionstests am Ende eines jeden Sprints, abgefangen werden)
  • Veraltete Vorgaben / Systeme erschweren das Arbeiten
  • Auch bei kleineren Projekten muss das Personal entsprechend trainiert sein. Vor allem externen Teammitgliedern, die wenig Berührungspunkte mit der guten Dokumentationspraxis hatten, fällt es schwer, die dokumentierten Nachweise korrekt zu erstellen. Wenn es hier keine Unterstützung durch Systeme gibt, müssen die Dokumente entsprechend öfter in den Review-Umlauf.

Vorteile V-Modell – klassische Validierung

  • Vorhandene Vorgaben / Technologien können genutzt werden. Weniger Trainings für neue Systeme notwendig.
  • Unterbrechungen der alltäglichen Arbeit kann auf definierte Zeitspannen begrenzt werden. Die Benutzer müssen ihre Arbeit z.B. nur für finale Tests unterbrechen.
  • Der Projektrahmen kann besser abgesteckt werden und für Stakeholder verständlicher dargestellt werden.

Nachteile V-Modell – klassische Validierung

  • Umsetzungsschwierigkeiten mit Einfluss auf den Go-Live machen Änderungen im Validierungsplan oder weitergehende Erklärungen im Validierungsreport notwendig und führen oftmals zu Verzögerungen (sehr geringe Flexibilität)
  • Eine Anpassung des Scopes ist je nach Projektfortschritt kaum oder nicht mehr möglich (sehr geringe Flexibilität)
  • Benutzer sehen erst am Ende wie das System umgesetzt wurde und können das Ergebnis nur geringfügig beeinflussen. Es kann vorkommen, dass Funktionen eingebaut werden, die von den Benutzern in dieser Form nicht genutzt werden können. Evtl. ist dadurch eine weitere Änderung im operativen Prozess erforderlich. (kann durch regelmäßige Risikoanalyse / Impact-Analyse abgefangen werden)

Fazit
Die Auswahl des Validierungs-Modells sollte gut durchdacht werden und von allen Stakeholdern mitgetragen werden, um die erfolgreiche Projektdurchführung zu gewährleisten. Oft stellt das Durchbrechen alter Gewohnheiten die größte Hürde dar. Vor allem in regulierten Unternehmen sollte man die zu erbringenden Nachweise (Dokumentation, Testen) effektiv mit einplanen, um spätere Verzögerungen im Projektablauf oder mögliche non-compliance Ereignisse abzufangen. Vor allem die Frage, wie zu dokumentieren ist und welche Tools dabei zu nutzen sind, sollte frühzeitig mit den Qualitäts- und/oder Validierungsabteilungen geklärt werden.

Eine gute Risikoanalyse und Priorisierung der Anforderungen tragen erheblich zum erfolgreichen Projektabschluss bei.

Der Ansatz des „Parallele / Gestaffelte V-Modells“ kann ein Kompromiss.

Wichtig ist hierbei ist klare Kommunikation um die Erwartungen der Stakeholder an die Validierungs-Flexibilität auf einem akzeptablen Niveau zu halten – im Rahmen der Vorgaben des regulierten Unternehmens.

Die Vorgehensweisen im agilen Modell werden meist durch veraltete Verfahren und Technologien erschwert, die das Projektteam eher behindern als es zu unterstützen.

Daher ist ein entscheidendes Erfolgskriterium die agile Methodologie tatsächlich anzunehmen, entsprechende Prozesse anzupassen und unterstützende Systeme zu etablieren und zu betreiben. Unter diesen Umständen ist Validierung im Rahmen agiler Methoden nicht nur möglich, sondern anzustreben.

Autorinnen: Annika Bergmann, Melanie Witt