“PLM ist tot” — höre ich immer wieder. Stimmt, vielleicht. Und stimmt auch wieder nicht. Denn es kommt darauf an, was man unter PLM versteht. Aus einer bestimmten Perspektive kann die Aussage durchaus Sinn geben. Nicht aus meiner, wohlgemerkt. Denn ich denke, PLM ist lebendiger denn je. Und ich erkläre gern, warum.
PLM-Software oder PLM-Disziplin? Der entscheidende Unterschied
Fangen wir bei der Frage an, was PLM überhaupt sein will.
Lesart eins
PLM sind die großen Suiten — Teamcenter, Windchill, ENOVIA. Monolithische Systeme, die versprechen, den gesamten Produktlebenszyklus abzubilden. Spoiler: Für diese Lesart hat der Satz “PLM ist tot” - vielleicht - eine Berechtigung. Nicht zwingend, aber vertretbar.
Lesart zwei
PLM ist die Disziplin, die alles umfasst, was zum Product Lifecycle dazugehört. Konfigurationsmanagement, Änderungsmanagement, Traceability, Systemintegration über den gesamten Lebenszyklus. Für diese Lesart ist PLM alles andere als am Sterben. Sondern entfaltet sich gerade erst zu dem, was es immer schon sein wollte.
Meine Sicht auf PLM war schon immer die zweite Lesart. Für mich beschreibt sie, was PLM eigentlich meint — und wem das zu eigensinnig klingt: Gartner definiert PLM als “philosophy, process and discipline supported by software”. Disziplin zuerst, Software als Hilfsmittel. Trotzdem verstehen viele PLM eher als Produktkategorie für Suiten im Engineering-Kontext.
Was stirbt: die monolithischen PLM-Suiten
Dass diese bekannten, oft monolithische PLM-Suiten das dominierende Modell bleiben, das steht heute allerdings mehr denn je in den Sternen. Denn die Richtung, wohin die Reise geht, ist klar, auch wenn der Prozess langsam ist. Drei Gedanken dazu:
Erstens: Der Glaube, ein System könne alles abdecken, ist in vielen Fällen nicht tragfähig. Legacy-PLM-Anbieter sind durch Übernahmen gewachsen, nicht (nur) durch architektonische Innovation. Das Ergebnis sind, wie der PLM-Analyst Oleg Shilovitsky (der allerdings selbst einen dezentralen PLM Ansatz verkauft) es beschreibt, “Konglomerate von Werkzeugen, zusammengehalten durch Integrationen — manchmal mit inkompatiblen Datenmodellen”. Wer die Erfahrung schmerzlich machen durfte, nickt. Wer nicht, der lernt es noch.
Zweitens: Das Make-or-Buy-Pendel schwingt Richtung Make — und KI beschleunigt das. Nicht weil Entwickler jetzt zehnmal schneller coden. Sondern weil klar abgegrenzte PLM-Randdomänen — Release-Plattformen, Änderungsmanagement-Workflows, spezifische Traceability-Lösungen — plötzlich realistisch eigenentwickelbar sind. Was früher an Aufwand und Wartungsrisiko scheiterte, lässt sich heute mit deutlich kleineren Teams machen. Das gilt vielleicht (noch) nicht für eine komplette PLM Bebauung. Aber für die Stellen, wo monolithische Lösungen überdimensioniert sind und trotzdem jährlich Lizenzkosten erzeugen, verschiebt sich die Kalkulation.
Rückblende auf ein Projekt, an dem ich vor ein paar Jahren selber beteiligt war: Ein Kunde wollte eine eigene Software-Releaseplattform bauen. Alles eigenentwickelt. Ich war damals skeptisch, und habe eine Nachschau empfohlen, welche Lösungen es denn von der Stange gäbe. KI-gestützte Coding, das solche Vorhaben heute viel erschwinglicher macht, gab es damals noch nicht. Der Kunde hatte sich festgelegt, und aufgrund seiner Größe war es machbar, wenn auch teuer, keine Konfektionsware zu nehmen. Vielleicht auch zu teuer. Fast Forward: mit den heutigen Möglichkeiten sähe meine Einschätzung sehr wahrscheinlich anders aus, was nicht heißt, dass ich heute “von der Stange” ablehnen würde. Aber die Tendenzen ändern sich.
Drittens: PLM als Dokumentenarchiv war einmal — die Ansprüche waren eigentlich schon immer größer. Dass PLM mehr sein muss als ein glorifiziertes Dokumentenarchiv, ist inzwischen Konsens. Konsens ist aber lange noch nicht operationalisiert, und in der operativen Realität hinkt das Handeln der Einsicht hinterher. Dabei klingt der Anspruch gar nicht so überirdisch, was ein modernes PLM-System tatsächlich leisten sollte: ein strukturiertes Produktdatenmodell, das Bauteile, Varianten, Abhängigkeiten und Änderungshistorien maschinenlesbar abbildet. Durchgängige Traceability von der Anforderung über Code und CAD bis zum fertigen Produkt im Feld. Integration aller relevanten Prozesse von A wie After Sales bis Z wie Zeichnungsarchiv.
Nur: Ein Werkzeug, das für alles taugt, taugt für niemanden richtig. Das gilt für Schweizer Taschenmesser, und es gilt für monolithische PLM-Suiten. Das Datenmodell ist generisch, weil es generisch sein muss. Vollintegration gibt es nicht, weil es im Unternehmen immer auch noch andere Systemwelten gibt (Stichwort ERP). Und: wer ein wirklich tiefes, domänenspezifisches Produktdatenmodell aufbauen will — eines, das die eigenen Teile, Varianten und Prozesse präzise abbildet — steht im Monolithen vor Anpassungsaufwänden, die potentiell jeden Mehrwert auffressen können. Spezialisierte Tools mit offenen Standards umgehen dieses Problem zumindest teilweise, weil sie von vorneherein auf Interoperabilität ausgelegt sind, nicht auf Vollständigkeit.
Was nicht stirbt: PLM als Disziplin — denn der Bedarf wächst
Fakt ist: Produkte werden komplexer. Systemgrenzen zwischen Mechanik, Elektronik und Software verschwimmen.
Beispiel Automotive: OEMs verlieren nach Schätzungen zwischen 500 Millionen und einer Milliarde US-Dollar pro Jahr durch physische Rückrufe, die technisch als OTA-Update möglich wären (eSync Alliance, 2023; ABI Research, 2023). Dass OTA-Updates in der Breite immer noch nicht da sind, wo sie rein technisch sein könnten, ist eben auch der Komplexität der Produkte geschuldet. Ein Auto ist eben keine einfache Maschine mehr wie früher, die im Zweifel in jeder Wüstenwerkstatt repariert werden kann. Damit ein OTA-Update funktioniert, und ich spreche aus Erfahrung, braucht es eine gut geschmierte Maschinerie, die den Gesamtüberblick über alle Produkte im Feld, ihre Konfiguration, ihren Softwarestand und alle Abhängigkeiten behält.
Deshalb: Konfigurationsmanagement, Änderungsmanagement, Traceability über den gesamten Lebenszyklus… der Bedarf an Professionalisierung dieser Disziplinen wird alles andere als kleiner. Im Gegenteil, er wird anspruchsvoller.
Natürlich, wer “PLM ist tot” sagt und noch ein PLM-Projekt in den Knien hat, das nicht geliefert hat, den kann ich verstehen. Nur hat derjenige dann möglicherweise das Symptom mit der Krankheit verwechselt. Das Tool hat gestrauchelt, aber die Disziplin, die Durchgängigkeit und das Mindset dahinter wurden womöglich nie wirklich gelebt und womöglich auch nicht verstanden.
Ein Satz, der dem PLM-Veteranen Rob Ferrone zugeschrieben wird, sagt mehr als zehn Foliensätze: „Meine ersten fünf Jahre wusste ich nicht einmal, dass wir PDM oder PLM machen — aber wir taten es.”. Wenn das umgekehrt auch gilt, wenn Unternehmen die Software kaufen, aber die Disziplin nie implementieren, dann ist die Frustration verständlich — sie trifft aber die Art, wie PLM eingeführt wurde, nicht die Disziplin selbst.
Nur 13% meinen, sie könnten ohne PLM nicht arbeiten
Dazu noch eine Zahl, die aufhorchen lässt: Nur 13% der Unternehmen, die PLM einsetzen, sagen, sie könnten nicht ohne es arbeiten. Ob es 10, 13 oder 20% sind, ist fast egal. Die eigentliche Aussage steckt im Umkehrschluss: Die meisten Unternehmen glauben, sie könnten PLM weglassen. Nein. Können sie nicht. Jedes Unternehmen, das Produkte entwickelt und produziert, betreibt PLM — in der einen oder anderen Form. Die Frage ist nur, ob es versteht, was es da tut…
Die eigentliche Herausforderung: Fehlende Architektur und ungenügende Organisation
Der Digital Thread — die durchgängige, bidirektionale Datenspur vom Requirement bis in den Betrieb — ist die Vision, die schon immer eng verknüpft mit dem PLM-Begriff war. “Single Source of Truth”, Traceability von der Anforderung bis ins Feld: Versprochen haben das die Vendoren schon in den Nuller-Jahren. Eingelöst wurde es leider allzu oft nicht, aus verschiedensten Gründen:
Woran es scheitert, ist dabei nämlich erstaunlich selten die Software. Es ist das, was um die Software herum fehlt: Informations- und Datenstrukturen. Ontologien. Eine Organisation, die bereit ist, ihre Prozesse ernsthaft anzufassen. Kurz: Architektur. Und die entsteht nicht von selbst — egal, ob man kauft oder baut.
Wer kauft, kauft ein Fertighaus. Und wer sich ein Fertighaus kauft, muss bereit sein, sich auf vorgegebene Grundrisse einzulassen. Auch wenn das bedeutet, liebgewonnene Gewohnheiten loszulassen und sich an neue Arbeitsabläufe zu gewöhnen. Das passiert freilich nicht von selbst. Das ist Arbeit. Und genau diese Arbeit scheut man gern — die eigenen Bestands-Prozesse sind ja oft sowas wie der heilige Gral, und der bisherige Erfolg gibt einem womöglich sogar Recht. Nur: Wer die Standardsoftware dann doch verbiegt, statt sich anzupassen, holt sich die Anpassungsaufwände ins Haus, die jeden Mehrwert auffressen können. Das Scheitern ist dann kein Software-Problem. Es ist ein Hausaufgaben-Problem.
Wer baut, hat das Grundriss-Problem nicht — dafür ein anderes. PLM-Tools, denen immer noch das ein oder andere Wunschfeature fehlt, plus die neue Verfügbarkeit KI-gestützter Softwareentwicklung: Das verleitet schnell zur Entscheidung, etwas Eigenes bauen zu wollen. Sei es komplett “from scratch”, sei es als sehr individuelle Verknüpfung verschiedenster Tools. Kann man machen, siehe oben — die Kalkulation hat sich ja tatsächlich verschoben. Aber: Eine durchgängige Digital-Thread-Bebauung braucht erst recht eine Architektur. Wer einfach drauflosbaut, baut eine Toollandschaft, die anfangs irgendwie funktioniert, nach kurzer Zeit kaum noch wartbar ist — und einem irgendwann um die Ohren fliegt. Excel-IT lässt grüßen.
Ergo: Der Invest in Organisation und Informationsarchitektur ist keine Option, sondern die Eintrittskarte. Auf beiden Wegen. Wer das verstanden hat — und nur der —, für den wird die Make-Option interessant: Denn wenn die Architekturarbeit ohnehin anfällt, ist der Vorsprung des Monolithen kleiner, als sein Preisschild suggeriert. Ein dezentraler Lösungsansatz fern der etablierten Suiten ist dann heute mehr denn je zumindest eine Erwägung wert. Es könnte sich lohnen.
Aber zurück zur Ausgangsfrage. Ist PLM tot?
❤️ PLM lebt
Wenn PLM die Disziplin meint (und daran halte ich fest) dann lautet die Antwort eindeutig: PLM ist lebendiger denn je. Die Anforderungen werden nicht kleiner. Die Produkte nicht einfacher. Und die Kosten, diese Disziplin zu vernachlässigen, werden größer.
Ob die großen PLM-Monolithen das Zeitliche segnen? Ich weiß es nicht, und ich halte mich mit Prophezeiungen zurück. Argumentationen, die dafür sprechen, sind zumindest plausibel. Aber die PLM-Vendoren sind auch nicht doof — die sehen die Veränderungen, die wir alle sehen, auch. Offenere Architekturen, modularere Angebote, SaaS — das kommt bereits, und bei manchen Vendoren stärker, als bei anderen. Ob es greift, wird der Markt entscheiden.
Long live PLM 😉🖖
Häufig gestellte Fragen
Ist PLM tot oder nicht?
Kommt auf die Lesart an. Als monolithische Suite (Teamcenter, Windchill, ENOVIA) ist die Aussage zumindest eine Diskussion wert. Als Disziplin — Konfigurationsmanagement, Änderungsmanagement, Traceability, etc. — ist sie schlicht falsch. Diese Disziplin wird wichtiger, nicht überflüssiger.
Was unterscheidet PLM-Software von PLM als Disziplin?
Die Software ist das Werkzeug, die Disziplin der Zweck dahinter. Gartner definiert PLM als “philosophy, process and discipline supported by software” — Disziplin zuerst, Tool danach. Ein gescheitertes PLM-Projekt heißt deshalb nicht, dass die Disziplin gescheitert ist, sondern oft nur, dass sie nie wirklich gelebt wurde.
Lohnt sich PLM Eigenentwicklung (Make) jetzt eher als der Kauf einer PLM-Suite (Buy)?
Die Kalkulation verschiebt sich, weil KI-gestützte Entwicklung abgegrenzte PLM-Randdomänen realistisch selbst baubar macht. Für eine komplette PLM-Bebauung gilt das meist (noch) nicht. Und: Auch Make erspart die Architekturarbeit nicht — wer einfach drauflosbaut, landet bei einer Toollandschaft, die schnell unwartbar wird.
Was ist der Digital Thread, und warum ist er relevant?
Die durchgängige, bidirektionale Datenspur vom Requirement über CAD und Code bis ins Feld — die Vision, die PLM seit den Nuller-Jahren verspricht. Eingelöst wird sie oft nicht, weil die Architektur dahinter fehlt, nicht weil die Software es nicht könnte.