Die Absicherung von PLM-Systemauswahlen mit Proof of Concepts

Veröffentlicht am 6. Juni 2022, aktualisiert am 7. Juni 2022 von Christoph

Die Entscheidung für ein PLM-System ist der Auswahl eines neuen Fahrzeugs für die Familie gar nicht so unähnlich. Die Eltern haben ein paar bestimmte Hersteller im Blick und finden diese oder jene sympathisch. Im Unternehmen werden von einem Projektteam PLM Systemhersteller recherchiert und eine Liste mit potenziellen Systemen erstellt.

Als Nächstes tagt derFamilienrat und es werden Kriterien (Preis, Lieferzeit, Design, Antriebskonzepte, …) definiert, nach denen die Auswahl von Fahrzeugen eingeschränkt wird. Analog dazu bekommen die PLM Hersteller einen Fragebogen und werden gebeten, diesen zu beantworten. Die Antworten werden ausgewertet und drei bis fünf vielversprechende Anbieter selektiert.

Beim Kauf eines Auto vereinbart man jetzt Probefahrten, bei der Auswahl eines PLM-Systems bittet man die Hersteller zur Vorstellung und Präsentation Ihrer Lösungen. Für diese Präsentationen werden Vorgaben gemacht, die sich aus den Hauptprozessen des auswählenden Unternehmens ergeben. Sehr gut geschulte PLM-Experten zeigen dann ihre Lösungen zu Ihren Anforderungen. Die Zuhörerschaft setzt sich aus den zukünftigen Anwendern zusammen, verfolgt diese Demonstrationen und gibt ihre Bewertungen auf Basis der gemachten Eindrucke ab. Die einzelnen Bewertungen werden statistisch ausgewertet und das führt zu einem favorisierten PLM-System.

Überträgt man dieses Vorgehen auf den Kauf der neuen Familienkutsche, sitzen bei der Probefahrt alle auf der Rückbank und der Fahrer ist Sebastian Vettel. Gesucht wird ein neuer Familienkombi für den Transport der Kinder zum Reitunterricht und zum Fussballtraining sowie für die Wege zum Baumarkt.

Aber Sebastian Vettel sitzt vorn am Steuer eines Cabrios und erzählt schöne Geschichten aus dem Rennfahrerleben. Mit ihm als Fahrer fühlt sich der Kofferraum des Cabrios auch gar nicht mehr so klein an. Und die Kinder sollen eh besser das Fahrrad nehmen.

Übertragen wir dieses zugegebenermaßen überspitzte Beispiel in die Wirklichkeit einer PLM-Systemauswahl, dann fährt ein Profi das PLM-Fahrzeug in der Benchmarkpräsentation. Und das ist zu diesem Zeitpunkt auch gar nicht so schlecht, da man selbst noch ein klein wenig überfordert bei der Steuerung eines recht komplexen PLM-Wagens ist.

Aber der PLM-Profi hat sich auf diese Probefahrt sehr gut vorbereitet, kann Schlaglöcher sehr gezielt umfahren und steuert sicher nicht mit einem Sportwagen auf einen Feldweg zur Demonstration der Offroad-Qualitäten.

Was heisst das jetzt aber für Ihre Systemauswahl? Das PLM-System ist neben der nicht unerheblichen kommerziellen Dimension eine der wichtigsten Entscheidungen für das Betriebssystem Ihres Unternehmens. Im diesem System laufen Ihre Produktdaten über den gesamten Lebenszyklus zusammen. Dichter dran an der Wertschöpfung ist kaum eine andere Unternehmenssoftware.

Diese zentrale Rolle im Unternehmen macht die Entscheidung für die PLM-Lösung so wichtig. Einmal getroffen kann diese Entscheidung nur mit großem Aufwand revidiert werden. Zu groß ist die Einbindung in der wertschöpfenden und steuernden Unternehmensprozesse.

Vor diesem Hintergrund bietet eine Probefahrt auf der Rückbank noch keine ausreichenden Erkenntnisse, um eine fundierte Systementscheidung zu treffen. Doch welche Aktivitäten schließen die noch offenen Lücken für Ihre Entscheidung? Hier sind einige Gedankenanstösse:

Sie müssen selbst fahren, d.h. sie bedienen das PLM System und nicht eine geschulte Fachkraft des Herstellers.
Sie erfahren selbst die Bequemlichkeit des Fahrersitzens und der Armaturen, d.h. ihre Maßstäbe und Erfahrungen zählen. Ist das PLM-System aus ihrem Blickwinkel benutzerfreundlich und logisch aufgebaut? Werden Informationen und Funktionen verständlich angezeigt?
Sie müssen den Weg ihrer Probefahrt selbst bestimmen können. Ihre Prozesse und Hauptanwendungsfälle müssen betrachtet werden.
Sie verlassen sich nicht auf die Verbrauchsangaben im Prospekt, sondern bewerten konkret die operativen Kosten des Systems auf Basis Ihrer Nutzung.
Sie fahren das Automobil mal im Linksverkehr. So bekommen sie einen Blick darauf, wie das System sich in ihren Niederlassungen in Asien oder anderen Standorten anfühlt.
Sie schauen intensiv unter die Motorhaube, ob sich dort ein hochgezüchteter Rennmotor verbirgt oder ein genügsamer, aber veralteter Dieselmotor oder ein wartungsfreier Elektroantrieb. Die Architektur des PLM System und die dafür verwendete Technologie bestimmt maßgeblichst den Aufwand für den kontinuierlichen Betrieb ihres PLM System. Im diesem Blogartikel “Die Out-of-the-box Lüge in PLM-Systemauswahlen” erfahren sie mehr dazu.
Sie testen die Größe des Kofferraums und des Fruncs mit Ihrem Reisegepäck, d.h. Ihre Stücklisten, Ihre CAD Modell und ihre Dokumente sind das Maß der Dinge.
Sie fahren auch mit einen Wohnwagen an der Anhängerkupplung und einem Kajak auf dem Dachgepäckträger. Wie werden Daten an ihr ERP System (der Wohnanhänger) übertragen und wie sind Autorensysteme (CAD, …) integriert?
Sie fahren in die Werkstatt und lassen einen Service machen und die Sitze neu beziehen. Wie gut ist der Support und wie versteht er sie? Passt das Vorgehensmodell des Implementierungspartners zu ihnen? Kommen sie auf menschlicher Ebene miteinander klar?

