Systemvalidierung von PLM-Systemen in der Medizingeräteindustrie

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.

Bild von <a href="https://pixabay.com/de/users/RobynsWorld-1577075/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2610509">Robyn Wright</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2610509">Pixabay</a>

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“.
Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3382521">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3382521">Pixabay</a>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

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3075837">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3075837">Pixabay</a>

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.

Guten Tag, mein Name ist PLM und womit kann ich helfen?

Als PLM Consultant ist es ja ein wenig wie mit der Polizei, man wird nur dann gerufen, wenn etwas im Argen liegt. Bei der Polizei geht es da eher um gesellschaftliche und rechtliche Konflikte, bei uns PLM-lern eher um betriebswirtschaftliche oder technische Probleme. Und genau um diese Auslöser, die zu einem Anruf bei uns führen, geht es in meinem heutigen Artikel.

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=257882">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=257882">Pixabay</a>

Auslöser gibt es derer viele und oftmals spielt das Thema PLM zu diesem Zeitpunkt noch gar keine Rolle. Eine industrieübergreifend recht oft genannte Herausforderung ist, dass die Produktentwicklung im Vergleich mit den Mitbewerbern zu lange dauert und/oder dass die Kosten dafür zu hoch sind. Die Konkurrenz kann das einfach schneller, besser und zu geringeren Kosten, was im Wettbewerb ein klarer Nachteil ist.

Wie gesagt, diese Erkenntnis wird nicht aus einem ingenieurigen PLM-Kontext heraus gewonnen, sondern ist eher eine aus den üblichen betriebswirtschaftlichen Auswertungen und Bilanzen. Und die Inhaber, Geschäftsführer und CXOs dieser Welt wollen natürlich dieses Problem gelöst haben. Und noch immer denkt niemand an den Kauf von PLM-Software.

Die Ursachenforschung beginnt und das jeweilige Unternehmen stellt sich die Frage nach den Gründen. Warum sind wir langsamer und  später dran als unsere Mitbewerber? Warum müssen wir deutlich mehr Geld in die Hand nehmen, um unsere Produkte auf den Markt zu bringen? Warum adaptieren unsere Mittbewerber eher neue Trends und gehen in neue Märkte? Und wo geht unsere Effizienz in die Binsen? Noch immer hat niemand das Wort PLM in den Mund genommen.

Die Antworten auf diese Fragen können sehr vielfältig sein und sind natürlich abhängig von der konkreten Situation. Aber es gibt natürlich einige Beispiele:

A) Unsere Mitarbeiter benBild von <a href="https://pixabay.com/de/users/AbsolutVision-6158753/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2636259">Gino Crescoli</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2636259">Pixabay</a>ötigen sehr viel Zeit, um Informationen für ihre täglichen Aufgaben zu finden und müssen zusätzlich Aufwände investieren, um die Gültigkeit und Aktualität dieser Daten zu überprüfen. In regulativen Branchen wie der z.B. Medizintechnik fällt so etwas auf, wenn in der Verifikation gar nicht klar ist, gegen welche Anforderungen geprüft und getestet werden soll. Oder in der Simulation müssen sich die notwendigen CAD Daten mühsam zusammengesucht werden, die im Entwicklungsprozess auch noch ständigen Änderungen unterliegen. Oder das Supply Chain Management hat Schwierigkeiten nachzuvollziehen, welche Daten jetzt in welchem Stand an Zulieferer gegangen sind.

B) Unsere Produkte müssen vor dem Markteintritt von Aufsichtsbehörden zugelassen werden und wir bekommen diese Erlaubnis immer sehr spät. Eigentlich zu spät, da wir technisch bereits in der Lage wären, diese Produkte zu produzieren und auszuliefern. Die Gründe sind vielschichtig. Es kann sein, dass wir erst sehr spät im Produktentwicklungsprozess in der Lage sind, die notwendigen Unterlagen den Aufsichtsbehörden zu überlassen. Oder die Aufsichtsbehörde hat Rückfragen oder bemängelt den Inhalt.

