V-Modell vs. Pharma 4.0

Es wird oft beklagt, dass das V-Modell zu unflexibel ist und nicht „agil“. Darum werde ich auf dieses Thema heute genauer eingehen.

Das klassische V-Modell im pharmazeutischen Mittelstand

Das V-Modell, wie es klassisch seit Jahren / Jahrzehnten in pharmazeutischen Unternehmen angewendet wird, beschreibt die Validierung von Computersystemen. Dabei wird zunächst auf dem linken Ast des V eine URS / eine Benutzeranforderung / ein Pflichtenheft erstellt, mit den Anforderungen an das „WAS“ des Systems. Im Anschluss wird in einer FS (Funktionalen Spezifikation) / einem Lastenheftdokument das „WIE“ der Umsetzung beschrieben.

Am unteren Ende des V’s wird in der Installation Qualification (IQ) die Umsetzungsarbeit / das Design dokumentiert. Zum Schluss wird auf dem rechten Ast zunächst die Umsetzung der technischen Seite in der OQ (Operations Qualification) gegenüber der FS und schließlich aus Benutzersicht in der PQ (Process Qualification) geprüft. Zwischen den Dokumenten erfolgen übergreifend Risikobewertungen sowie das Tracing (Nachverfolgen von Anforderungen) bis zum Test. Für komplexere Themen werden die Phasen zusätzlich weiter aufgeteilt.

Warum funktioniert das V-Modell nicht (mehr)?

Was sind nun die Herausforderungen, denen in der Anwendung begegnet wird?

• Das URS-Dokument wird als Anforderung des Unternehmens an einen Lieferanten verstanden. Dadurch fehlen wichtige organisatorische Anforderungen an das Gesamtsystem, die für den regulierten Betrieb allerdings extrem wichtig sind.
• Die URS-Dokumente brauchen ewig für den Unterschriftenumlauf, da sie von vielen unterschrieben werden müssen. Ein weiterer Nachteil daran ist, dass die Inhalte so komplex sind, dass keiner der Unterschreibenden sie vollständig versteht.
• Es ergeben sich Dopplungen zwischen Dokumenten, die zu Systemen gehören, die gemeinsam einen Prozess bedienen. In der Folge laufen diese Anforderungen auseinander und wiedersprechen sich im schlimmsten Falle sogar.
• Eine große Unbekannte sind immer wieder die Schnittstellenbeschreibungen. Wem gehören die Dokumente, wer macht was, was kommt rein, von wo nach wo wird getestet, usw.
• Anforderungen sind sauber nachzuverfolgen.
• Geschäftsanforderungen gehen verloren oder werden an beschaffte Systeme angepasst.
• Systeme verlieren ihren Kontext oder werden außerhalb des geschäftlichen Kontext entwickelt.

Ein Ansatz: Das V-Modell 4.0 und eine serviceorientierte Validierung

Meiner Meinung nach haben wir das V-Modell in den letzten Jahren zu etwas Starrem und Unflexiblem gemacht. Wir haben ein Konstrukt erschaffen, das für die heutige Zeit so nicht mehr funktioniert. Wir haben einen Berg an Regeln für einfache Systemarchitekturen kreiert und versuchen diesen nun auf komplexe Landschaften anzuwenden. Das kann nicht funktionieren!

Was sind die Basisanforderungen für die Validierung

Wir wollen beweisen, dass wir einen Prozess wiederholbar mit gleich guter Qualität ausführen können. Das war es auch schon 🙂 Der Konstrukt mit der Computer-System-Validierung mit allem Drum und Dran wurde entworfen, als die ersten Computersysteme aufkamen, die nicht direkt an Anlagen gebunden waren und damit aus dem Scope der Validierung fielen. Seither hat sich vieles geändert. Die Anzahl der Computersysteme pro Anlage hat deutlich zu genommen, die Vernetzung ist drastisch gestiegen und Abgrenzungen zwischen Systemen sind schwer bis unmöglich.

CSV ist FUBAR (fucked up beyond all repair)

Aus diesem Grund müssen wir das bestehende CSV-Konstrukt von der Basis an überarbeiten.

(1) Das erste grundlegende Problem am heute gelebten CSV-Konstrukt ist, dass wir auf Ebene der Systeme denken. Besser ist es jedoch, die Umgebung aus der Sicht der Prozesse zu betrachten. Denn aus den Prozessen ergeben sich die vorhandenen Risiken und damit auch wie wichtig ein System und der Kontext eines Systems ist.

