Anders durch Design. Anders für das, was als Nächstes kommt.

Der Inhalt dieser Seite wurde automatisch von einem Drittanbieter übersetzt.

Nach fast 30 Jahren in der Product-Lifecycle-Management-Branche habe ich gelernt, dass PLM niemals wirklich stillsteht.

Ich war 15 Jahre bei Siemens, 10 Jahre bei PTC und bin nun seit zwei Jahren bei Aras. In dieser Zeit habe ich erlebt, wie sich PLM über mehrere unterschiedliche Phasen hinweg entwickelt hat. Jede dieser Phasen wurde von neuen geschäftlichen Anforderungen, zunehmender Produktkomplexität und den jeweils verfügbaren Technologien geprägt.

Was ursprünglich vor allem als Möglichkeit zur Verwaltung von Engineering-Dateien begann, ist zu einer entscheidenden Grundlage dafür geworden, wie Unternehmen immer komplexere Produkte entwickeln, fertigen, warten und kontinuierlich verbessern.

Die Branche hat enorme Fortschritte gemacht. Gleichzeitig ist auch die Komplexität gewachsen. Viele Hersteller arbeiten heute mit fragmentierten Produktinformationen, stark angepassten Systemen, voneinander getrennten Prozessen und jahrzehntelang aufgebautem, wertvollem Engineering-Wissen, das über zahlreiche Systeme und Anwendungen verteilt ist.

Heute sorgt künstliche Intelligenz für einen weiteren bedeutenden Wendepunkt.

Die eigentliche Frage geht über das Hinzufügen von KI-Funktionen zu PLM hinaus. Langfristiger Nutzen hängt davon ab, ob die zugrunde liegende PLM-Umgebung den vernetzten Kontext, die Anpassungsfähigkeit und die Governance bereitstellt, die KI benötigt. Deshalb bin ich überzeugt, dass es darauf ankommt, anders zu sein.

PLM entstand aus einem unmittelbaren Problem im Engineering

Die Ursprünge des modernen PLM lassen sich auf einen praktischen Bedarf zurückführen: Unternehmen, die CAD-Tools einführten, benötigten eine zuverlässige Möglichkeit, Engineering-Dateien zu speichern, zu kontrollieren und zu verwalten.

Mit der zunehmenden Verbreitung digitaler Konstruktion mussten Hersteller wissen, welche Zeichnung aktuell war, wer sie geändert hatte und welche Version freigegeben worden war. Das Produktdatenmanagement entstand, um die schnell wachsende Menge digitaler Engineering-Informationen strukturiert zu verwalten.

Von dort aus erweiterte sich der Anwendungsbereich.

Unternehmen begannen, Stücklisten, Produktstrukturen, Dokumente, Revisionen, Freigaben und technische Änderungen zu verwalten. PLM ging über die reine Dateispeicherung hinaus und entwickelte sich zu einem System zur Steuerung der Produktdefinition.

Das war ein wichtiger Fortschritt, doch die in dieser Zeit entstandenen Systeme waren naturgemäß von den damaligen Herausforderungen und technologischen Einschränkungen geprägt.

Sie konzentrierten sich häufig auf Engineering-Abteilungen, CAD-Umgebungen und stark strukturierte Produktdaten. Oft wurden sie als große, monolithische Implementierungen bereitgestellt, die darauf ausgelegt waren, Prozesse zu standardisieren und eine strenge Kontrolle aufrechtzuerhalten.

Für die Herausforderungen dieser Zeit war dieser Ansatz sinnvoll.

PLM weitete sich auf das gesamte Unternehmen aus

Mit zunehmender Komplexität von Produkten und Organisationen erwarteten Unternehmen mehr von PLM.

Engineering-Teams arbeiteten nicht mehr nur an einem Standort oder innerhalb einer einzigen Disziplin. Unternehmen mussten über globale Entwicklungszentren, Geschäftsbereiche, Lieferanten, Produktionsstandorte und Serviceorganisationen hinweg zusammenarbeiten.