C) Unsere Marktanteile sinken, weil unsere bisherigen Kunden den höheren Innovationsgrad der Wettbewerbsprodukte honorieren. Die Ursache für das Verpassen von Trends kann in der fehlenden Weiterbildung der Mitarbeiter aus der Produktentwicklung liegen. Sie waren lange nicht mehr auf Tagungen oder haben lange keine Messen mehr besucht. Sowohl die interne als auch die externe Weiterbildung wurden vernachlässigt.

Wenn wir uns diese drei Antworten mit der PLM-Brille ansehen, dann kann ein PLM-System bei A) und B) eine wertvolle Unterstützung zur Lösung dieser Herausforderungen sein. PLM-Systeme sind prädestiniert dafür, den Informationsfluss rund um die Produktdaten zu verbessern und Menschen, Systeme, Prozesse und Daten zusammenzubringen. Somit könnten Analyseergebnisse wie diese der Start für eine PLM-Initiative sein und gleichzeitig definieren sie auch die ersten Erfolgsfaktoren.

Bei C) ist das eher nicht der Fall, hier sollten andere Maßnahmen zur Abstellung und Lösung ergriffen werden. Das Erarbeiten von Weiterbildungskonzepten oder die Bereitstellung von Budget für den Besuch von Tagungen und Messen – PLM kann vieles, aber hier ist es eher nicht so wirksam.

Die Out-of-the-box Lüge in PLM-Systemauswahlen

Nach zwei wirklich aufschlussreichen Artikeln des Gastautors Markus Ripping bin ich jetzt mal wieder dran mit einem Blogpost. Und der provokant gewählte Titel deutet auch schon die Richtung an. Es wird wieder etwas praktischer und geht und die Auswahl des richtigen PLM-Systems – wenn es das eine “richtige” überhaupt gibt.

PLM Änderungen sind notwendig

In den letzten 20 Jahren konnte ich an vielen Projekten mitarbeiten, die sich mit der Auswahl eines geeigneten PLM-Systems beschäftigt haben. Dabei habe ich beide Seiten kennengelernt, sowohl die des Kunden als auch die des potenziellen Software-Lieferanten. In den allermeisten Fällen wird im Rahmen einer mehr oder minder ausführlichen Analysephase ein Kriterienkatalog erarbeitet, in dem basierend auf den aktuellen Geschäftsprozessen Anforderungen an das zukünftige Wunschsystem zusammengefasst werden.

Dieser Fragebogen kann auch gerne mal eine mehrere Quadratmeter große Exceltabelle sein mit den Antwortmöglichkeiten “Out-of-the-box”, “Anpassung mit geringem Aufwand”, “Anpassung mit höherem Aufwand” und “Individuelle Entwicklung”.

In einigen, wenigen Fällen wird auch nach nicht funktionalen Anforderungen (z.B. notwendige Infrastruktur, Integrationsfähigkeiten, Anbindung verteilter Standorte, …) gefragt, um diese ebenfalls zu bewerten. Das passiert aber eher seltener, meistens bleibt es beim Abfragen Funktionen und Features.

Die nach besten Wissen und Gewissen von den potenziellen Softwarelieferanten gelieferten Antworten werden dann verglichen und gewichtet und übrig bleiben dann die Systeme, die in die engere Auswahl kommen. An dieser Stelle möchte ich dem geneigten Leser, der sich hier wiedererkennt, zwei Fragen stellen:

Denken sie bitte 3-5 Jahre zurück. Wie hätte dort ihr Fragenkatalog ausgesehen? Ist er komplett identisch mit dem, den sie heute entwickelt haben und Ihre Geschäftsprozesse und Daten haben sich in den letzten 3-5 Jahre nicht weiterentwickelt?

Denken Sie einmal 3-5 Jahre voraus. Wird der Kriterienkatalog in der Zukunft komplett identisch sein mit dem, den sie heute haben? Lesen Sie dazu auch den Artikel von Markus zum Thema Dynaxity.

