PLM-Systeme sollen der Backbone für die Datenverteilung im Unternehmen sein. Was in einem kleinen oder mittelständischen Unternehmen mit sauber strukturierter IT-Landschaft noch umsetzbar ist, wird in Großunternehmen, beispielsweise aus dem Automotive-Bereich zum Alptraum. Mehrere hundert Tools müssen angebunden werden und miteinander Daten austauschen können. Prof. Martin Eigner, Leiter des Lehrstuhls für Virtuelle Produktentwicklung (VPE) der TU Kaiserslautern, erläutert im Interview Alternativen zu diesem Ansatz. Anlass für das Interview war die Meldung, dass Autohersteller GM das PLM-System von Aras als Plattform für alle Marken weltweit einsetzen wird.
Herr Prof. Eigner, wie ist denn der Status in der Automobilindustrie?
Die Automobilindustrie steht vor großen Herausforderungen, die Zukunft mit Car Sharing, E-Autos und Autonomem Fahren wird die Branche stark verändern. Die Unternehmen reagieren darauf unter anderem mit der Optimierung und Straffung ihrer Prozesse. Dabei spielen PLM-Systeme, die den Lebenszyklus des Produkts von der Konzeption bis zum Service begleiten, eine Schlüsselrolle.
Wo liegt dabei die Herausforderung, etwa im Vergleich mit kleineren Unternehmen?
Bei einem deutschen Automobilbauer sind typischerweise zwischen 300 und 500 fragmentierte Systeme im Einsatz, vom Requirements Management über CAD bis hin zu Systemen für die Produktionssteuerung und den Service. Der Versuch, diese Systeme durch PLM zu verbinden, ist gescheitert – es existiert in Wirklichkeit kein Backbone, der alle Daten vereint.
Die Idee der PLM-Anbieter ist, dass die Autorensysteme, also die Anwendungen, in denen Daten erzeugt werden, beispielsweise CAD – ihre Daten nach oben an den Backbone liefern, dort mit anderen Daten verknüpft und wieder abrufbar sind. Stand heute würden die bestehenden Systeme diesen Datenfluss gar nicht verkraften, der Backbone würde platzen.
Und wie kann die Alternative aussehen?
Die Gartner Group hat das Konzept „bimodale IT-Systeme“ vorgestellt, sozusagen eine IT der zwei Geschwindigkeiten. Daten werden hier nicht über eine Schnittstelle in eine Datenbank überführt, sondern über leichtgewichtige, moderne APIs wie REST verlinkt. Die Systeme greifen über ein Repository, in dem alle Daten aller Systeme referenziert sind, auf die Daten anderer Systeme zu. So bleiben die Daten in ihrem jeweiligen Kontext., können aber auch von außen genutzt werden. So ist es nicht mehr notwendig, 300 bis 500 Schnittstellen und die Semantik zu entwickeln, die es Systemen ermöglicht, die Daten anderer Systeme zu verstehen. Da das Repository objektorientiert ist, erben die daran angeschlossenen Systeme nicht nur die Datenobjekte, sondern auch die Funktionen, die hier implementiert sind. Die Gartner Group hat neben Aras das CAD-System Onshape und das PLM-System Propel als Beispiele bimodaler Systeme identifiziert.
In einem Beitrag für Aras habe ich die Merkmale bimodaler Systeme zusammengefasst:
- Von Dokument-basiert zu Modell-basiert.
- Von hierarchischen- (herkömmlichen Stücklisten der Hardware) bis hin zu Netzwerk- (MBSE) und linearen Strukturen (Software).
- Aufteilung der Anwendungsdaten und Metadaten auf Basis eines objektorientierten Repository.
- Von monolithischen zu föderierten und leichtgewichtigen Systemen, die auf referenzierte bzw. verknüpften Daten. Die dazu notwendigen IT-Technologien basieren auf dem objektorientierten Repository und/oder REST.
- Bereitstellung auf unterschiedlichen Cloud-Level (IaaS, PaaS und SaaS[2])
- Unterstützung der typischen Engineering Prozesse wie z.B. Engineering Change Management (ECM) und Configuration Management (CM) für Mechanik, Elektrik / Elektronik und Software.
- Agile Einführung und betriebliche Anpassung durch überwiegend interaktive Konfiguration anstatt durch prozedurales Customizing.
- Automatischer Übernahme aller betrieblicher Anpassungen (Konfiguration und Customizing!) bei Upgrade des Basissystems.
- Neue flexible Geschäftsmodelle auf Basis von Subscriptions anstatt Lizenzen.
Die letzten drei Punkte deuten darauf hin, dass die Implementierung einfacher und preiswerter zu sein scheint als bei den typischen PLM-Systemen. Bisher war je die Einführung eines PLM-System mit hohen Investitionen in Customizing verbunden.
Das ist bei bimodalen Systemen anders, da hochkomplexe Vernetzungen mit anderen Systemen und schwierige Datenmigrationen eben nicht notwendig sind. Bei normalen PLM-Systemen rechnet man mit einem Customizingaufwand, dessen Kosten in einer Größenordnung zwischen der Höhe der Lizenzkosten bis zu den dreifachen Kosten wie für die Lizenzen liegen. Bei Aras liegt der Customizingaufwand weit niedriger, wir haben bei typischen Customizing-Usecases an meinem Lehrstuhl bei modalen PLM-Systemen einen bis zu dreifach höheren Aufwand gemessen.
Vor allem aber muss normalerweise mit jedem Versionswechsel das Customizing angepasst beziehungsweise neu erstellt werden, was wieder hohe Kosten nach sich zieht. Aras garantiert dagegen die Aufwärtskompatibilität sämtlicher Anpassungen, so dass ein Versionswechsel keine weiteren Kosten nach sich zieht.
Und das Thema Subscription? Steigert das nicht die Kosten über die Jahre?
Wenn man richtig rechnet, nein. Die Subscription kostet in etwa 20 Prozent des Preises, den der Kauf einer Lizenz kosten würde. In fünf Jahren zahlt man also den kompletten Preis einer Lizenz, vermeidet aber zum einen das hohe Anfangsinvestment in den Lizenzkauf. Zum anderen erhält man jederzeit die aktuellste Version, ohne Upgradegebühren zu zahlen, und vermeidet dank der Kompatibilitätsgarantie von Aras die Customizingkosten, die ansonsten anfallen. Am Ende rechnet sich das.
Herr Eigner, vielen Dank für das Gespräch.