PLM wurde erweitert, um umfassendere Prozesse zu unterstützen, darunter Anforderungsmanagement, Qualität, Fertigungsplanung, Zusammenarbeit mit Lieferanten, Konfigurationsmanagement, Systems Engineering und Service.

Auch die Beziehung zwischen PLM und anderen Unternehmenssystemen gewann zunehmend an Bedeutung. Die Produktentwicklung konnte nicht länger unabhängig von ERP, MES, Lieferkette, Qualität und anderen operativen Systemen arbeiten.

Unternehmen wollten überall entwickeln und überall produzieren können. Sie benötigten föderierte Umgebungen, die global verteilte Teams unterstützen und gleichzeitig die Kontrolle über Produktkonfigurationen und Änderungen gewährleisten konnten.

Die Vorstellung vom Produktlebenszyklus ging zunehmend weit über die Engineering-Abteilung hinaus.

Doch mit der Ausweitung von PLM wurden Implementierungen häufig komplizierter. Systeme wurden an sehr spezifische Prozesse angepasst. Die Zahl der Integrationen nahm zu. Upgrades wurden schwieriger. In manchen Fällen investierten Unternehmen so viel Aufwand in den Erhalt des implementierten Systems, dass die Anpassung an neue geschäftliche Anforderungen selbst zu einem großen Vorhaben wurde.

Das System, das Veränderungen verwalten sollte, ließ sich selbst nicht immer leicht verändern.

SaaS veränderte das Bereitstellungsmodell, doch der Weg dorthin war schwierig

Der nächste große Wandel in der Branche führte in Richtung Cloud und SaaS.

Das Nutzenversprechen war klar. Unternehmen konnten ihre Verantwortung für die Infrastruktur reduzieren, den Betrieb vereinfachen, die Zugänglichkeit verbessern und neue Funktionen regelmäßiger einführen. Für viele Unternehmen stellte SaaS die Zukunft von Unternehmenssoftware dar.

Doch der Weg vom traditionellen On-Premises-PLM zu SaaS erwies sich als weitaus schwieriger als das eigentliche Ziel.

Viele etablierte PLM-Umgebungen waren über Jahre oder sogar Jahrzehnte hinweg entstanden. Sie umfassten umfangreiche Anpassungen, Integrationen, Datenstrukturen und Prozesse, die widerspiegelten, wie das jeweilige Unternehmen seine Produkte entwickelte und bereitstellte. Der Wechsel dieser Umgebungen zu SaaS war selten so einfach, wie die bestehende Installation lediglich in die Cloud zu verlagern.

In vielen Fällen mussten Anbieter ihre Lösungen für SaaS grundlegend neu konzipieren. Kunden standen dadurch vor etwas, das praktisch einer neuen Implementierung gleichkommen konnte: Daten mussten migriert, Integrationen neu aufgebaut, Prozesse neu gestaltet und Anwender geschult werden. Gleichzeitig musste entschieden werden, welche über Jahre entstandenen Anpassungen übernommen werden konnten oder sollten.

Die Vorteile von SaaS können überzeugend sein, doch die Kosten, die damit verbundenen Beeinträchtigungen und der organisatorische Aufwand auf dem Weg dorthin können erheblich sein.

Dadurch wurde ein wichtiges Problem des traditionellen PLM-Modells deutlich. Ein Unternehmen konnte den strategischen Wert eines Wechsels zu SaaS erkennen und gleichzeitig durch die Komplexität seiner bestehenden Umgebung eingeschränkt sein. Die Technologie hatte sich weiterentwickelt, doch der Kunde konnte diese Entwicklung nicht unbedingt nutzen, ohne praktisch von vorne beginnen zu müssen.

Software in die Cloud zu verlagern, löste nicht automatisch alle Einschränkungen des traditionellen PLM.