Wenn sie in beiden Fällen absolut sicher sind, das sich Ihre Anforderungen an ihr PLM-System über 6-10 Jahre nicht ändern werden, dann bringt dieser Artikel ihnen keinen Erkenntnisgewinn. Dann werden Sie mit der oben geschilderten Auswahl das perfekte System für sie finden.

Es ist natürlich überhaupt nichts falsch daran, nach einer möglichst großen Schnittmenge zwischen eigenen Anforderungen und Out-of-the-box-Features zu suchen, ganz im Gegenteil. Natürlich gibt es eine ganze Reihe Anwendungsfälle, die eher stabil sind und bleiben und die wollen Sie natürlich möglichst “ready for use” vorfinden.

Aber mit an Sicherheit grenzender Wahrscheinlichkeit werden sich die Anforderungen an Ihr PLM-System ändern, einige werden hinzukommen, andere werden gar nicht mehr so wichtig sein und vielleicht ganz wegfallen. Daran besteht kein Zweifel. Und genau dieses immens wichtige Kriterium spielt in fast allen PLM-System Benchmarks überhaupt keine Rolle und wird immer “vergessen”: Wie gut, wie einfach, wie schnell und mit welchen Wissen kann ich mein System an zukünftige Anforderungen anpassen? Es ist schließlich ihr PLM-System und nicht das PLM-System, das ein PLM-Systemhersteller für geeignet für sie hält. Und im Gegensatz zu anderer Unternehmensoftware reden wir hier von Daten und Prozessen rund um ihr Produkt. Exakt dem “Ding”, mit dem sie ihr Geld verdienen, das etwas einzigartiges beinhaltet, dass sie von Ihrem Wettbewerb unterscheidet. Und wir sprechen über Daten und Prozesse, die das Herz, Wirbelsäule und Nervenbahnen Ihres Unternehmens bedeuten und diese gehorchen eher nicht vordefinierten Features, die auch Ihre Marktbegleiter einsetzen.

PLM Systemvergleiche vollständig durchführenDas sie ihr PLM-System an Ihre individuellen Bedürfnisse anpassen werden, ist unausweichlich. Und genau für diese Fall schauen sie genau hin, was ihre potenziellen Anbieter können. Vertrauen sie nicht auf schicke Powerpoints oder vorgefertigte Presales-Szenarien. Probieren Sie es aus, wie es sich anfühlt, das PLM-System zu verändern, anzupassen, neue Anforderungen an Daten und Prozesse abzubilden. Was müssen Sie dafür in Ausbildung investieren? Werden spezielle Entwicklungsumgebungen und besondere Kenntnisse dafür benötigt? Kann ich Anpassungen überhaupt selbst vornehmen oder muss ich immer einen Spezialisten dafür beauftragen? All diese Fragen werden sehr schnell sehr wichtig für einen PLM-Systemanwender und müssen daher in meinem Benchmark eine signifikante, wenn nicht sogar die signifikanteste Rolle spielen.

Warum machen wir nicht PLM End2End?

Markus Ripping, der Autor des letzten Gastbeitrags, greift in seinem neuen Artikel weitere Aspekte der Digitalisierung und der vor uns stehenden Herausforderungen im PLM Business auf und teilt diese Gedanken mit der geneigten Leserschaft. Vielen Dank dafür. Ich selbst habe einige neue Erkenntnisse gewinnen können. Aber genug der Vorrede, hier ist der Artikel:

Bild von <a href="https://pixabay.com/de/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3746923">Gerd Altmann</a> auf <a href="https://pixabay.com/de/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3746923">Pixabay</a>

Bild von Gerd Altmann auf Pixabay

PLM ist ein in der Industrie seit Jahrzehnten etablierter Begriff. Dennoch sieht man erst in den letzten Jahren eine tatsächliche Bewegung hin zum Managen eines kompletten Lifecycles. Vorher war der unbestrittene Fokus auf Engineering-Themen und viel PLM war eigentlich nur PDM. Was wird es uns bringen, wenn wir unser Produkt wirklich von der Wiege bis zur Bahre oder besser noch – um beim Bild des Lebens zu bleiben – von der Zeugung bis zur abgeschlossenen Kompostierung begleiten? Wie wird sich PLM verändern, wenn wir Marketing-Aspekte an einem der Enden und Service & MRO-Aspekte am anderen Ende sowie alles dazwischen wirklich integrativ erfassen würden wollen? Wie schließen wir den Kreis und lassen frühe Phasen der Produktentstehung an Erkenntnissen späterer Phasen nutznießend teilhaben?