(2) Das zweite Grundproblem ist das „Ownen“ von Anforderungen – Wer ist verantwortlich für eine Anforderung und wer testet sie?

(3) Das dritte Grundproblem ist die fehlende Nachverfolgbarkeit von Änderungen auf Konfigurationsebene.

Die Lösungen für diese drei Basisprobleme sind naheliegend:

1. Die User Requirements müssen wieder auf die Benutzerebene – ohne Wenn und Aber, keine technischen Anforderungen, keine „IT Requirements“. Die Benutzeranforderungen sollen den Prozess beschreiben oder auch auf „neudeutsch“ den Use Case.
2. Abschnitte in Validierung und Anforderungen werden als Services / Dienste betrachtet. Jeder Beteiligte betrachtet nur seinen direkten Nachbarn und Anforderungen werden zwischen diesen bindend vereinbart.
3. Als Lösung für die dritte Herausforderung bedienen wir uns im Release Management der Software Entwicklung. Neue Prozessversionen werden dabei als Releases betrachtet.

Was bedeutet das nun in der Praxis? Am äußeren Bild des V ändert sich nicht viel, aber in der Anwendung.

V-Modell 4.0 zur Unterstützung von Digitalisierungsprojekten

Der Prozesseigner beschreibt in der URS seinen Use Case, also seinen Prozess und in der FS dann die Umsetzung. Manchem wird hier bei genauerem Betrachten eine Lücke auffallen. Was passiert, wenn ein System mehrere Prozesse hat oder mehrere Systeme einen Prozess bedienen? Dies ist schließlich nicht selten der Fall. Aus diesem Grund wird zwischen dem Prozess und dem Systemeigner eine zusätzliche Ebene, die Ebene der Architektur, eingezogen.

Der Prozesseigner beschreibt jetzt also seine geschäftlichen Anforderungen und stellt diese an das Architektur-Team. Dort wird geprüft, welche Systeme für die Umsetzung erforderlich sind und ob Neuentwicklungen oder Beschaffungen benötigt werden. Jetzt listet das Architektur-Team die Anforderungen für die beteiligten Systeme auf (Requirements Engineering) und schließt den Vertrag mit den System Ownern ab.

Das Vorgehen mag auf den ersten Blick kompliziert klingen. Es macht den Ablauf aber für alle Beteiligten einfacher und unkomplizierter. Denn jetzt muss jeder nur noch die Dokumente unterschreiben, die er versteht und die er bewerten kann. Außerdem werden dadurch die Dokumente kleiner, wodurch sich die Geschwindigkeit und die Flexibilität erhöht.

Steigerung der Datenintegrität durch serviceorientierte Validierung

Hier gibt es drei Grundregeln:

1. Jeder, der eine Anforderung annimmt, macht sich diese zu eigen.

• Wer eine Anforderung annimmt und diese nicht alleine erfüllen kann, gibt diese angepasst entsprechend weiter, um selbst arbeitsfähig zu bleiben. Wie zum Beispiel die Lohnbuchhaltung, die Gehälter auszahlen soll, dies aber nur kann, wenn die Abteilungsleiter ihr die geleisteten Arbeitszeiten zur Verfügung stellen.

2. Verantwortlich für das End-to-End-Testen ist der Owner der auslösenden Geschäftsanforderung.

• Oft sind mehrere unterstützende technische Systeme beteiligt. Die Verantwortung für das End-to-End-Testen verbleibt aber immer bei der auslösenden Geschäftsanforderung.

3. Jeder betrachtet nur seinen direkten Nachbarn. Datenübergaben und Prüfungen werden in den Schnittstellen durchgeführt.

• Dadurch sind klare Abgrenzungen und auch die Einbindung von Cloud-Diensten möglich.

Tracking von Prozessänderungen in Systemen durch Release Management

Ähnlich wie Software versioniert wird, können auch Features von Prozessen oder Systemen versioniert werden. Dadurch erhalten wir eine vollständige Nachverfolgbarkeit vom Prozess bis hin zur Umsetzung in den einzelnen Systemen.

Beispiel: Das Feature „elektronische Bezahlung“ wird im Prozessverkauf 2.3 mit den Systemen ERP2.7 und Zahlungsgateway 1.4 und den Softwareständen …. realisiert. Wir bilden also auf jeder organisatorischen Ebene Features, die wir zu Releases bündeln.

Fazit:

Damit wir komplexe Systeme validieren können, müssen wir neue Wege gehen. Was ist Ihr Ansatz?

Mit chaotischen Grüßen,
Christof Layher