Es bleiben doch noch viele Fragen offen nach so einer Probefahrt nur auf dem Rücksitz. Für das Erleben und den Erkenntnisgewinn des Selber-Fahrens hat sich in PLM-Systemauswahlen die Methode des “Proof of Concept (PoC)” bewährt. Kurz gesagt wird in einem PoC eine Systemimplementierung in einem definierten zeitlichen Rahmen mit einem Subset von Anwendungsfällen simuliert. Diese Methode ermöglicht in großen Teilen das Beantworten der oben aufgeworfenen Fragen und reduziert so das Risiko einer falschen Systemauswahl erheblich. Ein PoC findet immer nach den Vorstellungen und Präsentationen der Systemhersteller statt und kann in Abhängigkeit des Ausgangs dieser Termine zwei Zielrichtungen haben:

Es gibt einen eindeutigen Gewinner nach den Benchmark-Präsentationen

Der PoC dient dann zur Absicherung der gezeigten Erkenntnisse aus den Probefahrten mit Herrn Vettel. So können Überraschungen in der späteren Implementierung oder im Betrieb des PLM-Systems vermieden werden und gleichzeitig lernen sich der Implementierungspartner und ihr Unternehmen besser kennen. Das beschleunigt eine spätere Implementierung ungemein. Sollte der PoC trotz aller Erwartungen nicht gut laufen oder sogar scheitern, haben Sie hier immer noch die Möglichkeit, ohne heftige Auswirkungen auf einen anderen Systemhersteller umzuschwenken.

Es gibt keinen klaren Gewinner nach den Benchmark-Präsentationen

Ein PoC ist kostet zeitlichen und personellen Aufwand und kann daher nicht mit allen Systemherstellern durchgeführt werden, die zu den Präsentationen eingeladen wurden. Sinnvollerweise reduziert man die Shortlist auf zwei oder maximal drei Teilnehmer am PoC. Da so ein PoC auch erhebliche Ressourcen bindet, ist die sequentielle Abfolge des PoCs eine Überlegung wert. Sollte der PoC des ersten PLM-Systems bereits zu hervorragenden Ergebnissen führen, kann über die Absage des zweiten und gegebenenfalls dritten PoC in Erwägung gezogen werden.

Auf der anderen Seite stachelt so eine Wettbewerbssituation bei einer parallelen Durchführung des PoCs auch an und zeigt dann im Ergebnis ein naturgemäß ein vollständigeres Bild aller beteiligten Hersteller. Aufwand gegen Nutzen gilt es sinnvoll abzuwägen.

Wie aber läuft so ein PoC jetzt konkret ab?

1. Die Erarbeitung des PoC-Szenarios

So ein PoC benötigt einen gewissen Mut zur Lücke, da aufgrund der zeitlichen und personellen Beschränkung nicht monatelang implementiert werden kann. Die Beantwortung der folgenden Fragen hilft bei der Definition eines geeigneten PoC-Szenarios.

Wo liegt der größte Hebel für das zukünftige PLM-System in ihrem Unternehmen? In welchem (Teil-)Prozess erwarten sie die größten positiven Effekte durch ein PLM-System?
In welchem Bereich oder in welchem (Teil-)Prozess liegt das größte Risiko des Scheiterns? Wo liegen die absoluten Knackpunkte der gesamtem PLM Systemeinführung, was muss unbedingt funktionieren? Gerade dem PLM-Projekt gegenüber kritisch eingestellte Bereiche oder Anwender können wertvolles Impulse geben.
Mit welchen anderen IT-Systemen (ERP, CAD, …) muss das zukünftige PLM System Daten austauschen? Sind diese Schnittstellen kritisch für Ihre PLM Mission? Falls ja, gehören die in den PoC.
Welche Anwendungsfälle sind sehr spezifisch für Ihr Unternehmen? Suchen Sie gezielt nach Komplexität in Ihren Anforderungen, um den Systemhersteller zu fordern und somit eine Aussagekraft für die wirkliche Leistungsfähigkeit zu erlangen. Standard können alle, das ist kein Selektionskriterium.

Das Schneiden eine passenden PoC-Szenarios als Kompromiss zwischen Aufwand und der Erfüllung der genannten Kriterien ist nicht ganz einfach. Der Ruf nach externer Hilfe ist für diesen Schritt eine Überlegung wert. Mit der Qualität des PoC-Szenarios steht und fällt die Qualität und die Aussagekraft der Ergebnisse. Zu einfache PoC Szenarien verringern den Erkenntnisgewinn und zu aufwändige sind im Rahmen eines PoCs nicht abbildbar. Externe Berater mit Erfahrungen in der Implementierung und im Betrieb von PLM-Systemen als auch im Umgang mit PLM Systemherstellern können wertvolle Hinweise geben für den richtigen Schnitt des PoCs.

Die Beschreibung des PoC-Szenarios muss so konkret als möglich erfolgen. Hier haben sich Methoden wie User Stories mit Akzeptanzkriterien bewährt. Neben diesen funktionalen Beschreibungen müssen auch die dazugehörige Daten (CAD-Modelle, Stücklisten, Dokumente, Spezifikationen, …) erzeugt werden und diese müssen so dicht als möglich an der täglichen Realität der Anwender sein.

2. Die Implementierung des PoCs

Im folgenden werden unterschiedliche Ansätze für die Implementierungsphase aufgezeigt.

Die off-site Variante

Jeder Systemhersteller bekommt die Anforderungen und Testdaten zugestellt und hat dann einen klar definierten Zeitraum, diese zu implementieren. Wie viele Ressourcen und welchen Aufwand er für diesen PoC allokiert, bleibt ihn überlassen und ist für das PoC-Team nicht sichtbar. Um eine spätere Implementierung zu simulieren, sollte es regelmäßige Abstimmungstermine zwischen dem PLM-Systemhersteller und dem PoC-Team geben. Diese Termine geben Hinweise hinsichtlich der fachlichen Expertise und der Kommunikation im Projekt. Spricht man eine gemeinsame Sprache? Passt es menschlich zusammen? Wie engagiert ist der Systemhersteller bei diesem PoC?

Der Vorteil dieser Variante liegt im überschaubaren Betreuungsaufwand für das PoC-Team. Bis auf die Teilnahme an den regelmäßigen Abstimmungsterminen fällt hier kaum Aufwand an.

