Von Mercedes zu NIO: Was moderne Engineering-Toolchains ausmacht

Ich freue mich, Dr. Yousef Hooshmand für ein Interview auf Systems Engineering Trends gewonnen zu haben. Yousef kennt die Produktentwicklung und ihre IT-Landschaften sowohl aus der deutschen als auch aus der chinesischen Automobilindustrie aus eigener Praxis: Vor seinem Wechsel zu NIO arbeitete er mehrere Jahre bei Mercedes-Benz an der Modernisierung der PLM-Landschaft. Heute verantwortet er bei NIO als PLM & R&D Toolchain Lead Architect die Gestaltung und Weiterentwicklung einer ganzheitlichen PLM- und Engineering-Toolchain.

Über Dr. Yousef Hooshmand

Dr. Yousef Hooshmand (LinkedIn) verfügt über mehr als 16 Jahre Erfahrung in den Bereichen PLM, Systems Engineering, MBSE und semantische Integration Engineering-Daten. Nach seiner Promotion und seiner Postdoc-Tätigkeit im Bereich Produktentwicklung an der Universität Duisburg-Essen wechselte er zu Mercedes-Benz. Dort war er als Digital Transformation Consultant sowie als PLM-Architekt und Technical Lead tätig. Seit 2022 arbeitet er bei NIO als PLM & R&D Toolchain Lead Architect.

Ein Schwerpunkt seiner Arbeit ist der Übergang von applikationszentrierten zu datenzentrierten Engineering-Landschaften. Dabei hat er sich insbesondere auf die Vorantreibung einer durchgängigen geschäftlichen und digitalen Transformation in komplexen Entwicklungs- und Fertigungsumgebungen verschiedener Branchen, darunter die Automobil- und die Energiebranche, konzentriert. Seine Schwerpunkt liegt in der Konzeption und Entwicklung von föderierten Engineering-Landschaften, die fragmentierte Datenquellen miteinander verbinden und eine nahtlose interdisziplinäre Zusammenarbeit ermöglichen. Er hat die Ergebnisse seiner Arbeit in zahlreichen Veröffentlichungen und Vorträgen vorgestellt.Interview mit Dr. Yousef Hooshmand

Das Interview wurde schriftlich am 9. August 2026 von Michael Jastram geführt. Dadurch konnte Yousef seine Positionen zu PLM, MBSE, Data-Centric Systems Engineering und moderner Produktentwicklung ausführlich darlegen.

Du hast sowohl die Transformation eines etablierten Premium-OEMs erlebt und arbeitest jetzt für einen chinesischen OEM. Welche Annahmen über moderne Produktentwicklung haben sich für Dich als falsch herausgestellt?

Vor allem zwei Annahmen haben sich für mich als falsch herausgestellt.

Erstens habe ich den Einfluss von Daten und Datenintegrität unterschätzt und gleichzeitig die Bedeutung der Applikationsfunktionalität überschätzt. Viele Organisationen investieren enorme Energie in die Frage, welches Werkzeug die meisten Funktionen bietet. Dabei wird übersehen, dass Geschwindigkeit und Qualität der Produktentwicklung wesentlich davon abhängen, ob die benötigten Daten vollständig, konsistent, verständlich und über Systemgrenzen hinweg verfügbar sind.

Das application-centric mindset führt häufig dazu, dass Daten lediglich als Nebenprodukt einer Softwareanwendung behandelt werden. Geschäftslogik und Datensemantik bleiben in proprietären Datenmodellen oder im Anwendungscode verborgen.

Zweitens habe ich den Einfluss des Mindsets auf Produktentwicklung unterschätzt. Ein gutes Beispiel ist der Umgang mit Meilensteinen. Man kann einen Meilenstein als verbindliches Liefer- und Kontrollversprechen betrachten, das teilweise unabhängig von neuen Erkenntnissen möglichst exakt eingehalten werden muss. Oder man versteht ihn als Zwischenschritt, an dem wir unseren tatsächlichen Fortschritt messen, lernen und den Kurs anpassen, um den Produktentwicklungszielen schrittweise näher zu kommen. Formal kann der Prozess identisch aussehen, jedoch führt das zugrunde liegende Mindset zu einem völlig anderen Verhalten.

