Patrick Zahnow leitet das siebenköpfige Validierungs‐ und Qualifizierungsteam bei ARCONDIS. Er ist Experte für Computerized System Validation (CSV) und führt als Projektleiter und Validation Lead zahlreiche Compliance‐ und Qualitätsmanagementprojekte. Zudem bringt er rund 20 Jahre Erfahrung in der Pharmaindustrie und zehn Jahren in der Medizinproduktbranche mit, was ihn zu einem erfahrenen Ansprechpartner rund um Validierung in der Life Sciences Branche macht.
Im Interview mit UPDATE spricht Zahnow über seine Erfahrungen in Validierungsprojekten und berichtet, welche speziellen Herausforderungen im agilen Umfeld auftreten können.
Herr Zahnow, wann empfiehlt sich der Einsatz von agilen CSV‐Frameworks?
Der Klassiker ist die Entwicklung von mobilen Applikationen im regulierten Umfeld. Immer häufiger kommt die agile Softwareentwicklung aber auch bei Businessapplikationen für Desktopanwender zum Einsatz. Das hält den Entstehungsprozess flexibel und ermöglicht, den Fokus gezielt auf priorisierte Funktionalitäten zu legen. Bei Scrum Beispielsweise werden in einzelnen Iterationen, sogenannten Sprints, funktionsfähige Teilprodukte der Applikation fertiggestellt. Um den Ansprüchen an Qualität und Compliance gerecht zu werden, empfehle ich, im agilen Entwicklungsumfeld auch einen agilen Validierungsansatz – auch als agiles CSV‐Framework bezeichnet – zu wählen. Das erleichtert die Zusammenarbeit zwischen Business, also der Fachabteilung, und den Quality‐Verantwortlichen, was die Flexibilität und verkürzt Release‐Zyklen erhöht.
In Bezug auf die regulatorischen Vorgaben ist es völlig egal, ob man klassisch nach Wasserfall‐ und V‐Modell vorgeht oder den agilen Weg wählt, beides ist zulässig. Insbesondere beim agilen Vorgehen aber muss man sich sehr bewusst sein, zu welchem Zeitpunkt – also in welchem Sprint – welche Dokumente freigegeben werden sollen.
Wie sieht ein typisches agiles Framework aus?
Agile Validierung bedeutet nicht – was zu vermuten wäre –, dass innerhalb jedes Sprints ein Mini‐V‐Modell durchgeführt wird. Sondern es reicht, die Validierung erst nach einigen Sprints vorzunehmen. Meiner Erfahrung nach bewährt es sich, alle drei Entwicklungssprints einen Validierungssprint durchzuführen. So handhaben wir dies beispielsweise auch aktuell bei einem Kunden aus der Medizinproduktindustrie bei der Einführung einer mobilen Applikation zur Erfassung von Kundenfeedbacks in das zentrale Complaint‐Management‐System.
In der Praxis sieht es so aus, dass sämtliche Dokumente wie User Requirements, Funktions‐ und Designspezifikationen, die man aus dem klassischen V‐Modell kennt, im ersten Sprint initial aufgesetzt werden. In jedem Folgesprint werden diese Dokumente um die neuen Funktionalitäten erweitert. Die eigentliche Freigabe und das zugehörige Testing erfolgen jedoch erst im formellen Validierungssprint. Bildlich gesprochen erledige ich in den Entwicklungssprints die linke Seite des V‐Modells, im Validierungssprint erfolgt dann die rechte Seite.
Welche Besonderheiten gibt es dann dabei?
Die eigentliche Validierungsarbeit unterscheidet sich nicht sehr zum Standardvorgehen, es gibt im agilen Umfeld aber einige Fallstricke. So ist es unabdingbar, die Qualitätsabteilung schon vor Projektstart mit an Bord zu holen. Anders als im Wasserfallmodell bleiben beim agilen Vorgehen jeweils nur zwei bis drei Wochen zur Freigabe sämtlicher Dokumente. Kann diese Frist nicht eingehalten werden, verzögert sich die gesamte Entwicklung um einen kompletten Sprint. Der Freigabeprozess muss daher einwandfrei funktionieren. Neben dem Commitment der Verantwortlichen ist dazu auch ein sauberes Dokumentenmanagementsystem wichtig.
Die echte Herausforderung hat man als Validation Lead aber vor allem dann, wenn die Entwickler zwar agil nach Scrum vorgehen, der Projektmanager hingegen nach Wasserfall. So ähnlich ist das bei einem aktuellen Projekt: Wir unterstützen bei einem Laborprodukte‐Hersteller die Optimierung eines Systems aufgrund fester Vorgaben des Kunden nach dem Wasserfallmodell, während parallel dazu ein dazugehöriges CRM agil entwickelt wird und validiert werden soll. In so einem Fall bestehe ich auf einer sehr engen Zusammenarbeit der jeweiligen Projektleiter, damit die Milestones der Projekte zusammenpassen und zum richtigen Zeitpunkt die notwendigen Anforderungen für die Entwicklung zur Verfügung stehen.
Vielen Dank für den Einblick zum Vorgehen und damit zusammenhängende Besonderheiten!
Im Interview mit UPDATE spricht Zahnow über seine Erfahrungen in Validierungsprojekten und berichtet, welche speziellen Herausforderungen im agilen Umfeld auftreten können.
Herr Zahnow, wann empfiehlt sich der Einsatz von agilen CSV‐Frameworks?
Der Klassiker ist die Entwicklung von mobilen Applikationen im regulierten Umfeld. Immer häufiger kommt die agile Softwareentwicklung aber auch bei Businessapplikationen für Desktopanwender zum Einsatz. Das hält den Entstehungsprozess flexibel und ermöglicht, den Fokus gezielt auf priorisierte Funktionalitäten zu legen. Bei Scrum Beispielsweise werden in einzelnen Iterationen, sogenannten Sprints, funktionsfähige Teilprodukte der Applikation fertiggestellt. Um den Ansprüchen an Qualität und Compliance gerecht zu werden, empfehle ich, im agilen Entwicklungsumfeld auch einen agilen Validierungsansatz – auch als agiles CSV‐Framework bezeichnet – zu wählen. Das erleichtert die Zusammenarbeit zwischen Business, also der Fachabteilung, und den Quality‐Verantwortlichen, was die Flexibilität und verkürzt Release‐Zyklen erhöht.
In Bezug auf die regulatorischen Vorgaben ist es völlig egal, ob man klassisch nach Wasserfall‐ und V‐Modell vorgeht oder den agilen Weg wählt, beides ist zulässig. Insbesondere beim agilen Vorgehen aber muss man sich sehr bewusst sein, zu welchem Zeitpunkt – also in welchem Sprint – welche Dokumente freigegeben werden sollen.
Wie sieht ein typisches agiles Framework aus?
Agile Validierung bedeutet nicht – was zu vermuten wäre –, dass innerhalb jedes Sprints ein Mini‐V‐Modell durchgeführt wird. Sondern es reicht, die Validierung erst nach einigen Sprints vorzunehmen. Meiner Erfahrung nach bewährt es sich, alle drei Entwicklungssprints einen Validierungssprint durchzuführen. So handhaben wir dies beispielsweise auch aktuell bei einem Kunden aus der Medizinproduktindustrie bei der Einführung einer mobilen Applikation zur Erfassung von Kundenfeedbacks in das zentrale Complaint‐Management‐System.
In der Praxis sieht es so aus, dass sämtliche Dokumente wie User Requirements, Funktions‐ und Designspezifikationen, die man aus dem klassischen V‐Modell kennt, im ersten Sprint initial aufgesetzt werden. In jedem Folgesprint werden diese Dokumente um die neuen Funktionalitäten erweitert. Die eigentliche Freigabe und das zugehörige Testing erfolgen jedoch erst im formellen Validierungssprint. Bildlich gesprochen erledige ich in den Entwicklungssprints die linke Seite des V‐Modells, im Validierungssprint erfolgt dann die rechte Seite.
Welche Besonderheiten gibt es dann dabei?
Die eigentliche Validierungsarbeit unterscheidet sich nicht sehr zum Standardvorgehen, es gibt im agilen Umfeld aber einige Fallstricke. So ist es unabdingbar, die Qualitätsabteilung schon vor Projektstart mit an Bord zu holen. Anders als im Wasserfallmodell bleiben beim agilen Vorgehen jeweils nur zwei bis drei Wochen zur Freigabe sämtlicher Dokumente. Kann diese Frist nicht eingehalten werden, verzögert sich die gesamte Entwicklung um einen kompletten Sprint. Der Freigabeprozess muss daher einwandfrei funktionieren. Neben dem Commitment der Verantwortlichen ist dazu auch ein sauberes Dokumentenmanagementsystem wichtig.
Die echte Herausforderung hat man als Validation Lead aber vor allem dann, wenn die Entwickler zwar agil nach Scrum vorgehen, der Projektmanager hingegen nach Wasserfall. So ähnlich ist das bei einem aktuellen Projekt: Wir unterstützen bei einem Laborprodukte‐Hersteller die Optimierung eines Systems aufgrund fester Vorgaben des Kunden nach dem Wasserfallmodell, während parallel dazu ein dazugehöriges CRM agil entwickelt wird und validiert werden soll. In so einem Fall bestehe ich auf einer sehr engen Zusammenarbeit der jeweiligen Projektleiter, damit die Milestones der Projekte zusammenpassen und zum richtigen Zeitpunkt die notwendigen Anforderungen für die Entwicklung zur Verfügung stehen.
Vielen Dank für den Einblick zum Vorgehen und damit zusammenhängende Besonderheiten!
