Agilität bedeutet aktiv agieren und dabei das Wissen aller Beteiligten zur Optimierung einzubeziehen. Um Prozesse in agiler Vorgehensweise zu verbessern, ist eine Veränderung in inkrementellen Schritten geeignet. Bereits während des Projektverlaufs wird das Optimierungspotenzial erkannt und kann schrittweise umgesetzt werden. Am Beispiel eines Data Warehouse der Pharmaindustrie wird Aufwand und Nutzen gegenübergestellt.

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 bis 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.

Agile Vorgehensweisen

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 voranzugehen. 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 bspw. 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.

Stufenweises Prüfen und Verbessern

Beispiele für Bereiche, in denen sich das inkrementell (also stufenweise bei gleichzeitiger Busi­ness-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 zum Beispiel 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 großen 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 so weit wie möglich automatisiert durchgeführt werden, um den Aufwand bei den häufigen Wiederholungen zu reduzieren und ein jederzeit lauffähiges System sicherzustellen.

Optimierung in Teamarbeit

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. Dazu werden 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 gesetzt. Gleichzeitig bieten diese Systeme die Möglichkeit, die einzelnen Elemente wie Anforderungen, Testbeschreibungen und Testresultate in einem elek­tronischen 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. Außerdem muss nicht auf eine genehmigte Gesamtversion verzichtet werden.

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, Datenvisu­a­li­sierung 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 Com­pliance der Systemlandschaft zu erneuern und nachzuweisen, wird sie begleitend kontinuierlich und mit verhältnismäßig geringem Aufwand aufrechterhalten.

Beispiel für den wirtschaftlichen Nutzen

In einem Data Warehouse 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 Labor­systeme 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.

Das Potenzial für diese Art von Projekten wächst mit der Anzahl der Transaktionen. 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.

Die Autoren:
Dr. Gerd Paulus, DiQualis Schweiz
Markus Meuten, Agile Experts
Christoph Jeggle, DiQualis Schweiz