Im ersten Fall steht die Einhaltung des Plans im Vordergrund, im zweiten die Erreichung des bestmöglichen Ergebnisses. Meilensteine sind nur dann wirksam, wenn die Organisation Unsicherheit akzeptiert, Lernen ermöglicht und Anpassungen nicht als Scheitern, sondern als wesentlichen Bestandteil der Produktentwicklung versteht.

Moderne Produktentwicklung wird nicht primär durch modernere Applikationen ermöglicht, sondern durch das richtige Mindset und einen konsequent datenzentrierten Ansatz über Domänen und Disziplinen hinweg.

Viele Unternehmen investieren in neue PLM-, ALM- oder MBSE-Werkzeuge und sind trotzdem nicht schneller. Was sind aus Deiner Sicht die häufigsten Ursachen dafür?

Eine der häufigsten Ursachen ist das application-centric mindset, das unter anderem Dave McComb in seinen Publikationen „Software Wasteland“ und „The Data-Centric Revolution“ sehr treffend kritisiert. Unternehmen erwarten von einem neuen Werkzeug, dass es strukturelle Probleme löst. Dabei werden veraltete Prozesse und inkonsistente Daten lediglich in ein neues System übertragen. Das Ergebnis ist häufig eine technisch modern aussehende Plattform, die jedoch eher dazu beiträgt, die eigentlichen Ursachen langsamer Produktentwicklung zu verdecken, statt sie zu beseitigen.

Das grundlegende Missverständnis beginnt oft bereits beim Begriff „digitale Transformation“. Was Unternehmen tatsächlich benötigen, ist eine Business Transformation. Technologie kann diese unterstützen, aber nicht ersetzen. Eine extern geführte Transformation kann im besten Fall eine erfolgreiche IT-Migration liefern. Eine nachhaltige Veränderung der Arbeitsweise muss dagegen aus dem Unternehmen selbst kommen.

Dafür habe ich vor einigen Jahren das Modell der „5 + 1 Steps for Resilient Business Transformation“ entwickelt und 2023 auf der Konferenz PLM Road Map & PDT Europe in Paris vorgestellt:

• Schritt 0 als übergeordnete Voraussetzung: langfristiges Commitment der Führungskräfte,
• Schritt 1: Definition der Unternehmenswerte und -ziele,
• Schritt 2: Erstellung einer Business-Capability-Map,
• Schritt 3: Erfassung der bestehenden Engineering-Landschaft,
• Schritt 4: Ableitung konkreter, idealerweise technologieunabhängiger, Maßnahmen,
• Schritt 5: Erst dann Auswahl der Tools und Technologien.

Viele Programme beginnen direkt bei Schritt fünf, bei dem ein Werkzeug ausgewählt wird, bevor klar ist, welche Geschäftsprobleme gelöst werden sollen. Eine erfolgreiche Transformation benötigt dagegen einen ganzheitlichen Ansatz sowie ein konsequentes Top-down- und Bottom-up-Engagement.

Du vertrittst seit Jahren einen datenzentrierten Ansatz. Was bedeutet Data-Centric Engineering konkret im Entwicklungsalltag und warum ist dieser Ansatz Deiner Meinung nach wichtig?

Data-Centric Engineering beziehungsweise Data-Centric Systems Engineering (DCSE) ist ein Ansatz, bei dem Daten und ihre Zusammenhänge als primäres Asset in den Mittelpunkt des Systems Engineering gestellt werden. Dadurch wird die Rückverfolgbarkeit über Disziplinen, Lebenszyklusphasen und Software-Tools hinweg gewährleistet.

Auf Basis eines einheitlichen semantischen Datenmodells, ermöglicht DCSE inhärente semantische Interoperabilität. Isolierte Artefakte werden zu einem integrierten Graphen verbunden, der fundierte, datenbasierte Entscheidungen unterstützt. Dabei entsteht ein Semantisches Netz, das heterogene Daten aus strukturierten Quellen wie Datenbanken, aus unstrukturierten Quellen wie Dokumenten sowie aus Domänenmodellen wie CAD, Modelica, SysML, oder ECAD integriert und zu einem zusammenhängenden Ganzen verknüpft.

