Wir leben in turbulenten Zeiten. Ein Effekt der ganzen Corona- und Covid-19-Gemengelage ist ein neue Wahrnehmung der Leit-Industrie in Deutschland. Wenn man heute im Familien- und Bekanntenkreis sich zum Video-Call verabredet, spricht man nicht mehr über die Anschaffung des neuen Familienautos oder die Assistenzsysteme des neuen Dienstwagens. Eine neue Industrie, die bisher nicht im Fokus der öffentlichen Wahrnehmung stand, rückt in die Mitte des Interesses: Die Hersteller von Medizintechnik und -geräten.
Laut der Angaben des statistischen Bundesamtes belief sich der Gesamtumsatz dieser Branche im Jahr 2018 auf ca. 30 Mrd. Euro. Man muss kein Hellseher sein, um den Unternehmen eine steigende Umsatzkurve zu prognostizieren.
In den letzten Jahren habe ich einige PLM-Implementierungsprojekte in dieser Branche begleiten und dabei auch die besonderen Herausforderungen kennen lernen dürfen. Und um eine besondere soll sich heute dieser Artikel drehen: Die Validierung des PLM Systems.
Bevor wir jedoch in die fachlichen Tiefen abtauchen, möchte ich aber noch einen Disclaimer einschieben: Dieser Artikel ist keine Rechtsberatung zum Bestehen von Audits der Aufsichtsbehörden. Er soll lediglich Anregungen und Hinweise zur Lösungsfindung geben, die auf meiner Projekterfahrung basieren.

Doch fangen wir einmal am Anfang an und fragen uns, warum ein PLM-System nach Regeln der Medizintechnik validiert werden muss. Und wer bestimmt eigentlich die Regeln für diesen Vorgang?
Als eine wichtige Quelle sei die ISO13485:2016, Kapitel 4.1.6 genannt, in dem explizit gefordert wird, dass die Hersteller Verfahren zur Software-Validierung für Software festlegen müssen, die das Qualitätsmanagementsystem nutzt. Diese Validierung sei risikobasiert durchzuführen. Zur weiteren Recherche sei hier auf die exzellenten Webseiten des Johner-Instituts verweisen.

Taucht man etwas tiefer in diese Validierungsanforderungen ein, liegt der Verdacht nahe, das lediglich wasserfallbasierte Projektvorgehensmodelle diese erfüllen können und zu einer auditsicheren Systemvalidierung führen. Diese Vorgehensmodelle konnten aber nicht den Nachweis erbringen, zum Erfolg von PLM-Projekten beitragen zu können.
Agile und inkrementelle Vorgehensmodelle sind an deren Stelle getreten und seit Jahrzehnten Stand der Wissenschaft für die Einführung von PLM-Systemen. Schaut man sich aber diese Vorgehensmodell an, stehen diese teilweise im Widerspruch zu den Forderungen zur Systemvalidierung. Welche Methoden und Aktivitäten- in “agilisch“ Artefakte – können diesen gordischen Knoten zerschlagen? Dieser Blogeintrag liefert eine Antwort auf diese Frage.

Dokumentation von Anforderungen:

Auch bei agilen Projekten werden natürlich Anforderungen an das zukünftige PLM-System aufgenommen. Das fängt bei einer generellen Scope Definition an und wird dann immer weiter herunter gebrochen und weiter detailliert. Verfahren und Methoden zur Businessanalyse gibt es viele und ich möchte hier nicht weiter ins Detail gehen, um den Umfang des Artikels nicht zu sprengen.
Meine Erfahrung zeigt einen klare Tendenz zu “User Stories” als meistverwendete Methode zur Dokumentation von Anforderungen. Und genau diese Dokumentation wird auch für die Systemvalidierung verlangt. Somit ist das gar kein Mehraufwand außer dem, die User Stories ordentlich zu dokumentieren. Und das macht man auch im agilen Kontext im Product Backlog und später dann im Sprint Backlog.

Der Teufel steckt hierbei eher im Detail der Dokumentation. User Story ist nicht gleich User Story und die beiden folgenden Beispiele illustrieren das:

• Als Anwender möchte ich meine Design Control Aktivitäten und Prozesse im PLM-System abbilden, um während eines FDA-Audits die geforderte Nachverfolgbarkeit nachweisen zu können
• Als Testingenieur möchte ich die genauen Parameter für das Maximalgewicht meines Testproduktes angezeigt bekommen, um diese mit der Anzeige der Laborwaage vergleichen zu können.