Nachteilig ist der fehlende Einblick in die Anzahl der genutzten Ressourcen und den Implementierungsaufwand. Hat das ein Experte an einem Nachmittag schnell zusammenkonfiguriert oder war dafür ein ganzen Entwicklerteam über mehrere Wochen beschäftigt? Diese Aussage kann nicht getroffen werden und das führt zu einer unsicheren Beurteilung hinsichtliches dieses Kostentreibers für ein späteres Implementierungsprojekt.

Die on-site Variante

Der Implementierungspartner wird eingeladen und bekommt das PoC Szenario und die Daten in den Räumlichkeiten des Unternehmens übermittelt. Die Berater und Entwickler setzen die Anforderungen des PoC dann on-site um und haben dafür wenige Tage bis eine Woche Zeit. Das PoC Team ist integraler Bestandteil des Implementierungsteams und tauscht sich ständig aus. Im besten Fall sitzen alle im gleichen Raum. So ist das PoC-Team live dabei, wenn die Anforderungen umgesetzt werden.

Die Vorteile dieser Variante liegen im deutlich höheren Erkenntnisgewinn zur Leistungsfähigkeit des Implementierungsteam als auch der Technologie/Architektur des Systems. Es ist nachvollziehbar, welcher Aufwand hinter der Implementierung steckt und somit können die dafür entstehenden Kosten genauer kalkuliert und hochgerechnet werden. Auch die menschlichen Faktoren der Zusammenarbeit werden in dieser Variante deutlich besser getestet.

Nachteile sind im Aufwand für diese Variante zu finden. Der Betreuungsaufwand für das PoC-Team ist deutlich höher. Zusätzlich müssen entsprechende Räumlichkeiten und Infrastruktur zur Verfügung stehen.

Die on-site Variante extended

Nicht alle Unternehmen möchten sich an einen externen Partner binden, sondern planen den Aufbau eines eigenen Implementierungsteams. In diesem Fall kann die On-site Variante anstelle des externen Partners auch mit diesen internen Ressourcen gefahren werden. Der Erkenntnisgewinn ist hier nochmal höher gegenüber der zweiten Variante, da Implementierer und Anforderer aus dem gleichen Unternehmen kommen. Als Nachteil ist zu nennen, dass das interne Implementierungsteam erst ausgebildet werden muss, um die Anforderungen des PoC im Zielsystem umzusetzen zu können. Dabei sind PLM-Systeme, die auf Standardtechnologien setzen, im Vorteil. Hier ist weniger Trainingsaufwand notwendig, was auch ein wichtiger Erkenntnisgewinn des PoC ist.

3. Die Vorstellung des PoCs

Welche Implementierungsvariante auch gewählt wurde, am Ende steht immer die Präsentation der PoC-Ergebnisse durch das Implementierungsteam. Das Ziel dieser Vorstellung ist aber nicht nur die Vorführung der Ergebnisse. Es geht vielmehr darum, das PoC Team in der Anwendung des PLM-Systems ausreichend zu schulen. Hinsichtlich der Infrastruktur für diese und die nächste PoC Phase sollte sich an der Unternehmens-IT-Strategie orientiert werden.

Bei einem Betrieb des PLM-Systems auf eigener Hardware sollte die PoC-Installation in diese unternehmenseigene Infrastruktur erfolgen. Welche Stolpersteine hier drohen können, zeigt dieser Artikel “Es wird technisch – Der Betrieb ihres PLM-Ökosystems”
Wird eher ein Auslagern des PLM-Systems in die Cloud (SaaS o.ä.) angestrebt, so ist diese Art der Installation vorzuziehen.

4. Testen und Bewerten des PoC

Der PLM-Systemhersteller ermöglicht nach der PoC Präsentation dem PoC-Team einen mehrwöchigen Testzeitraum. Hier fährt jetzt also nicht mehr Sebastian Vettel, sondern jeder Anwender selbst. Das zukünftige System kann so auf Herz und Nieren geprüft werden. Mit diesem ausgiebigen Testzeitraum einhergehen wird eine ansteigende Lernkurve der zukünftigen Anwender des PLM Systems. Dieser Effekt ist nicht zu unterschätzen, da hier die Grundlage für einen effektiven Start des nachfolgenden Implementierungsprojektes gelegt wird.

Aber was ist jetzt nach dem PoC besser geworden im Vergleich zu dem Stand nach den Benchmarkpräsentationen?

Sie sind selbst gefahren und haben das PLM System selbst bedient.
Sie haben Bequemlichkeit des Fahrersitzes selbst getestet, d.h. ihre Maßstäbe und ihr persönliches Empfinden in der Anwendung der Software sind das Maß der Dinge.
Sie haben die Strecke selbst bestimmt. Ihre wichtigsten Prozesse und Anwendungsfälle wurden betrachtet.
Sie haben Erkenntnisse gewonnen über die tatsächlichen Verbrauch (die operativen Kosten) ihres PLM-Systems.
Falls notwendig, haben sie auch andere Standorte in ihren PoC integriert. Der Linksverkehr war ein Abenteuer, aber es hat sich gelohnt.
Sie haben definitiv unter die Motorhaube des PLM-System geschaut. Sie verstehen die Architektur und die zugrundeliegenden Technologien des PLM-Systems und können Auswirkungen besser beurteilen und abschätzen.
Der Kofferraum Ihres PLM-Systems wurde mit Ihrem Reisegepäck (ihren Daten) getestet.
Der Austausch von Daten und die Integration von Autorensystemen wurden praktisch getestet. Das PLM-Automobil war mit dem ERP-Wohnanhänger im Slalomparcours. War das eine wilde Sause!
Sie waren in der Werkstatt und haben ausgiebig mit dem Werkstattmeister und den Mechanikern zusammengearbeitet. Die haben auch den kaputten Wohnanhänger wieder hinbekommen.

Mit diesen Erkenntnissen kann jetzt eine deutlich besser abgesicherte PLM Systemauswahl getroffen werden. Sicher, so ein PoC kostet einen nicht unerheblichen Aufwand. Aber das Risiko einer Fehlentscheidung beim Betriebssystem Ihres Unternehmensblutkreislaufes wird so deutlich minimiert. Eine spätere Korrektur wäre deutlich teurer und aufwändiger.

Und ein Effekt wird auch oft vergessen. Das PoC-Team hat eine erhebliche Lernkurve genommen, versteht PLM als Managementstrategie und das PLM-System deutlich besser. Und startet mit diesen Voraussetzungen deutlich effektiver in das Implementierungsprojekt. Und für das wünsche ich ihnen maximalen Erfolg.

PLM und demographische Diversität – wie passt das zusammen?