Konkret bedeutet dies im Entwicklungsalltag:

• Daten sind das zentrale, langlebige Asset. Softwareanwendungen dienen dazu, Daten zu lesen, zu erzeugen, und zu verändern, können aber ausgetauscht werden.
• Die Architektur ist application-agnostic. Fachbereiche können weiterhin spezialisierte Best-of-Breed-Werkzeuge verwenden, ohne dass das Engineering-Wissen dauerhaft an ein einzelnes Softwareanwendung gebunden ist.
• Die Semantik ist explizit und maschineninterpretierbar. Anwendungen können Daten daher nicht nur auslesen, sondern auch deren Bedeutung, Kontext und Zusammenhänge erfassen und verarbeiten.
• Föderierte IT-Landschaften werden unterstützt. Daten können über dezentrale Domänen und Teams hinweg zur Verfügung stehen, ohne ein zentrales monolithisches System zu erzwingen.
• Governance bleibt föderiert, Konsistenz wird jedoch gemeinsam abgesichert. Nur domänenübergreifende Aspekte werden global geregelt.

DCSE erweitert damit MBSE und schafft kontextualisierte Daten für neue Anwendungen und deterministische KI-Lösungen. Mehr über DCSE findet sich in meinem Beitrag „Data-Centric Systems Engineering (DCSE) based on Semantic Digital Thread (SeDT)“.

Der Begriff „Digital Thread“ wird heute fast inflationär verwendet. Was unterscheidet einen Semantic Digital Thread von klassischen Integrationsansätzen zwischen Werkzeugen?

Klassische Integrationen verbinden Informationen überwiegend über technische Identifikatoren, APIs, Dateien oder Punkt-zu-Punkt-Mappings. Sie können feststellen, dass zwei Datensätze miteinander verbunden sind, erklären aber nicht zuverlässig, was diese Verbindung bedeutet. Der Semantic Digital Thread etabliert dagegen explizite, maschineninterpretierbare Beziehungen zwischen Systemartefakten und erzeugt dadurch einen kontextsensitiven Graphen.

Der Semantic Digital Thread (SeDT) ist das Rückgrat von DCSE. Seine Grundlage ist ein einheitliches, maschineninterpretierbares Semantic Data Model, kurz SeDM. Das SeDM definiert als Blueprint die Entitäten, Beziehungen, und Constraints. Der SeDT ist dagegen der instanziierte Knowledge Graph, der diese Definitionen mit realen Daten aus den Unternehmenssystemen materialisiert. Dieser Knowledge Graph wird kontinuierlich aktualisiert und kann dadurch den Zustand sowie die sich entwickelnde Konfiguration eines Systems nahezu in Echtzeit abbilden.

Der SeDT endet zudem nicht an Unternehmensgrenzen. Er muss Beziehungen und Provenienz über Lebenszyklusphasen und Wertschöpfungspartner hinweg abbilden können, also von den Rohstoffen und dem Bergbau über Zulieferer, Entwicklung und Produktion bis hin zum Endprodukt und dessen Verwendung.

Du hast sowohl monolithische als auch stärker föderierte Toollandschaften erlebt. Welche Architekturprinzipien haben sich in der Praxis bewährt und welche eher nicht?

Für mich sind weniger einzelne Architekturprinzipien entscheidend als klare Entscheidungsleitlinien:

• User-centric: Design für eine höhere Nutzerzufriedenheit,
• Data-centric: Daten konsequent als First-Class Citizen behandeln,
• Build for Change: Systeme von Beginn an für Veränderung und nicht für einen vermeintlich perfekten Endzustand gestalten.