Beides sind formal korrekt dokumentierte User Stories, aber es ist deutlich der unterschiedliche Detaillierungsgrad zu erkennen. Die erste User Story ist eher so etwas wie der Intended Use des PLM-Systems und beschreibt eine Hauptanforderung, warum ein Medizintechnikunternehmen überhaupt ein PLM-System einführt. Der Aufwand für die Implementierung liegt hier eher bei Monaten oder sogar Jahren und viele Details sind noch vollkommen unklar und müssen entwickelt werden. Die zweite User Story ist da deutlich kleiner und genauer. Es liegt in der Natur der Sache, dass in einem PLM-Projekt User Stories dynamischen Änderungen unterliegen und somit unterschiedliche Reifegrade haben.

Die Anforderungen müssen reifen

Am Anfang stand das Wort des zukünftigen Nutzers eines PLM-Systems – in Form von Prozess-Schaubildern, Funktionsbeschreibungen, Definition von gewünschten Features und Schnittstellen und noch vielem mehr. Im Branchenjargon entspricht das dem Intended Use und den User Requirements des PLM-Systems. Der Reifegrad dieser Anforderungen ist aber noch weit davon entfernt, die notwendigen Details für eine Implementierung zu liefern. Es fehlen die Beschreibung von Systemumgebungen, Eingangsgrößen und Vorbedingungen, Akteuren und Berechtigungen und noch vieles mehr.
Des Weiteren bringt ein erfahrener Implementierungspartner seine Expertise ein, wie bestimmte Herausforderungen gut gelöst werden können. Oft können hier erhebliche Einsparpotentiale gehoben werden, wenn auf vorkonfigurierte oder bewährte Lösungen zurückgegriffen und nicht das Rad neu erfunden wird.
Und zu guter Letzt fehlen auch noch eine Reihe von Informationen, die für die Systemvalidierung benötigt wird. Das sind in erster Linie die Akzeptanzkriterien, deren klare Definition unabhängig von einer Validierung in jedem PLM-Projekt eine super Idee ist. Aber auch über mögliche Testszenarien, wie diese Akzeptanzkriterien geprüft werden sollen, müssen hier besprochen und dokumentiert sein.
Gerade bei stark integrativen PLM-Projekten ist die kontinuierliche Pflege der IT-Landkarte angebracht. Je nach Technologie und Architektur des gewählten PLM-Anbieters und der Komplexität der Anforderungen kann die Checkliste noch deutlich mehr Kriterien enthalten, bevor eine Anforderung “implementierungsreif” genannt werden darf. In der Sprache der Agilität wird das die “Definition of Ready DoR” genannt.
Die Erfahrung zeigt, dass der Aufwand des Reifens einer Kundenanforderung bis zum Erreichen der DoR von Anwenderseite fast immer unterschätzt, manchmal sogar in den Budgetplanungen gar nicht berücksichtigt wird.
Aus Validierungssicht ist die DoR aber ein großartiges Quality-Gate, das bei sinnvoller Kriterienliste nebenher den ersten Schritt der Systemvaliderung erledigt. Die Anforderungen sind klar dokumentiert, Akzeptanzkriterien definiert und Testszenarien und -fälle spezifiziert. Es kann mit der Umsetzung und Implementierung begonnen werden

Anforderungen werden zum Funktionen und Features

Das Implementierungsteam nimmt die DoR-reifen User Stories und Anforderungen auf und setzt diese um. Analog zur DoR gibt es auch eine Checkliste, deren Kriterien zur erfolgreichen Umsetzung der Anforderung erreicht werden muss: Die “Definition of Done DoD“.
Ein offensichtliches Kriterium ist das erfolgreiche Passieren der Testszenarien und Erreichen der Akzeptanzkriterien aus der DoR. Bei der Spezifikation der Testdaten sollten Sie nicht nur vom besten Fall ausgehen, auch falsche Eingaben ausprobieren. Des Weiteren ist das Beschreiten von alternativen Prozesspfaden eine gute Idee. Auch Code-Reviews oder die Prüfung auf Coding-Rules sind Mittel zu Steigerung der Softwarequalität. Die Dokumentation der Testergebnisse und dem Erreichen aller Kriterien der DoD genügt dann in der Regel als Nachweis für die Softwarevalidierung.
Hinweise und Empfehlungen zur richtigen Organisation und Toolunterstützung des Testens füllen Fachartikel und -Bücher. Als wichtige Erfahrungswerte sollte auf den Umstand hingewiesen werden, dass diese Tests keine einmalige Sache sind, sondern dass diese regressiv bei erneuten Änderungen am PLM-System erneut durchgeführt werden müssen. In der Praxis haben sich folgende Maßnahmen zur Reduzierung des wiederkehrenden Testaufwandes bewährt:

Risikobewertung

Die Risikobewertung hinsichtlich der Patientengefährdung ist ein Standardverfahren der Medizingeräteentwicklung und das gilt auch für die Validierung an das PLM-System. In den Projekten wird immer wieder intensiv über die reale Patientengefährdung bei einer Fehlfunktion des PLM-Systems diskutiert. Sicher kann man Szenarien herleiten, aber in diesen sind es immer einige Schritte vom der Benutzung des PLM-Systems hin zur Benutzung des Medizingeräts. Man sollte hier den gesunden Menschenverstand nicht außer Acht lassen und mit Augenmaß dieses Risiko bewerten. In einem vergangenen Projekt stellte dazu ein QM-Verantwortlicher mal fest, dass das Risiko aufgrund einer Fehlfunktion im PLM-System ernsthafte Probleme im Audit zu bekommen um Zehnerpotenzen höher ist als das einer Patientengefährdung.
Die Risikobewertung ist aber nicht nur ein erhöhter Aufwand ohne wirklichen Nutzen. Man kann dieses Werkzeug gut einsetzen, um kritischen Anwendungsfälle und Funktionen zu identifizieren und somit den Testaufwand zu skalieren. Und das Testen ist auch nicht die einzige risikominimierende Maßnahme. Schulungen und Awareness-Sessions oder zusätzliche Prüfschritte in den jeweiligen Prozessen können unter bestimmten Voraussetzungen deutlich günstiger als ein Softwaretest sein.

Das richtige Level finden

Wie vorhin an den beiden User Stories gezeigt, können Anforderungen unterschiedlich umfangreich und komplex sein. Eine Umsetzung in einem Sprint ist nicht möglich. Es ist somit notwendig, diese Anforderungen in kleinere Stücke zu schneiden und aufzuteilen. Die Risikobewertung wird dann für alle diese Anforderungs-Stücke vorgenommen, was zu einem doch recht erheblichen Aufwand führen kann.
Es kann daher sinnvoll sein, über das richtige Level nachzudenken, auf dem die Risikobewertung durchgeführt wird. Es erscheint wenig zielführend, auf granularem Detaillevel der Anforderungen eine Evaluierung durchzuführen. Ein Erkenntnisgewinn ist nicht gegeben und lediglich der Aufwand für die Erstellung und Pflege steigt.

Testautomatisierung

Wie schon oben erwähnt, ist die Systemvalidierung bei jeder Systemänderung erneut vorzunehmen. Ein bewährtes Mittel zur Reduzierung des Aufwandes für wiederkehrende Testfälle ist die Testautomatisierung, die mit Augenmaß eingesetzt werden kann. Es ist abzuwägen, bei welchen Testfällen sich der Aufwand zur Erstellung und Pflege der Automatismen gegen die Ersparnis der manuellen Testausführung lohnt. In diese Rechnung müssen auch die Anschaffungs- und Pflegekosten der Testwerkzeuge berücksichtigt werden.

Testreport der PLM-Systemhersteller

Einige PLM-Systemhersteller bieten sogenannte Validierungspakete an. Diese Dokumente erbringen den Nachweis der Systemvalierung für die Standardfunktionen des Systems. Diese Aussagen können natürlich herangezogen werden und sorgen somit für eine Verringerung des Validierungsaufwandes beim Medizingerätehersteller.
Das gilt aber nur, solange diese Standardfunktionen nicht angepasst, konfiguriert, ergänzt oder erweitert wurden. Auch Seiteneffekte sind dabei zu beachten und daher sind die Einspareffekte meist geringer als man sich das auf den ersten Blick erhofft hatte.

Was es noch zu beachten gilt

PLM-Systemhersteller und -Implementierungspartner bringen meist Wissen und Erfahrung zur Systemvalierung mit, aber verantwortlich ist das Medizingeräteunternehmen dafür. Somit ist es dafür zuständig, die Anforderungen an sein PLM-System zu dokumentieren und die Prozesse, die zu deren Reifung und Umsetzung führen. Ebenso sind es auch seine  DoR- und DoD Kriterien. Eine Herausforderung ist dabei mit Sicherheit die Dynamik, die eine PLM-Systemeinführung nunmal mit sich bringt. Neben der Hilfe und Unterstützung des Implementierungspartners gibt es auch sehr gute Softwarewerkzeuge, die dabei helfen und unterstützen können.