Ein starres System bleibt auch dann ein starres System, wenn es als SaaS bereitgestellt wird. Eine standardisierte Anwendung lässt sich möglicherweise einfacher betreiben, kann Unternehmen jedoch auch dazu zwingen, sich an Prozesse anzupassen, die nicht der Art und Weise entsprechen, wie sie differenzierte Produkte entwickeln oder ihre Kunden bedienen.

Damit wurde eine zentrale Frage wichtiger als der Ort, an dem die Software gehostet wurde:

Wie kann ein Unternehmen seine PLM-Umgebung modernisieren, ohne das Produktwissen, die Prozesse, Integrationen und den geschäftlichen Wert aufzugeben, die es über Jahre hinweg aufgebaut hat?

Diese Frage ist besonders wichtig, weil sich die Produktentwicklung ständig verändert. Unternehmen werden übernommen. Vorschriften entwickeln sich weiter. Neue Engineering-Disziplinen kommen hinzu. Produkte enthalten immer mehr Software und Elektronik. Lieferketten verändern sich. Neue Geschäftsmodelle entstehen.

Hersteller sollten nicht jedes Mal eine weitere kostspielige Neuimplementierung durchführen müssen, wenn die Unternehmenstechnologie in eine neue Ära eintritt.

Wir sind im Zeitalter der KI angekommen

Heute befindet sich die Branche in einem weiteren bedeutenden Wandel.

Künstliche Intelligenz hat das Potenzial, die Art und Weise zu verändern, wie Ingenieure Informationen finden, Alternativen bewerten, Risiken erkennen, repetitive Aufgaben erledigen und Entscheidungen über den gesamten Produktlebenszyklus hinweg treffen.

Doch KI kann aus unverbundenen und unzureichend kontrollierten Informationen keine vertrauenswürdigen Ergebnisse erzeugen.

Ein KI-System kann möglicherweise eine technisch plausible Antwort generieren. In einem industriellen Umfeld reicht Plausibilität jedoch nicht aus. Ingenieure müssen wissen, für welche Produktkonfiguration die Antwort gilt, ob die zugrunde liegenden Informationen aktuell sind, wer sie freigegeben hat, welche Anforderungen dafür gelten und wie sich eine vorgeschlagene Maßnahme auf Fertigung, Qualität, Compliance, Kosten oder Service auswirken könnte.

Industrielle KI braucht Kontext.

Dieser Kontext entsteht aus den Beziehungen zwischen Anforderungen, Teilen, Dokumenten, Software, Simulationen, Änderungen, Lieferanten, Fertigungsplänen, Qualitätsdaten und physischen Assets.

Mit anderen Worten: KI braucht den Digital Thread.

Deshalb sehe ich das KI-Zeitalter nicht einfach als eine weitere Gelegenheit, PLM um zusätzliche Funktionen zu erweitern. Es ist ein Test dafür, ob die PLM-Grundlage Informationen verknüpfen, Governance bewahren, sich verändernde Prozesse unterstützen und Produktwissen sowohl für Menschen als auch für intelligente Systeme zugänglich machen kann.

Warum Aras von Grund auf anders ist

Was mich an Aras überzeugt hat, war nicht einfach eine weitere Sammlung von PLM-Anwendungen. Es war eine andere Designphilosophie.

Aras wurde auf der Annahme aufgebaut, dass sich geschäftliche Anforderungen kontinuierlich verändern werden.

Die modellbasierte Architektur ermöglicht es Unternehmen, Datenmodelle, Workflows, Beziehungen und Anwendungen weiterzuentwickeln, ohne jede Änderung wie eine traditionelle Softwareanpassung behandeln zu müssen. Der offene Ansatz ermöglicht es Unternehmen, Informationen über die gesamte Unternehmensumgebung hinweg zu verknüpfen. Die Upgrade-Philosophie soll Kunden dabei helfen, das zu bewahren, was sie aufgebaut haben, und gleichzeitig weiterhin neue Plattformfunktionen einzuführen.

Dabei handelt es sich nicht nur um technische Unterschiede.