Veröffentlicht am 29. Januar 2022, aktualisiert am 29. Januar 2022 von Christoph

Vor einigen Tagen wurde mir eine Veröffentlichung in meine Linkedin-Timeline gespült, dessen Titel meine Aufmerksamkeit erregte: “Organizational Demographic Faultlines: Their Impact on Collective Organizational Identification, Firm Performance, and Firm Innovation“. Ulrich Leicht-Deobald (Universität St. Gallen), Hendrik Huettermann (Bundeswehruniversität München), Heike Bruch (Universität St. Gallen) und Barbara S. Lawrence (University of California, Los Angeles) veröffentlichten dieses Paper im “Journal of Management Studies” im Dezember 2021.

Foto von fauxels via Pexels

In dieser Studie wurde der Zusammenhang zwischen Gräben innerhalb von Unternehmensorganisationen und der Innovations- und Leistungsfähigkeit untersucht. Ok, der Abbau von Datensilos ist die Basis des Business Cases fast aller PLM Projekte und somit keine wirkliche Sensation.

Neu in dieser Studie war aber der Blickwinkel, unter dem das betrachtet wurde. Die Protagonistinnen und Protagonisten schauen gezielt auf die demographischen Ursachen der Ausbildung solcher Trenngräben. Menschen mit ähnlichen Merkmalen (Geschlecht, Alter, soziale und/oder regionale Herkunft, …) bilden keine Netzwerke über die gesamte Organisation, sondern arbeiten so mehr oder minder unter sich zusammen.

Die Studie führte zu einem klaren Ergebnis: Diese demographischen Silos wirken sich klar und nachweisbar negativ auf die Innovations- und Leistungsfähigkeit von Unternehmen aus.

Somit schlägt das Beharren auf überholten konservativen und althergebrachten Denkmustern die Hüter des “Früher war alles besser” mit den eigenen Waffen. Innovationen und die Performance von Organisationen werden vermindert und gebremst, wenn sich keine demographisch-diversen Netzwerke in Unternehmensorganisationen ausbilden können.

Das wo ist hier die Verbindung zum PLM? Datensilos wollte PLM schon abbauen, als es noch CIM hieß. Über gemeinsame Datenmodelle, Product Data Backbones und Systemintegration wird in jedem Projekt ausgiebig diskutiert.

Und auch zum organisatorischen und arbeitskulturellen Wandel, der mit PLM einhergeht, wurde schon sehr viel geschrieben. Der geneigten Leserin und dem geneigten Leser möchte ich dazu den Blogartikel “Es wird menschlich – die Organisation rund um ihr PLM System” und das Interview mit Bernd Ebert an das Herz legen.

Foto von Alexas Fotos via Pexels

Ebenso ist die Umsetzung und Begleitung dieses ein fester Bestandteil ein jeder PLM Initiative. Das reicht von der intensiven Projektkommunikation über die Einbindung von Key Usern und Stakeholdern bis hin zu vielfältigen Trainingsmaßnahmen.

Martin Eigner bringt es auf den Punkt: “Jeder PLM Anwendungsfall verlangt nach einer individuellen Lösung. Technik, Organisation und Menschen müssen gleichwertig eingebunden werden“. Ich nicke zustimmend und möchte das “Organisation” und “Menschen” betonen.

Mit der Lektüre dieser Studie hat sich mein Mindset definitv erweitert. Diversität wirkt in Unternehmensorganisationen als erfolgsverstärkender Faktor und das hat definitiv einen Einfluss auf erfolgreiche PLM Projekte.

Es gibt Beispiele dafür, die in diesen Aspekt auf der Agenda haben, Initiativen starten und handeln. Stellvertretend sei auf das LEAD Network verweisen, auf das ich durch meinen Fellow Mick Broekhof aufmerksam wurde.

Diesen spannenden Gedankenanstoss möchte ich mit der Community teilen. Und er hat mich zum Nachdenken gebracht. Man soll ja immer zuerst vor der eigenen Tür kehren. Wenn wir uns in der PLM Branche umschauen, wie divers sind wir eigentlich?

Es wird menschlich – die Organisation rund um ihr PLM System

Veröffentlicht am 1. Oktober 2021, aktualisiert am 7. Oktober 2021 von Christoph

Der geneigte Leser mag sich noch an meinen Artikel über die infrastrukturellen Voraussetzungen eines erfolgreichen PLM-Projekts erinnern. Aber leider ist es mit der reinen IT Infrastruktur nicht getan und deshalb wende ich mich heute dem Aspekt der Organisation zu. Konkret geht es mir genau um den Übergang von der Implementierungsphase in den produktiven Betrieb des PLM-Systems und das weniger aus technischer Sicht, sondern aus dem Blickwinkel der Unternehmensorganisation und den damit zusammenhängenden menschlichen Faktoren. Wie bekommen Sie als Eltern des PLM-Systems diesen gerade der Pubertät entwachsenen Sprössling gut und sicher in den Ernst des Lebens, nämlich in den produktiven Betrieb?

Als Erstes möchte ich mit einem noch oft gehörtem Trugschluss einer PLM-Einführung ausräumen. Vergessen Sie den Gedanken, dass so ein PLM-System jemals “fertig” ist. Ihre Produkte müssen sich ständig neuen Markterfordernissen anpassen oder sie setzen neue Trends und Innovationen auf Ihrem Markt.

Des Weiteren ziehen gerade in der Produktentwicklung immer mehr agile Methoden ein. Dieses Internet, von dem man in den letzten Monaten so viel hört, bringt vollkommen neue Geschäftskonzepte hervor und lässt komplette traditionelle Produkte verschwinden.Das zwingt jeden Marktteilnehmer zur Anpassung.

Vor diesem Hintergrund kann und darf ein PLM-System nicht statisch sein. Die Anpassung dieses System zur Unterstützung Ihrer Produktinnovation ist nicht die Ausnahme, es ist der Regelfall. Daher muss sich auch jeder PLM-Systemlieferant daran messen lassen, wie einfach und durchgängig Änderungen an seinem System vorgenommen werden können. Für mich als Verantwortlicher eines PLM-Systembenchmarks wäre diese Adaptionsfähigkeit das allerwichtigste Kriterium. Den Gedanken an ausreichende oder sogar vollständige Out-of-the-box Funktionalität legen sie besser beiseite. Wenn alles OOTB funktionieren soll, was was unterscheidet sie dann von Ihrer Konkurrenz? Des Weiteren kann in ein paar Jahren die OOTB Funktion von heute vom Stand der Technik überholt worden sein. Oder wer benutzt heute noch ein Nokia 3210 oder bringt noch analoge Filme zu entwickeln? Und wer weiß, was diese Digitalisierung in den nächsten Jahren noch an neuen Konzepten und Innovationen hervorbringt, die mit Sicherheit Einfluss auf ihr PLM-System haben werden.