Hinzu kommt ein fundamentales Prinzip: Die Vorstellung einer universellen Single Source of Truth (SSOT) ist in Engineering-Organisationen meist eine Illusion. Daten entstehen und entwickeln sich in unterschiedlichen Domänen und Kontexten. Das SSOT-Konzept kann sogar irreführend sein und wird teilweise beinahe wie ein Scharlatanversprechen verwendet. Wer daran glaubt, sucht unbewusst vor allem nach monolithischen Applikationen, die sämtliche Probleme lösen sollen.

Wer dagegen dem Prinzip Nearest Source of Truth based on a Single Source of Change folgt, bleibt offen für alternative Lösungen und versucht die gesamte Engineering-Landschaft zu berücksichtigen. Mehr dazu findet sich in meinem Beitrag „From a Monolithic PLM Landscape to a Federated Domain and Data Mesh“.

Das bedeutet, ein bestimmtes Objekt hat eine klar definierte, verantwortliche Quelle, an der autoritative Änderungen erfolgen. Seine Informationen können jedoch in mehreren Systemen verfügbar und um den jeweiligen Kontext ergänzt werden. So bleiben Änderungsverantwortung und Datenintegrität eindeutig, ohne sämtliche Informationen in ein einziges System zwingen zu müssen.

Architekturansätze wie Domain-Driven Design, Data Mesh, und Semantic-Web-Technologien passen besonders gut zu diesen Prinzipien. DDD hilft bei fachlichen Grenzen und Verantwortlichkeiten, Data Mesh bei föderierter Datenverantwortung und Semantic-Web-Technologien bei der übergreifenden semantischen Konsistenz.

Grundsätzlich kann eine Organisation jedoch andere Architekturansätze wählen. Entscheidend ist, dass die drei Entscheidungsleitlinien und das Prinzip Nearest Source of Truth based on a Single Source of Change konsequent eingehalten werden.

Wenn Du heute die Toolchain eines großen Entwicklungsunternehmens neu gestalten könntest: Welche drei Entscheidungen würdest Du möglichst früh treffen?

Zunächst würde ich den Umbau der Toolchain ausdrücklich als Teil einer Business Transformation behandeln und nicht als isoliertes IT- oder Digitalisierungsprojekt. Deshalb sind alle zuvor genannten „5 + 1 Steps“ relevant.

Aus technischer Sicht würde ich die folgenden drei Entscheidungen als kritisch einstufen und möglichst früh treffen:

Erstens: Die Architektur an Business Capabilities und fachlichen Domänen ausrichten.
Bevor Produkte ausgewählt werden, müssen Verantwortlichkeiten, Domänengrenzen, und Datenprodukte geklärt sein. Die IT-Architektur sollte nicht aus den Grenzen der heute eingesetzten Werkzeuge abgeleitet werden.

Zweitens: Eine gemeinsame semantische Grundlage schaffen.
Dazu gehören eine Enterprise Upper Ontology, ein Integration Model, ein Terminology Model, und modulare Domain Models. Diese Grundlage muss nicht sofort vollständig sein, sollte aber iterativ mit priorisierten Anwendungsfällen wachsen.

Drittens: Anpassungsfähigkeit zum expliziten Architekturziel machen.
Die Toolchain sollte modular, Softwareanwendung-agnostic und semantisch integrierbar sein. Softwareanwendungen müssen kurzfristig erweiterbar oder sogar austauschbar bleiben, während Daten und Semantik langfristig erhalten bleiben können.

MBSE begleitet die Branche inzwischen seit vielen Jahren. Wo siehst Du heute die größten Erfolge, und wo wurden die Erwartungen aus Deiner Sicht nicht erfüllt?

MBSE ist mit großen und hervorragenden Visionen angetreten. Aus meiner Sicht bestand einer seiner wichtigsten Beiträge darin, diese Visionen überhaupt in der Industrie bekannt zu machen: komplexe Systeme ganzheitlich zu betrachten, Beziehungen explizit zu modellieren und Anforderungen, Funktionen, Systemelemente sowie deren Verifikationen systematisch miteinander zu verbinden.