Sie beeinflussen, ob ein Unternehmen auf eine neue Vorschrift reagieren kann, ohne ein mehrjähriges Austauschprogramm starten zu müssen. Sie beeinflussen, ob ein übernommenes Unternehmen in einen gemeinsamen Digital Thread eingebunden werden kann. Sie beeinflussen, ob Engineering, Fertigung, Qualität, Lieferanten und Serviceteams auf der Grundlage eines vernetzten Produktkontexts zusammenarbeiten können.

Und zunehmend beeinflussen sie, ob KI in reale Produktlebenszyklusprozesse integriert werden kann, anstatt als isoliertes Experiment zu funktionieren.

Aras verlangt nicht, dass jede einzelne Produktinformation in ein einziges Repository kopiert wird. Die Plattform kann Informationen über bestehende Systeme hinweg verknüpfen und kontrollieren und gleichzeitig die Beziehungen und den Kontext bereitstellen, die erforderlich sind, um das Produkt über seinen gesamten Lebenszyklus hinweg zu verstehen.

Dieser Ansatz ist besonders wichtig in den fragmentierten Unternehmensumgebungen, die heute Realität sind.

Anders zu sein sollte differenzierten Mehrwert schaffen

Anders zu sein ist an sich noch kein Wert.

Der Wert entsteht durch das, was dieser Unterschied den Kunden ermöglicht.

Er ermöglicht ihnen, zu modernisieren, ohne immer wieder von vorne beginnen zu müssen.

Er ermöglicht ihnen, PLM auf neue Geschäftsprozesse auszuweiten, sobald neue Anforderungen entstehen.

Er ermöglicht ihnen, bestehende Systeme und Informationen miteinander zu verknüpfen, anstatt davon auszugehen, dass jede Anwendung ersetzt werden kann.

Er ermöglicht ihnen, jahrzehntelang aufgebautes Engineering-Wissen zu bewahren und gleichzeitig neue Technologien einzuführen.

Und er ermöglicht ihnen, sich auf KI vorzubereiten, indem sie den vernetzten und kontrollierten Produktkontext schaffen, den intelligente Systeme benötigen.

Das bedeutet „von Grund auf anders“ für mich. Es ist nicht einfach eine Aussage über Softwarearchitektur. Es ist eine Verpflichtung, Kunden dabei zu unterstützen, sich kontinuierlich weiterzuentwickeln.

KI wird nicht die letzte Ära sein

KI ist die prägende Technologiewelle unserer Zeit, aber sie wird nicht die letzte sein.

Neue Technologien, Betriebsmodelle, Vorschriften und Formen der Produktkomplexität werden weiterhin entstehen. In zehn Jahren werden Hersteller mit Anforderungen konfrontiert sein, die wir heute noch nicht vollständig vorhersehen können.

Die wichtigste Fähigkeit besteht daher möglicherweise nicht darin, jeden zukünftigen Bedarf vorherzusehen.

Vielleicht besteht sie vielmehr darin, sich anpassen zu können, wenn diese Zukunft eintritt.

PLM begann mit der Verwaltung von CAD-Daten. Es wurde auf die Verwaltung von Produktstrukturen und Unternehmensprozessen ausgeweitet. Es entwickelte sich weiter, um globale Zusammenarbeit, vernetzte Ökosysteme, Digital Threads und nun auch KI zu unterstützen.

Die nächste Ära wird neue Anforderungen mit sich bringen.

Unternehmen sollten nicht jedes Mal, wenn die Branche in eine neue Phase eintritt, das Produktwissen, die Prozesse und die digitalen Grundlagen aufgeben müssen, die sie über Jahrzehnte hinweg aufgebaut haben.

Sie brauchen eine Plattform, die darauf ausgelegt ist, sich gemeinsam mit ihnen weiterzuentwickeln.

Deshalb bin ich überzeugt, dass Aras von Grund auf anders ist.

Anders und darauf ausgelegt, sich an das anzupassen, was als Nächstes kommt.