Was heißt das jetzt aber für Ihre Unternehmensorganisation? Die Schlussfolgerung liegt auf der Hand: Sie benötigen Mitarbeiterinnen und Mitarbeiter, die mit dieser Herausforderung der ständigen Änderung umgehen können. Und sie müssen sich natürlich Gedanken über Prozesse und Methoden machen, die dies unterstützen.

Das ist einfacher gesagt als getan. Im Implementierungsprojekt hat ihr PLM Systemhaus diese Aufgaben übernommen. Er hat Ihre Anforderungen aufgenommen, das PLM-System ihrer Wahl dahingehend angepasst, die Ergebnisse in regelmäßigen Sprints vorgestellt, Feedback eingesammelt und so das erste produktive Release des PLM-System erstellt. Für diese Implementierungspartner ist das tägliches Brot, sie haben entsprechende Prozesse und Infrastruktur am Start und deren Mitarbeiter sind darauf geschult und trainiert. Genau aus diesem Grund haben Sie ja auch diese externe Unterstützung eingekauft.

Basierend auf Ihren guten oder nicht so guten Erfahrungen während der Implementierungsphase können sie dann eine erste Entscheidung treffen: Wollen sie alle weitere Änderungen am produktiven PLM-System von Ihrem Implementierungspartner durchführen lassen? Der Vorteil dieser Lösung liegt auf der Hand: Es ist die Fortführung von mittlerweile eingespielten Prozessen und Verantwortlichkeiten und sollte ein beherrschbares Risiko beinhalten.

Der Nachteil ist aber auch klar: Die schnelle Verfügbarkeit der Consultants ist nicht garantiert, sie machen sich ein Stück weit abhängig von ihm und die Kostenseite muss natürlich auch betrachtet werden.

Alternativ können Sie auch darüber nachdenken, diese Aufgabe zumindest teilweise intern zu lösen. Die großen neuen Module vergeben sie weiterhin an Ihren Partner, aber die alltägliche Maintenance lösen sie mit internen Ressourcen. Oder sie befähigen ihr Team, zukünftig alle Anpassungen ihres PLM-Systems vorzunehmen.

Beides bedingt, dass sie bereits während der Implementierungsphase Gedanken über die Organisation, die Ressourcen und die Methoden und Prozesse machen müssen. Es gibt natürlich auch Industriestandards wie ITIL, die sie dabei unterstützen können, gute Lösungen zu finden.

Aber eigentlich reicht auch der gesunde Menschenverstand, um über die Frage nachzudenken, was nach der Produktivsetzung passieren muss. Prinzipiell müssen sie die Methoden, Prozesse und die Infrastruktur Ihres Implementierungspartners auf sich selbst adaptieren.

Zur Infrastruktur hatte ich mich bereits in einem anderen Blogartikel ausgelassen. Aber das ist nur eine Seite der Medaille, die andere betrifft ihre Mitarbeiter und Unternehmensorganisation. Ich möchte hier nur einige Aspekte ansprechen:

Support

Auch wenn ihre Anwender intensiv trainiert und geschult werden, trotzdem wird es im laufenden Betrieb Fragen geben. Wer übernimmt diesen first und second level Support bei Ihnen? Sollen das Ihre Key User aus dem Implementierungsprojekt sein oder richten sie eine dezidierte Supportmannschaft ein?

Instandhaltung

Wer kümmert sich um die Kommunikation von Issues, die an den Hersteller des PLM-Systems weitergeleitet werden müssen? Und wer verfolgt das weiter? Daraus ergeben sich auch Fragen, wie die Änderungen (Hotfixes, Patches) in ihr Produktivsystem gelangen sollen. Wer übernimmt Verantwortung für das Aufsetzen und die Wartung Ihrer Integrationsumgebung und ihres Testsystems.

Tests und Qualitätssicherung

Wer kümmert sich um die Organisation von Testaktivitäten, ohne die Änderungen an einem Produktivsystem auf keinen Fall vorgenommen werden dürfen? Wer übernimmt Verantwortung für die interne Freigabe von neuen Releases?

Anpassungen und tägliche Wartung

Und dann gibt es noch diese ganz normalen Anpassungen, die ständig anfallen werden. Wer übernimmt die notwendigen Pflegearbeiten am PLM-System? Das geht von der Anlage von Benutzeraccounts und der Vergabe von Berechtigungen über einfache Änderungen an den Businessobjekten (z.B. neue Klassifikationen ihrer Dokumente) bis hin zu komplexen Änderungen an den implementierten Geschäftslogiken.

Diese Liste von Fragen und Aspekte erhebt keinen Anspruch auf Vollständigkeit. Dafür ist dieses Thema auch zu individuell und zu unternehmensspezifisch.

Eine gute und bewährte Strategie, die richtigen Fragen zu stellen und auch passende Antworten darauf zu finden, ist es, die zukünftige Supportorganisation frühzeitig in das Implementierungsprojekt einzubinden. Denken sie daran, es ist IHR PLM-System und nicht das Ihres PLM Systemhauses. Lernen sie aus den Erfahrungen ihrer Implementierungsphase und profitieren sie vom Wissen, dass Ihr Partner mit Ihnen dabei teilt. Nicht jedes Rad muss neu erfunden werden.

Vor einigen Tagen hat mir Bernd Ebert, der hier auch schon auf der PLM Couch saß, einen weiteren vielversprechenden Ansatz zur Lösung dieses Problems vorgestellt.

Es geht dabei um DevOps, einen Prozessverbesserungsansatz aus dem Bereich Softwarentwicklung und Systemadministration. Das ist definitiv einen Blick wert – aber das soll in einem anderen Blogartikel passieren.

Der PLM-Talk: Heute mit Dr. Christian Klüber-Demir

Veröffentlicht am 8. April 2021 von Christoph

Herzlich Willkommen auf meiner virtuellen Blogcouch, Herr Dr. Klüber-Demir. Machen Sie es sich bitte recht bequem. Ich freue mich sehr, einen ausgewiesenen Experten aus der Medizintechnik begrüßen zu dürfen – einer Branche, die seit Monaten im Fokus der Öffentlichkeit steht. Für Leser, die noch keine Berührungspunkte mit Ihnen hatten, können sie sich bitte kurz vorstellen?