Zum Ende meines letzten – etwas ketzerisch geschriebenen – Blogbeitrages hatte ich die Frage in den Raum gestellt, warum wir PLM eigentlich nicht mal wirklich End2End machen. Ganz einfach: Weil es nicht ganz einfach ist.

Die Digitalisierung schreitet voran, kaum eine Industrie kann sich ihr verschließen. Neue Produktkategorien, neue Geschäftsmodelle, neue Vertriebswege und –strategien. Dynaxity ist King. Interessant ist, dass wir im PLM heute weiterhin im Wesentlichen Strategien und Werkzeuge sehen, die Struktur und Ordnung schaffen wollen. Das sind im Bild des Dynaxity-Modells alles Maßnahmen für die zweite, also dynamische Zone. Befragt man eine Suchmaschine nach dem Begriff Management, ist der erste Vorschlag die Definition „The process of dealing with or controlling things or people“. Struktur und Ordnung ist Kontrolle. Das „Management“ in PLM verkommt damit zu einem reinen Verwalten.

Realität ist aber, dass wir uns auf die Zukunft einstellend damit abfinden müssen, dass Digitalisierung turbulent (Dynaxity Zone 3) ist. Bei Turbulenzen muss man anpassungsfähig sein. Liebgewordenes über Bord werfen. „Dealing with“ scheint also der Knackpunkt zu sein. Leo schlägt als erste Übersetzung für „to manage“ vor: „etwas bewältigen“. Bewältigen werden wir aber in größeren Firmen sicher nichts allein. Teamarbeit ist gefragt.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger.

Wie finde ich in einem komplexen und sich stetig verändernden System immer wieder neu die Personen und Informationen, die ich zur Bewältigung meiner Aufgabe benötige? Und welche Informationen benötige ich überhaupt? Für mich fallen seit geraumer Zeit die Grenzen, die PLM früher auf Engineering-Aspekte eingeschränkt haben. Heute muss ich noch während der Entwicklung wissen, ob der Markt mein Produkt überhaupt noch nachfragt. Ich muss Wartbarkeit definieren, noch bevor ich weiß, ob ich das Produkt verkaufe oder als Service anbiete. Fundamentale Fragen eines Wertschöpfungsprozesses verändern sich, während der Prozess durchlaufen wird. Nichts kann mehr schön in Ruhe seriell abgearbeitet werden.

Deswegen muss ich in Zukunft alle Silos durchbrechen. Ich muss im Marketing verstehen, was Corporate Development macht. Denn nur so, kann ich einen Development Funnel sicherstellen, der mir die richtigen Produkte zur richtigen Zeit marktfertig bereitstellt. Ich muss aber auch mein eigenes Product Portfolio Management mit der Zulieferkette in der Fertigung und Produktion verbinden. Immerhin drehen sich die Uhren auch bei unseren Lieferanten immer schneller. Und Druck können wir da auch nicht mehr wie früher ausüben. Mit IIoT bekommen wir Zugriff auf Erkenntnisse aus dem Betrieb unserer Produkte, die von unschätzbarem Wert für R&D sind und noch vor 5 Jahren undenkbar waren. Gleichzeitig wird der Product Ideation Prozess immer schnelllebiger und braucht Erkenntnisse aus der Marktforschung. usw. usw. usw.

Bild von Gerd Altmann auf Pixabay

Plötzlich müsste eigentlich jeder mit jedem sprechen. Aber man kennt sich gar nicht persönlich. Und man wird sich auch nicht kennen, denn Dynamik und Wachstum schaffen auch selbst auf der HR-Front neue Hürden. Früher kannte man sich, arbeitete Jahre lang mit- und nebeneinander. Im heutigen Markt ist das Wachstum enorm, die Fluktuation größer, Platz nach oben für Beförderungen gegeben und Job-Hopping innerhalb von Konzernen ebenfalls in Mode. „Corporate Social Networks“ werden wichtig und basieren nicht mehr auf alten Seilschaften. Eins eint alle Beteiligten: Produktdaten.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger.

