Was ist Product Lifecycle Management (PLM)?

Product Lifecycle Management (PLM) begegnet uns häufig im Systems Engineering. Doch häufig gehen wir – oder andere davon aus, dass ein gemeinsames Verständnis besteht, was damit gemeint ist. Von einem gemeinsamen Verständnis sollte man nie ausgehen, bei keinem Begriff. Und besonders dann, wenn viel auf dem Spiel steht oder sich längere Debatten entwickeln ist es an der Zeit, mit einer klaren Begriffsdefinition ein solides Fundament zu setzen. Viele Diskussionen lassen sich darauf zurückführen, dass implizit unterschiedliche Definitionen angenommen wurden.

Also, was ist PLM?

Einfach Alles

Die abstrakte Definition ist einfach:

PLM ist ein Konzept zur nahtlosen Integration sämtlicher Informationen, die im Verlauf des Lebenszyklus eines Produktes anfallen (Sudarsan et. al., 2010)

Hier sind zwei Dimensionen zu beachten: Die zeitliche Dimension und die informelle Dimension. In der zeitlichen Dimension denken wir in der Regel von Idee bis zum Ende des Produktsupports, oft einschließlich Verschrottung. Informell denken wir in der Regel an alle Artefakte der Produktentwicklung. Dazu gehören unter anderem:

  • Anforderungen und andere Artefakte des Systems Engineering
  • Zeitpläne und andere Artefakte des Projektmanagements
  • CAD-Pläne, und andere Artefakte der Konstruktion
  • Ressourcen, Fertigungsanlagen und andere Artefakte der Produktion
  • Wartung, Kundenservice und andere Dienstleistungen

Hier wird vielleicht schon ersichtlich, dass die Abgrenzung von PLM gar nicht so einfach ist: Ist Marketing Teil von PLM? Und wenn ja, nur Produkt-Marketing, oder auch die Webseite? Wie sieht es mit der Personalabteilung aus?

Hier gibt es kein „richtig“ und „falsch“. Statt dessen sollte für PLM-Initiativen unbedingt der Scope klar definiert werden. Nicht vergessen; PLM ist ein „Konzept zur nahtlosen Integration.“ Typischerweise werden in einer PLM-Initiative diese Integrationen eingeführt oder ausgebaut. Daher ist der Scope einer PLM-Initative immer eine Untermenge des Scopes von PLM.

Warum PLM?

Eine „nahtlose Integration sämtlicher Informationen, die im Verlauf des Lebenszyklus eines Produktes anfallen“ kostet Geld und darf kein Selbstzweck sein. Was ist also der Business Case für PLM? Hier treffen wir die üblichen Verdächtigen, zum Beispiel:

  • Innovation ermöglichen bzw. beschleunigen
  • Umsatz erhöhen
  • Produktivität erhöhen
  • Kosten Reduzieren
  • Qualität erhöhen
  • Compliance sicherstellen
  • Markteintritt neuer Produkte beschleunigen.

PLM umsetzen – aber wie?

Für die nahtlose Integration von Informationen werden Werkzeuge benötigt. Damit allein ist es nicht getan, denn Product Lifecycle Management erfordert auch ein Umdenken und anpassen von Prozessen, um die Informationen auch effizient nutzen zu können.

Bei PLM-Initiativen beginnen wir nie auf der grünen Wiese (Ausnahmen bestätigen die Regel). Daher gibt es bereits Informationen, die allerdings noch nicht nahtlos integriert sind. Hier sollten Unbedingt zwei Dinge im Vorweg geklärt werden:

1. Erst die Anwendungsfälle des PLM definieren!

Ich habe viel zu oft gesehen, dass Daten gesammelt und/oder integriert wurden, um sich über den Sinn und Zweck wirklich im klaren zu sein. Wer nutzt die integrierten Daten, und zu welchem Zweck? Zum Beispiel könnten Daten der Resourcenplannung mit dem Backlogs integriert werden, um ungenutze Ressourcen zu finden und sinnvoll einzusetzen.

2. Die Architektur der IT-Landschaft definieren!

Es gibt Hersteller von PLM-Systemen. Das Versprechen ist, mit einem System alle Aspekte des Product Lifecycle Management abzudecken. Nur: Wie ich bereits sagte, PLM beginnt nie auf der grünen Wiese.

Die Werkzeug-Frage

Die Einführung eines allumfassenden PLM-Systems birgt viele Risiken:

  • Es kann Redundanzen zu Bestandsystemen geben
  • Wichtige Funktionen werden nicht sonderlich gut unterstützt, oder fehlen gänzlich
  • Die geforderten Anwendungsfälle können möglicherweise gar nicht durchgeführt werden!
  • Man macht sich von einem Hersteller abhängig

Es kann durchaus sinnvoll sein, ein komplettes PLM-System anzuschaffen. Es sollten jedoch die gerade aufgeführten Fragen (und mehr) vorher sorgfältig geprüft werden.

Es gibt Alternativen zu einem monolithischen PLM-System, von denen ich die folgenden drei vorstellen möchte:

Integration von integrierbaren Werkzeugen. Heutzutage würde ich sowieso großen Wert auf Integrierbarkeit legen. Typische Schnittstellen sind REST API oder OSLC. Die Gefahr bei diesem Ansatz ist, dass schnell Wildwuchs entstehen kann. die IT-Architektur muss wie ein richtiges Projekt sorgfältig gepflegt werden.

Integrations-Hub. Es gibt Werkzeuge, die als Daten-Drehkreuz agieren. Diese haben in der Regel eine Anzahl von Adaptern für populäre Werkzeuge. Damit können dann mächtige Integrationsszenarien realisiert werden. Der Vorteil hier ist, dass diese Lösungen sehr robust sind und zuverlässig funktionieren. Allerdings werden selten alle zu integrierenden Werkzeuge vom Hub unterstützt. In so einem Fall kann der Hub auch mit der direkten Integration kombiniert werden.

Business Intelligence. Es gibt auch Werkzeuge, die lediglich lesend auf verschiedene Datenquellen zugreifen. Hiermit lassen sich – offensichtlich – nur bestimmte Anwendungsfälle umsetzen. Dennoch sind solche Werkzeuge gut für den Einstieg ins PLM geeignet: Denn hier bekommt man sehr schnell brauchbare Informationen über die Produktentwicklung. Dabei wird nicht riskiert dass Daten korrumpiert werden – schließlich werden Daten nur gelesen.

Wie gesagt, es gibt noch viele andere Optionen. Wichtig ist es hier, sich Gedanken zu machen.

Fazit

Beim Product Lifecycle Management geht es um Informationen, und zwar allen, die etwas mit der Produktentwicklung zu tun haben. Weiterhin geht es darum, diese Informationen effektiv zu nutzen. In der Praxis ist es sinnvoll, den Scope einzugrenzen, indem wir konkrete PLM-Initiativen definieren (die sich in eine PLM-Strategie einordnen). PLM lässt sich nicht ohne entsprechende Werkzeuge realisieren. Hier ist wichtig, dass zuerst Anwendungsfälle und IT-Architektur geklärt werden.

PLM ist nicht einfach, aber richtig implementiert, hat es das Potential, die Produktentwicklung nachhaltig zu reformieren.

Photo by Sean Patrick Murphy on Unsplash