Dr. Christian Klüber-Demir:

Ja gerne, und erst mal besten Dank für die Einladung! Ich habe ursprünglich an der RWTH Aachen und der Universität Wien Werkstoffwissenschaften studiert und am Max-Planck-Institut Düsseldorf geforscht und promoviert, bevor ich zu einem traditionellen Hersteller von Stahlrohren gewechselt bin.
Dort habe meine ersten Erfahrungen im Qualitätsmanagement gesammelt, bevor ich dann erst in die Halbleiterindustrie und während der Finanzkrise weiter in die Medizintechnik gewechselt bin.
In den letzten 15 Jahren habe ich mich dabei meist mit dem Thema Lieferantenqualität beschäftigt, in der großen Spannweite von Halbzeug-und Standardteil-Zulieferern für die Eigenfertigung bis zu OEM- oder Handelswarenlieferanten von Medizinprodukten.

Die Prozess- und Systemintegration ist eine Kernaufgabe einer PLM-Strategie und gerade in Medizintechnikunternehmen kommt dabei dem Qualitätsmanagement in der Zuliefererkette eine besondere Bedeutung zu. Rückblickend auf ihre langjährige Berufserfahrung, was waren dort die größten Herausforderungen die es zu meistern galt.

Nach meiner Erfahrung gab zwei Herausforderungen, die uns besonders großes Kopfzerbrechen gemacht haben:
Zum einem fehlte es an eigenen ausgereiften Prozessen zur Qualifikation von Lieferanten und von zugelieferten Komponenten oder Produkten. Die Organisationen, in denen ich aktiv war, hatten immer eine starke Entwicklungsabteilung und Eigenfertigung. Und dort hat man sich in der Medizintechnik über die letzten Jahre viel u.a. von der Automobilindustrie abgeschaut, z. B. das Thema Prozessvalidierung.
Aber die Beschaffung von Komponenten für die Eigenfertigung oder auch von fertigen Medizinprodukten als Handelswaren wurde eher stiefmütterlich behandelt. Dazu waren die jeweiligen Einkaufsorganisationen auch gar nicht ausreichend auf die regulatorischen Anforderungen geschult und es gab keine guten Prozesse. Es hat viel Zeit gekostet, dafür zu werben, dass Zukaufteile dieselben Anforderungen erfüllen müssen wie die Eigenfertigung, zumal der Unterschied für den Kunden ja gar nicht sichtbar ist.
Und da spannt sich dann auch der Bogen zur zweiten großen Herausforderung auf:
Wir wussten anfangs viel zu wenig über unsere Lieferanten und wurden regelmäßig überrascht, wenn wir genauer hingeschaut haben! Obwohl ich mich im Halbleiterbereich ja schon mit dem Lieferantenqualitätsmanagement beschäftigt hatte, waren die Ergebnisse in der Medizintechnik zum Teil erschreckend! Dafür musste man nicht mal in irgendwelche Billiglohnländer schauen, die deutschen Medizintechnik-Zulieferer zeigten und zeigen ein riesiges Spektrum vom professionellen Hersteller, der deutlich reifere Prozesse hat als wir selber, bis zur Ein-Mann-Fertigung von Medizinprodukten auf der Drehbank im eigenen Wohnzimmer – ohne Prozesse, kalibrierte Messmittel, Prüfkonzept und ordentliche Dokumentation. Ich hätte damals gar nicht für möglich gehalten, dass es solche Firmen in Deutschland noch gibt.
Wir haben dabei vor allem gelernt, uns nicht mehr auf Zertifizierungen nach ISO 9001 zu verlassen, weil sie wenig über die Reife der Organisation aussagen. Stattdessen haben wir mehr Energie in die Auswahl und Qualifikation neuer sowie das regelmäßige Monitoring vorhandener Lieferanten gesetzt – beides recht erfolgreich durch ausführliche Audits vor Ort.

Wenn man auf diese Herausforderungen zurückblickt, waren da die Ursachen eher der Gestaltung der Wertschöpfungsprozesse geschuldet oder wurden diese Prozesse einfach schlecht unterstützt, zum Beispiel durch eine ungeeignete IT-Infrastruktur?

Das Problem waren oft weniger die Systeme als mehr die damit abgebildeten Prozesse, die sozusagen noch in Revision 1 feststeckten, sowie ein fehlendes Verständnis der Organisation für die Notwendigkeit solcher Prozesse, um die Produktqualität abzusichern und die ständig strenger werdenden regulatorischen Anforderungen überhaupt noch erfüllen zu können.

Häufig lag der Schwerpunkt – obwohl der Preisdruck in dieser Branche sicher nicht so extrem ist wie in anderen Industrien – mehr auf kaufmännischen Aspekten wie Preis und Lieferzeiten. Dabei ist der Entwicklung regulatorischen Anforderungen auch eine Möglichkeit, sich von Wettbewerbern abzusetzen, die nicht die Kompetenz oder auch die kritische Größe haben, ein dediziertes Lieferantenmanagement aufzubauen.
Der Einfluss der IT-Infrastruktur wird dabei meiner Meinung nach vom Management häufig überbewertet. Natürlich ist eine funktionierende IT-Infrastruktur heutzutage unerlässlich, aber was häufig übersehen wird: Sie ist nur ein Tool, um gute Prozesse umzusetzen oder um Arbeit in diesen Prozessen zu vereinfachen: Bei Kritik an der IT merkt man bei genauem Hinschauen oft, dass nicht die Software das Problem ist, sondern ein holpriger oder fehlender Prozess, den diese Software jetzt per Knopfdruck abbilden und vereinfachen soll. Das kann natürlich nicht funktionieren.

Was hätten Sie sich den konkret an Hilfe und Unterstützung gewünscht?

Vermutlich benötigt es viel mehr Beratung und Analyse der vorhandenen Prozesse und Strukturen, bevor man eine IT-Infrastruktur aufbaut und neue Software einführt – da wäre eine bessere Beratung und eine schonungslose Analyse durch den externen Anbieter hilfreich. Es benötigt, vor allem in größeren, schwerfälligeren Organisationen, einen Lernprozess:
Es ist der falsche Weg, kommerzielle Lösungen langwierig, teuer und fehleranfällig zu “customizen”, um sie an die vorhandenen aber veralteten Prozesse einer Organisation anzupassen. Stattdessen muss der Status Quo zunächst analysiert, Prozesse aktualisiert werden. Und manchmal muss man dann die Prozesse auch an die Softwarelösung anpassen, um das Optimum herauszuholen.

