In diesem Artikel wird gezeigt, welche Chancen Agilität als Antwort auf bekannte und neue Herausforderungen bietet. [...]
Agilität muss man zunächst als Mindset, also Geisteshaltung verstehen, aus der konkrete Praktiken und Tools entstehen. Diese können die Veränderung hin zur verbesserten Zusammenarbeit im Rahmen optimierter Prozesse unterstützen. Dazu muss man sich von dem Gedanken lösen, alles bis ins Detail beherrschen und beliebig weit im Voraus planen zu können. Diese Erkenntnis bildet die Grundlage für den agilen Ansatz.
Wichtige Prinzipien dabei sind kurze Feedbackzyklen (Plan-Do-Check-Adjust), welche dem Vorgehen der adaptiven Prozessverbesserung folgen. Auch wenn es zyklische Ansätze und Prozessverbesserungen bereits in bekannten Vorgehensmodellen gibt, so ist doch ihre Anwendungsgeschwindigkeit in diesem Zusammenhang eine deutlich höhere. Ein gutes Beispiel dafür ist das Prinzip des ‚Lessons-Learned‘, welches typischerweise am Ende eines Projektes (nach durchschnittlich 18-24 Monaten) durchgeführt wird und somit dem Projekt selbst keinen Vorteil mehr bringt. Dieselbe Idee wird im agilen Kontext regelmäßig und vor allem häufiger (im Schnitt mehr als einmal im Monat) umgesetzt und führt damit bereits während der eigenen Projektlaufzeit zu Verbesserungen. Die Ergebnisse der Entwicklung selbst entstehen so in Harmonie mit dem sich verbessernden Projekt in kleinen, aber sehr wertbringenden Inkrementen.
Agilität bedeutet aber auch, aus der Reaktion wieder ins Agieren zu kommen, also vom Geführt-werden zurück ins Führen. Darüber hinaus ist es immer gut, sich in Zeiten der Unsicherheit Verbündete und Gleichgesinnte zu suchen, anstatt allein voran zu gehen. All dies macht die Agilität und ihre Ausprägungsformen aus – Teamarbeit (Schwarmintelligenz), in kurzen Zyklen (Iterationen) mit Feedbackschleifen arbeiten und nicht nur das Ergebnis produzieren, sondern gleichzeitig auch den dazu genutzten Prozess verbessern (Inspect & Adapt).
Agil heißt also nicht planlos zu handeln, sondern lediglich für kürzere, also tatsächlich beherrschbare Zeiträume zu planen. Die Ergebnisse der Iterationen, also die Produkt-Inkremente, werden sorgfältig definiert, einschließlich der Kriterien für das Erkennen ihrer erfolgreichen Umsetzung. Zu diesen Kriterien gehört auch die Compliance zu regulatorischen Anforderungen. So können beispielsweise automatisierte Tests bei jedem neuen Inkrement nachweisen, dass die regulatorischen Anforderungen immer noch und durchgängig erfüllt sind. Ein Beispiel wäre die Umsetzung des Audit Trails und die Anforderungen an die Datenintegrität zur Sicherstellung der Patientensicherheit und Produktqualität durch automatisierte Tests.
Beispiele für Bereiche, in denen sich das inkrementell (also stufenweise bei gleichzeitiger Business-Case Betrachtung) umsetzen lässt sind vergleichsweise einfach zu finden: Während die Digitalisierung im Forschungsbereich der Pharmaindustrie durchaus innovativ ist, stellt sich der Bereich, welcher unter GxP-Regularien steht, eher zurückhaltend hinsichtlich der Digitalisierung dar. Digital erhobene Daten werden dort häufig in räumlich voneinander getrennten Anwendungen gespeichert und für die Weiterverarbeitung und Aufbewahrung ausgedruckt, nicht selten auch, um dann in anderen Systemen zur Weiterverarbeitung erneut eingegeben zu werden. Was zum Datenaustausch fehlt, sind die definierten, physischen Schnittstellen zwischen den einzelnen Anwendungen. Diese Verbindungen zu schaffen und Daten aus unterschiedlichen Quellen bei gleichzeitiger automatisierter Qualitätssicherung elektronisch für die Auswertung zusammenzuführen, ist ein ideales Anwendungsgebiet für ein behutsames, inkrementelles Vorgehen mit paralleler, kontinuierlicher Prozessverbesserung. Dies bietet sich vor allem für den Auf- oder Umbau komplexer Infrastrukturen an, die nicht in einem Stück angepasst werden können, weil dies z.B. zu riskant wäre.
Auf der einen Seite bedeutet dieses inkrementelle Vorgehen sehr viel häufiger Änderungen in bestehenden IT-Systemen als bei einer Implementierung in einem grossen Schritt der Fall wäre, auf der anderen Seite lassen sich diese kleinen Anpassungen aber viel effizienter testen.
Um sicherzustellen, dass ein neues Inkrement nicht die Ergebnisse vorheriger Inkremente beeinträchtigt und der validierte Zustand erhalten bleibt, werden entsprechende Unit- und Regression-Tests gleich mit der Entwicklung umgesetzt. Dabei stellen die Unit-Tests die technischen Tests von Einzelkomponenten dar und die Regression-Tests die wiederholenden Tests, die auch nach Änderungen die weiter bestehende Funktionalität nachweisen sollen. Diese Tests sollten dabei soweit wie möglich automatisiert durchgeführt werden, um den Aufwand bei den häufigen Wiederholungen zu reduzieren und ein jederzeit lauffähiges System zu garantieren.
Ein weiterer Vorteil besteht darin, dass Testfälle nicht mehr nachgelagert von unbeteiligten Personen erstellt werden, sondern in Teamarbeit von tatsächlich Beteiligten wie Architekten, Analysten, Entwicklern, Testern oder Benutzern, und dies bereits früh im Entwicklungsprozess.
Ein weiterer wichtiger Punkt im Zusammenhang mit einer inkrementellen Anpassung von Strukturen ist die Dokumentation als Bestandteil der Computersystemvalidierung. Eine traditionelle Validierungsdokumentation in elektronischen Dokumenten oder sogar auf Papier stößt bei einem inkrementellen Vorgehen an die Grenzen der Flexibilität. Hier bietet es sich an, elektronische Lösungen für das Lifecycle-Management von Anwendungen zu verwenden. Diese können die Traceability über Systeme hinweg sicherstellen, indem die einzelnen Anforderungen an die Anwendung mit der Implementierung und den dazugehörigen Tests bis hin zur Dokumentation aller Artefakte sauber und versioniert miteinander in Beziehung setzen können. Gleichzeitig bieten diese Systeme die Möglichkeit, die einzelnen Elemente wie Anforderungen, Testbeschreibungen und Testresultate in einem elektronischen Workflow genehmigen zu lassen. Bei diesem Vorgehen können dann in jedem (Liefer-)Inkrement einzelne Elemente durch neue ergänzt oder ersetzt werden, ohne die bereits bestehenden und genehmigten Elemente anfassen zu müssen, ohne dabei auf eine genehmigte Gesamtversion verzichten zu müssen.
Ist diese Vorgehensweise vereinbar mit den regulatorischen Vorgaben?
Fit for intended use, Patientensicherheit, Produktqualität und Datenintegrität: Über all diese Punkte ist ein Nachweis erforderlich, unabhängig von der Vorgehensweise der Umsetzung. Dies ist auch bei agilem Vorgehen kein Problem, ganz im Gegenteil. Während bisher übliche Vorgehensmodelle sehr aufwändig Qualität durch nachgelagerte Tests und Dokumentation nachzuholen versuchen, wächst die Qualitätssicherung bei agilen Ansätzen zusammen mit dem Produkt, also stets mit angemessenem Aufwand. Darüber hinaus lassen sich phasengetriebene Vorgehensweisen mit Agilität verbinden bzw. anreichern. Die Einführung dieses Vorgehens selbst erfolgt dann auch nicht mehr als Big-Bang-Approach, sondern wird selbst agil einführt.
Sollte jetzt also alles agil werden?
Was die konkrete Umsetzung agiler Methoden angeht, so hat sich die Business-Case-Betrachtung bewährt, bei der die Summe des Aufwands den zu erwartenden Einsparungen bzw. potenziellen Mehrwerten gegenübergestellt wird. Hierbei zeigt sich häufig, dass eine agile Vorgehensweise für die Einführung eines Out-of-the-box-Systems eher nicht wertschöpfend ist, für Anwendungen wie Dateninterfaces zwischen Standardanwendungen, Datenvisualisierung von Daten aus unterschiedlichen Quellen sowie Datenauswertung mit Hilfe von KI aber in der Regel schon.
Sehr oft werden solche Verfahren von SaaS-Anbietern verwendet, um kontinuierliche Verbesserungen und Erweiterungen in ihren Lösungen auszurollen. Hierbei kommt dann ein weiterer potenzieller Mehrwert zum Tragen: Die Möglichkeit der Sicherstellung einer Continuous Compliance über alle Änderungen im IT-System hinweg. Statt also immer und immer wieder nachgängig und aufwändig die Compliance der Systemlandschaft zu erneuern und nachzuweisen, wird sie begleitend kontinuierlich und mit verhältnismäßig geringem Aufwand aufrechterhalten.
Der agile Ansatz: konkretes Beispiel für den wirtschaftlichen Nutzen
In einem Data Warehause werden definierte Daten der Laborsysteme gesammelt, um systemübergreifend ausgewertet werden zu können. Dieses Beispiel bietet sich für eine agile Herangehensweise an, da bereits eine Verbindung eines Teils der vorhandenen Laborsysteme zu dem zentralen Data Warehouse einen messbaren Nutzen bringen würde. Es ist also sinnvoll, iterativ ein System nach dem anderen anzuschließen, anstatt in einem großen Projekt die gesamte Laborlandschaft auf einmal mit dem Data Warehouse zu verbinden. Genauso iterativ kann man bei der Auswahl der Daten, die in das Data Warehouse übertragen werden, vorgehen. Es kann zunächst mit einem kleinen Teil der Daten begonnen werden, die von analytischen Laborsystemen zur Verfügung gestellt werden, und diese Datenauswahl sukzessive erweitert werden.
Der Aufwand einer solchen agilen Herangehensweise darf nicht unterschätzt werden. Er besteht zusätzlich zu dem ohnehin notwendigen Aufwand bei der Entwicklung, dem Test und der Dokumentation der Schnittstellen. Dieser erhöhte Kommunikationsaufwand senkt allerdings das Risiko von Fehlern bei der Entwicklung, da das Erreichte immer wieder während des Entwicklungsprozesses mit den tatsächlichen Geschäftsanforderungen abgeglichen wird. Dadurch wird erfahrungsgemäß der Entwicklungsaufwand gesenkt.
Diesem Aufwand steht der Nutzen der Lösung gegenüber. In der Regel ersetzen solche Schnittstellenprojekte bereits vorhandene, mehr oder weniger manuell durchgeführte Datenzusammenführungen. Vorteilhaft ist dies insbesondere deswegen, weil solche manuellen Prozesse nicht nur einen signifikanten Aufwand, sondern auch ein Risiko hinsichtlich der Datenqualität bedeuten. Gut getestete und robust implementierte automatisierte Datenflüsse sind bedeutend zuverlässiger als manuelle Prozesse, in denen Eingabe- oder Kopierfehler durch Menschen immer ein Risiko darstellen.
Hieraus lässt sich eine Formel für den Mehrwert bei der Einführung agiler Prozesse ableiten:
((Manueller Aufwand pro Transaktion + Risikozuschlag Fehlerbehebung) * Anzahl Transaktionen) / (Entwicklungsaufwand (inkl. Qualitätssicherung))
Hier wird ersichtlich, wie das Potenzial für diese Art von Projekten mit der Anzahl der Transaktionen wächst. Ein weiterer Aspekt neben dem Aufwand und der Qualität ist die Geschwindigkeit. Automatisierte Schnittstellen stellen die Daten mehr oder weniger sofort bereit, es entstehen also keine Verzögerungen. So können Geschäftsentscheidungen auf einer soliden Datenbasis schnell getroffen werden und sind unabhängig von der Durchführung eines manuellen, potenziell fehlerhaften Prozesses.
Wer sich den Mehrwert dieses Vorgehens vorstellen kann, der kann auch einen Schritt weiter gehen und dies auf bislang unberührte Bereiche des Geschäftsbetriebs ausweiten. Wir möchten an dieser Stelle die Idee der Continous Compliance einführen – statt jedes Mal vor der anstehenden Zertifizierung den wertschöpfenden Betrieb stillzulegen die Compliance mit kleinen, aber sehr wertvollen Massnahmen aufrecht zu erhalten und dabei auch noch den Prozess der Compliance Sicherstellung kontinuierlich zu verbessern. Lassen Sie sich von uns vorstellen, wie dies möglich sein wird und warum sich dieses Vorgehen rechnen wird.
*Dr. Gerd Paulus (Advanced Project Services GmbH) berät Betriebe aus Pharmazie und Forschung zu verschiedenen Themen der Qualitätssicherung und begleitet diese bis zur erfolgreichen Akkreditierung. Gemeinsam mit Christoph Jeggle (Advanced Project Services GmbH, Senior CSV Consultant) und Markus Meuten (Agile Experts GmbH, Agile Coach und Trainer) entwickelt er agile Vorgehensweisen für diesen Fachbereich.
Be the first to comment