Aber was sind eigentlich Produktdaten? Die Frage bietet Raum, ein ganzes Buch darüber zu schreiben. Und eine ganze Reihe schlauer Leute hat das bereits getan. Doch auch diese Grenzen verschwimmen mit der Zeit. Ich arbeite bei einem Hersteller diskreter Produkte, die bei unseren Kunden in der Prozessindustrie eingesetzt werden. Ich denke heute darüber nach, wie ich die erzeugten Prozessdaten meiner Kunden „tesseliere“ und in unseren R&D und Portfolio Management Prozess zurückfädele. Vor 5 Jahren hipper Zukunftskram, heute aus meiner Sicht nötige Maßnahme, mich auf die nahe Zukunft vorzubereiten. Das schafft aber ganz neue Herausforderungen auf der Zusammenarbeitsebene. Infrastruktur ist da noch das trivialste Problem. Wir brauchen juristische Vereinbarungen, um überhaupt Zugriff auf Relevantes zu bekommen. Das geht meist nicht gut im Kunde/Lieferant-Verhältnis, besser schon wenn man als Partner auf Augenhöhe kooperiert. Aber auch bei Partnern macht man sich Gedanken über den Wert von Daten. Wir wollen lernen. Unsere Kunden wollen aber nicht, dass wir gleich ihr ganzes Geschäft mitlernen und dem nächsten Konkurrenten anbieten. Intellectual Property wird da plötzlich bis auf Attribut- und Transaktions-Ebene ein relevantes Thema, mit dem sich auch Legal & Compliance auseinandersetzt. Noch ein Player im Boot.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger.

Ich mag daher auch nicht mehr die traditionelle Abgrenzung ERP <-> PLM mit überschaubarem Overlap. PLM sollte mehr Strategie, ganzheitliches Konzept oder von mir aus auch Vision sein und nicht auf das reine Toolset reduziert werden. Am Toolset und dessen Implementierung halten sich eh zu viele Leute auf. Die eierlegende Wollmilchsau gibt es nicht und wird es auch entgegen der Beteuerung der einschlägigen Anbieter nicht geben. Außerdem wird es weniger denn je eine statische IT-Landschaft sein. IT-Individualismus auf die eigenen Bedürfnisse ist gefragt. Die lässt sich mit dem Wissen über Informationsflüsse aber besser kleinteilig bewerkstelligen, als mit monolithischen Single-Point-Of-Truth Strukturen. Ich bin schon seit jeher Freund von Single-Source-Of-Truth in Abgrenzung zu Single-Point. Pro Information eine Quelle ist entscheidend, um Redundanzen aus dem System zu nehmen, manuelle Prozesse zu reduzieren und Fehleranfälligkeit in den Griff zu bekommen. In wie vielen Systemen die Information eines einzelnen Ursprungs konsolidiert und konsumiert werden hat für mich keine besondere Relevanz. Für die Endabnehmer aber schon. Die mögen es, in Ihnen vertrauten Systemen zu arbeiten. Alles ablösen und die PLM/ERP Rundum-Sorglos-Lösung bereitstellen wird massive Change-Management-Schockwellen auslösen. Minimalinvasiv ist das Stichwort. Kleinteilige, individuelle Lösungen, im Zweifel im Eigenbau und gerne proprietär – denn wo steckt Intellectual Property nicht in Zukunft, wenn nicht im Wissen um die sinnvolle Bearbeitung und Verwendung der eigenen Daten. Und ganz praktisch: Der Ansatz ist auch noch super kompatibel mit einem der vielen anderen Buzzwords der Digitalisierung: Agile! Auch bei Agile geht’s im Übrigen um Kommunikation und Collaboration.

PLM wird damit für mich zu einem Kommunikations- und Collaborations-Enabler. Nicht mehr und nicht weniger. Das kann man gar nicht oft genug wiederholen!