Die Digitalisierung schlägt auch in die Zulieferkette immer mehr durch und Prozessabläufe und der Datenaustausch werden elektronisch gestaltet und automatisiert. Welche positiven Effekte sehen Sie denn aus der Sicht des Qualitätsmanagements bei dieser Entwicklung?

Tatsächlich durfte ich in der Halbleiterindustrie lernen, wie man die Digitalisierung wirklich nutzt, um Ressourcen im Bereich Einkauf und Qualität zu entlasten und für wichtigeres zu nutzen: Bestellprozesse, Lagerüberwachungen aber auch die digitale Übertragung von Produktspezifikationen, Mess- und Prüfergebnissen und Zeugnissen waren dort selbstverständlich und eine echte Arbeitserleichterung. Die gewonnene Zeit haben wir in echte Lieferantenüberwachung investiert, zum Beispiel in regelmäßige Review-Meetings.

Gibt es auch negative Effekte dabei?

Wie schon beschrieben löst die Digitalisierung nicht das Problem schlechter Prozesse. Gleichzeitig besteht die Gefahr, dass die
Organisation sich auf Software verlässt und Fehler sogar später erkannt werden. Ein schönes Beispiel aus einem anderen Unternehmen war die Beschaffung von Komponenten für ein schon obsoletes Produkt:
Die Prozesse des PLM hatten versagt, so dass Komponenten weiter bestellt, nach Ablauf der Mindesthaltbarkeit (kostenpflichtig) entsorgt und auf Grund einer hinterlegten Mindestlagermenge dann wieder neu bestellt wurden – in Summe fünf mal in fünf Jahren, bis endlich auffiel, dass dem inzwischen sechsstelligen Einkaufsvolumen kein Umsatz gegenüberstand.

Sie sind ein wichtiger Stakeholder und Key-User des PLM-Systems. Was würden Sie sich denn von den Herstellern dieser Systeme wünschen, um ihre tägliche Arbeit zu erleichtern?

Ich würde mir heute wünschen, dass die Hersteller solcher Systeme im Vorfeld ausführlicher beraten und viel schonungsloser klarmachen, wo ihre Systeme auf Grund vorhandener Schwächen in der Organisation des Kunden an ihre Grenzen kommen.
Ich stelle mir vor, dass das viele Kunden zunächst gar nicht gerne hören wollen, aber für den langfristigen Erfolg und eine zufrieden stellende Zusammenarbeit ist es meines Erachtens unerlässlich.

Herzlichen Dank, Herr Dr. Klüber-Demir für dieses erkenntnisreiche Gespräch. Ich wünsche Ihnen für Ihre weiteren Projekte maximale Erfolge.

Das PLM-Leben ist nicht ohne Risiko

Veröffentlicht am 23. März 2021, aktualisiert am 23. März 2021 von Christoph

Wir alle absolvieren in diesen Zeiten eine medizinische Ausbildung. Vor ein paar Monaten wusste noch niemand, was ein Inzidenzwert ist. Heute kann den jeder im Kopf ausrechnen und den Verlauf über die letzten Woche grafisch darstellen.

Das unser Leben risikobehaftet ist, kann niemand abstreiten. In der Medizintechnik spielt dieses Risiko schon immer eine wichtige Rolle. Der Einsatz von Medizingeräten ist oft ein Abwägen des Nutzens gegen die damit einhergehende Gefahr eines Schadens.

Dazu ein anschauliches Beispiel: Mit einem Skalpell wird während einer Operation einem Patienten eine Wunde zugefügt. Ohne den medizinischen Kontext wäre das eine vorsätzliche Körperverletzung. Aber ohne die Inkaufnahme dieser Verletzung kann man eben auch nicht das Krebsgeschwür entfernen, dass sich im Körper ausbreitet. Der Nutzen (Geschwür entfernen) überwiegt dem Schaden (Wunde). Dabei muss natürlich alles dafür getan werden, diese Verletzung möglichst gering zu halten und den daraus entstehenden Schaden zu begrenzen.

In der Entwicklung von Medizingeräten ist die Analyse und Bewertung von Risiken und den damit verbundenen Schäden ein essentieller Bestandteil des Produktentwicklungsprozesses. In diesem Prozess muss eine Risikoanalyse durchgeführt werden, um eine möglichst geringe Gefährdung von Patienten und des medizinischen Personals sicherzustellen.

Diese Forderung schlägtsich in den einschlägigen Normen und Standards wie der ISO 14971 nieder. Es wird die Durchführung und Dokumentation der Risikoanalyse, Risikobewertung, Risikokontrolle und Informationen aus der Produktion und der Produktion nachgelagerten Phasen verlangt.

In diesem Artikel möchte ich aber gar nicht diese Prozesse tiefer betrachten. Dafür gibt es Qualitätsmanagement-Experten, die sich richtig gut damit auskennen. Es geht mir eher um die Beantwortung der Frage, wie PLM das Risikomanagement unterstützen kann und man so zu einer höheren Effektivität (die richtigen Dinge tun) und Effizienz (die Dinge richtig tun) gelangt. Aus meiner Erfahrung heraus konnte ich folgende Dinge identifizieren:

Integration des Risikomanagement in den digital Thread des Medizinproduktes

Das Risikomanagement als Teil des Produktentwicklungsprozesses benötigt als Eingangsgröße valide Produktdaten – schließlich müssen die Risiken des bestimmungsgemäße Gebrauch des Medizinp

roduktes analysiert und bewertet werden. Diese Produktdaten sind aber keineswegs statisch, sondern ändern sich. Das Speichern des Entwicklungstandes, zu dem eine Risikobewertung erstellt wurde, ist essentiell wichtig. Außerdem werden Dinge richtig getan, wenn der Risikoanalyst sich nicht seine Produktdaten aus verschiedenen Quellen zusammensuchen muss, sondern sich auf Gültigkeit und Datenqualität verlassen kann.

Aufbrechen der Risikobewertung innerhalb der Produktstrukturen und Stücklisten

Gerade Medizingeräte sind äußerst innovativ und beinhalten komplexe Strukturen – sei es aus tiefen Stücklisten aus z. B. der mechanischen Konstruktion oder, weitaus öfter, weil das Produkt aus mechanischen, elektrischen, elektronischen und Software-Komponenten besteht. In neuerer Zeit kommen auch immer mehr Services als integraler Produktbestandteil und somit eine weitere Komplexitätsebene dazu.