In bestimmten Bereichen, wie beispielsweise in frühen Entwicklungsphasen, wurden gute Ergebnisse erzielt. Das große Gesamtversprechen einer durchgängig modellbasierten Produktentwicklung wurde jedoch aus technischen wie auch nicht technischen Gründen bisher nur teilweise eingelöst.

Eine der Hauptursachen ist, dass MBSE häufig model-centric und application- centric geblieben ist. Das Modell wird als zentrales, langlebiges Asset betrachtet, seine Semantik bleibt jedoch häufig innerhalb einer Modellierungssprache und eines bestimmten Werkzeugökosystems. In der Praxis liegen wichtige Engineering-Informationen weiterhin verteilt in CAD-, ALM-, Simulations-, Fertigungs- und Qualitätssystemen sowie in Dokumenten. Genau deshalb beschäftige ich mich seit vielen Jahren intensiv mit Data-Centric Systems Engineering.

DCSE ersetzt MBSE nicht, sondern erweitert dessen Vision. Daten und ihre Verbindungen werden zum zentralen, langlebigen Asset; die Architektur ist application-agnostic, semantisch interoperabel und für föderierte IT-Landschaften ausgelegt. Wenn der Semantic Digital Thread die Infrastruktur ist, dann ist DCSE die Methodik, die darauf aufbaut. MBSE wird darin zu einem wichtigen Baustein sowie zu einem Produzenten und Konsumenten semantisch vernetzter Engineering-Daten.

SysML v2 ist in der Praxis angekommen. Welche Auswirkungen erwartest Du auf MBSE, Toolintegration und die tägliche Arbeit von Entwicklungsorganisationen?

SysML v2 ist aus meiner Sicht ein wichtiger Fortschritt. Die präzise Semantik, die bessere Maschinenlesbarkeit und die standardisierten APIs können automatisierte Analysen, Integration, und Wiederverwendung deutlich verbessern. Systemmodelle lassen sich dadurch besser programmatisch abfragen, validieren und transformieren.

Trotzdem ist SysML v2 kein Allheilmittel. Eine präzisere Sprache und eine bessere API lösen nicht automatisch organisatorische Probleme, Datensilos oder die semantische Heterogenität einer gesamten Engineering-Landschaft. Auch werden andere Domänen weiterhin eigene Modelle, und Softwarewerkzeuge besitzen.

SysML v2 sollte deshalb nicht zum Fundament eines neuen zentralen Monolithen gemacht werden. Ich sehe es vielmehr als einen sehr guten Baustein von DCSE. Über einen Semantic Digital Thread können SysML-v2-Modelle mit CAD-, Simulations-, Test-, Produktions- und Felddaten semantisch verbunden werden. So trägt SysML v2 zu einem größeren, application-agnostischen und föderierten Engineering-Ökosystem bei.

Wenn Du einem CTO oder Entwicklungsleiter nur einen einzigen Rat geben dürftest, um die Zusammenarbeit zwischen Menschen, Daten und Werkzeugen nachhaltig zu verbessern: Welcher wäre das?

Behandeln Sie die Verbesserung der Zusammenarbeit nicht als Toolprojekt, sondern als Business Transformation und folgen Sie dabei konsequent den „5 + 1 Steps for Resilient Business Transformation“.

Beginnen Sie mit den Business Values und Objectives. Leiten Sie daraus die benötigten Business Capabilities ab und schaffen Sie Transparenz über die bestehende Engineering-Landschaft. Definieren Sie anschließend konkrete Maßnahmen und entscheiden Sie erst danach über Tools und Technologien. Sorgen Sie gleichzeitig dafür, dass sowohl die Unternehmensleitung als auch die Mitarbeiter sich langfristig engagieren.

Der wichtigste Perspektivwechsel besteht daher darin, nicht zu fragen, welches neue Tool eingeführt werden sollte, sondern vielmehr, wie wir das Geschäft so umgestalten müssen, um die Unternehmensziele zu erreichen. Nur dann kann sich eine Initiative zu einer soliden und nachhaltigen Geschäftstransformation entwickeln, die sich sowohl auf die Organisation als auch auf die IT-Toolchain positiv auswirkt.