Grad noch Digital Twin, jetzt Digital Thread – Warum wir am Ende doch nur PLM machen

 

Gerade eben saß er noch auf der Blogcouch und hat ein Interview gegeben, jetzt teilt er sein Wissen und seine Erfahrungen auch in einem Gastbeitrag. Ich freue mich sehr darüber, Markus Ripping, global verantwortlich für das PLM bei Sartorius, als Gastautor für den PLM-Blog gewonnen zu haben. Aber jetzt genug der einleitenden Worte und viel Freude beim Lesen seines Artikels.

Insbesondere, weil PLM schwer zu erklären ist und sich noch schwerer im Innenverhältnis von Industrie-Betrieben wirtschaftlich verkaufen lässt, wird in der Branche in den vergaIst der Digital Thread das neue PLM?ngenen Jahren in der Hoffnung auf Aufmerksamkeit bei Entscheidern eine Buzzword-Sau nach der anderen durchs Dorf getrieben. An den wesentlichen Schwerpunkten der PLM-Arbeit und an der Wichtigkeit, insbesondere in Hinblick auf die für viele Industrien bitter nötige Digitalisierung, hat sich aber nichts geändert. Buzzwords schaffen Begehren auf der C-Ebene, welche aktuell bei der Trägheit und Change-Aversion bestehender Organisationen zum Scheitern verurteilt sind. PLM ist schon schwer genug. Wir sollten es nicht noch versuchen, sexy zu machen.

In den Jahren, in denen ich mich im PLM-Umfeld bewegt habe war der Begriff „Product Lifecycle Management“ nie stabil. Über die Jahre sind verschiedene Themenkomplexe hinein- und wieder herausinterpretiert worden. Aber der Terminus PLM war immer da. In den letzten Jahren hat sich das geändert. Zu meinem großen Bedauern.

Früher war es der nächste logische Schritt auf dem steinigen Weg eines professionalisierten Produktentstehungsprozesses. Man nannte es PLM, auch wenn man eigentlich noch PDM machte. Das war in einer Zeit, als es auch schon schwierig war, PLM zu verkaufen. Denn es war schon immer schwierig, PLM zu verkaufen. Ich komme aus der Beratung, aber ich meine nicht PLM-Beratung. Ich meine den Buy-In des Industrie-C-Level.

Warum wir uns das alles überhaupt antun? „PLM implementieren ist leichter, als es zu verkaufen“. Wir kennen alle die Sprüche. Man hat sich abgemüht, Gelder zu bekommen und hat komplexeste Systemlandschaften gebaut, alles basierend auf anfangs ziemlich dünnen Business Cases und mit optimistischen ROIs. Warum? Weil PLM Grundlagen schafft. Weil PLM vieles besser macht, aber fast nichts davon direkt. Im PLM-Umfeld gibt es eine Häufung von Berufs-Optimisten. Leute, die die Probleme von heute schon vorgestern gesehen haben. Und die versucht haben, Weichen zu stellen für eine Zukunft, die sie selbst noch nicht verstanden. Man kannte zwar nicht den Weg, aber zumindest hatte man eine Ahnung vom Ziel.

Wohin geht PLM?Heute kennen wir die Ziele. Die „hippen“ High-Tech-Unternehmen machen uns vor, wie man agil wird und durch Agilität weiterkommt. Wie man nicht mehr nur Produkte besser macht, sondern gleich komplett neue Business-Modelle schafft – am besten gleich ganz ohne lästige physische Produkte. Everything as a Service. Das schafft Begehrlichkeiten. Insbesondere bei den hochrangigen Entscheidern. Begehrlichkeiten, die PLM zwar nicht alleine befriedigen kann, für dessen Befriedigung in vielen Industrien PLM aber einer der Schlüssel-Enabler sein kann.