Das hat auch Auswirkungen auf die Risikobewertung. Die Risikoanalysten für die Software verlinken dann ihre Bewertungen mit dem Software-Baum der Produktstruktur. Der Lebenszyklus von Softwarekomponenten ist deutlich kürzer als der von mechanischen. Eine saubere Verlinkung der Risikobewertung in die jeweiligen Sub-Bäume hilft, beides voneinander zu trennen und somit die unterschiedlichen Bedürfnisse der Softwerker und Mechaniker zu befriedigen. Eben die Dinge richtig zu tun.

Aufbrechen der Risikobewertung entlang des Produktlebenszyklus

Eine Produktentwicklung in der Medizintechnik startet mit der Definition des Design Inputs, also der Definition eines ersten “Intended Use” und der Aufnahme der Anforderungen an das Medizinprodukt. Aufgrund der bereits angesprochenen Produktkomplexität wird das zukünftige Medizinprodukt in funktionale, systemische oder logische Bestandteile strukturiert. Eine Preliminary Hazard Analysis (PHA) sorgt für erste Ergebnisse. Diese Methode konzentriert sich auf die Identifizierung von Schwachstellen in einem frühen Stadium der Lebensdauer eines Systems und spart so Zeit und Geld, die für ein größeres Redesign erforderlich wären, wenn die Gefahren zu einem späteren Zeitpunkt entdeckt würden. Daher haben PHAs einen Bezug zum Systemdesign und damit zur funktionalen und logischen Produktstruktur.

Ganzheitliches Änderungswesen

Das Aufbrechen der Risikoanalyse in sinnvolle Bestandteile und da damit einhergehende genau Verlinkung der Eingangs- und Ausgangsdaten in das Produktdatenmodell erlauben dann eine vollständige und schnelle Auswirkungsanalyse von Änderungen. Dann zahlen sich die bisher gelegten Grundlagen aus, in dem entlang des digital Threads nachvollzogen werden kann, welche Daten wie zusammenhängen und somit eine vollständige Analyse der betroffenen Produktdaten möglich ist. Das spart immens Zeit und erhöht die Qualität, gerade auch im Hinblick auf die Risikobewertungen. Wenn diese Bestandteil sauber in den digital Thread integriert sind, können notwendige Änderungen und Anpassungen auch getriggert und nachvollzogen werden.

Aber dieser signifikante Einspar- und Qualitätseffekt steht und fällt mit der Vollständigkeit aller Einzelfäden. Fehlen einige, enstehen Löcher im Datenmodell, die sehr aufwendig manuell geflickt werden müssen.

Aktivitätsnachverfolgung

PLM-Systeme bilden Wertschöpfungsprozesse ab und in diesen fallen Aktivitäten und Aufgaben an. Diese Aufgaben werden den jeweiligen Verantwortlichen zugestellt und deren Abarbeitung nachvollziehbar gespeichert. Reviews und Freigaben von Daten und Dokumenten werden im Audit Trail gespeichert.

Auch im Risikomanagementprozess fallen Aufgaben an und auch dort müssen Daten und Ergebnisse überprüft und freigegeben werden. Das betrifft insbesondere die Maßnahmen zur Mitigation von Risiken.

Die Funktionen des PLM-Systems sollten dafür genutzt werden. So kann allen Anwendern eine Single Source of Arbeitsvorrat zur Verfügung gestellt werden und deren Abarbeitung nachvollziehbar gespeichert werden.

Unterstützung des Reportings, Datenaufbereitung und -nachverfolgung

Am Ende müssen die einzelnen Fäden der Risikobewertung auch wieder zusammenlaufen. Auf der Ebene des Medizinproduktes ist eine komplette Sicht auf alle Bestandteile der Risikobewertung unabdingbar. Schließlich muss sichergestellt werden, dass alle Schritte des Risikomanagements durchlaufen wurden. Zur Dokumentation wird oft ein Risk Management Report verwendet.

Wenn die Risk Management Reports nachvollziehbar mit den Revisionsständen der Produktdaten verknüpft sind, hat das entscheidenden Einfluss auf die Effizienz und Effektivität: Es wird die richtigen Dinge getan, da der Entwicklungsstand und Reifegrad des Medizinproduktes mit dem Stand der Risikobewertung fest verknüft ist. Und es werden Dinge richtig getan, da an der Entwicklung des Medizinproduktes und an der damit verbundenen Risikobewertung sofort weiter gearbeitet werden kann und die historischen Relationen erhalten bleiben. Ähnliches gilt natürlich auch für die Bildung von Produktvarianten und Produktfamilien.

Unterstützung vom Wiederverwendung

Eine komplette Neuentwicklung eines Medizinproduktes erfolgt doch nur in seltenen Fällen. Der weitaus häufigere Anwendungsfall ist doch, dass ein vorhandenes Produkt angepasst wird. PLM-Systeme unterstützen vielfach diese Szenarien durch Funktionen im Produktenwicklungsmodul, z.B. durch die intelligente Kopieren und Anpassen von Stücklisten und Produktstrukturen. Wenn von dieser Intelligenz nicht nur Bauteile und Baugruppen erfasst werden, sondern auch die Daten der Risikoanalyse, dass werden wieder Dinge richtig getan. Wiederverwendnung spart auch hier Zeit und Aufwand.

Alle diese Aspekte führen zu einer oft diskutierten Abwägung der Ver- und Nachteile einer speziellen Risikomanagement-Software gegenüber der Nutzung von Funktionen im PLM-System. Das PLM System bildet das Rückgrat für alle Produktdaten und steuert die damit verbundenen Wertschöpfungsprozesse. Hier laufen die Fäden zusammen, die dann zu einem vollständigen Digital Thread des Medizinproduktes zusammengefügt werden.

Ob alle Einzelfäden auch im PLM-System erzeugt werden müssen oder manche auch von Spezialsystemen kreiert werden können, ist eine unternehmens- und anwendungsfallspezifische Abwägung. Entscheidend ist nur die Integration, das Risikomanagement darf nicht als Dateninsel isoliert existieren.

Dinge richtige tun und richtige Dinge tun, beides steht und fällt mit der Integration von Daten. Und das ist genau der Kern eines PLM, die Verbindung von Daten, Prozessen, Systemen und den Anwendern.