Warum geht also PLM nicht ab wie ‘ne Rakete? Weil Entscheider PLM seit x Jahren kennen! „Wie kann etwas, das wir vor 15 Jahren schon versucht haben uns jetzt plötzlich in die goldene Zukunft bringen? Geht doch nicht!“ Eine genauso verständliche wie falsche Argumentation. Unsere Reaktion als PLM-Community? Anstatt PLM heute richtig zu machen mit den Mitteln, die uns 2018 frei zur Verfügung stellt und nicht mehr hilflos zu frickeln, wie es vor 15 Jahren zwangsweise nötig war, fallen wir auf die Argumentation herein und geben dem Kind einen neuen Namen. Wir nennen das ganze nicht mehr Produkt-Lifecycle-Management.  Neue Namen gibt es genug. Neue hehre Ziele ebenso.

PLM war zu abstrakt. Unter einem Digital Twin kann sich jeder etwas vorstellen – glaubt jeder, sich etwas vorstellen zu können. Aber für viele aktuelle Firmen ist ein (vollständiger) digitaler Zwilling heute genauso unerreichbar wie (noch) unnütz.

Genauso unstrukturiertes Datensammeln und -kippen in einen Data Lake. „Heute anfangen, keine Daten mehr verloren gehen lassen!“. Egal! Was ich heute im Zeitraum eines Jahres sammeln kann, kann ich in 5 Jahren in wenigen Tagen, vielleicht sogar Stunden sammeln.

Oder Künstliche Intelligenz, die heute noch weit, weit davon entfernt ist, intelligent zu sein. Man googele den Unterschied zwischen Korrelation und Kausalität.

Model Based System Engineering? AR/VR? Und nun Digital Thread? Aus Fäden macht meine Schwiegermutter warme Socken. Die sind toll, helfen aber der Industrie nicht weiter. Meiner zumindest nicht. Und sexy sind sie auch nicht.

Früher war jedes Ziel ein hehres Ziel. Heute bringen die Schritte auf dem Weg zu den Zielen die Organisation weiter. Nicht unbedingt das Ziel selbst. Dabei stelle ich immer wieder fest, dass Buzzwords eine magische Eigenschaft mit sich bringen. Sie werden nie hinterfragt. „Brauchen wir das überhaupt? Was bringt es uns? Welche heute unmögliche Wertschöpfung erreichen wir?“. Selbst „Was kost‘ der Spaß?“. Solche Fragen stellen sich bei den Buzzwords nicht. Aber für mich sind die Buzzwords von heute die Zielgerade eines Marathon. Wo stehen die Organisationen heute? Manche sind schon losgelaufen. Aber andere sitzen noch auf der Couch, shoppen Laufshirts bei Amazon und träumen vom Training – in dem Irrglauben, es würde schon nicht anstrengend sein.

PLM ist antrengend

Aber es wird anstrengend! In der Welt des Product Lifecycle Managements ist anstrengend gleich komplex. Oft genug sogar kompliziert -> komplex -> chaotisch! Da geht auch gern mal was schief. Bei Erfolg sind die Gewinner oft die anderen. Die Nutznießer der Systeme. Bei denen wurde ein abstrakter Case nach einer Zeit des Einschleifens plötzlich selbstverständliches Handwerkszeug. Ohne leben: undenkbar. Verlierer durfte man im PLM-Umfeld immer gern alleine sein. Deswegen jetzt ausweichen und zu weit in die Zukunft blicken und vom Thema ablenken zählt nicht. Dazu ist der Weg auch heute noch immer zu steinig. Und auch heute können wir genug Themen aufgreifen, die uns und unsere Organisationen jetzt weiterbringt. Nicht erst morgen. Weiterhin abstrakt. Aber doch auch konkreter, als das vor Jahren möglich war. Mit modernen Werkzeugen. Und vielleicht endlich mal wirklich End2End und nicht nur mit einem starken Fokus auf die Produktentwicklung. Dafür aber als das, was es ist: PLM.

Es gibt das Sprichwort „den Wald vor lauter Bäumen nicht sehen“. Wir sehen den Wald! Wir sollten nur vor lauter Vorfreude auf den Wald das Bäume pflanzen nicht vergessen. Die fehlen oft genug noch oder sind zwar da, aber schon morsch!