Warum moderne Produktentwicklung trotzdem langsam bleibt

Agile und MBSE sind bekannt und in vielen Unternehmen auch in irgendeiner Form im Einsatz. Dazu kommen neue Werkzeuge, Maßnahmen zur Erhöhung des Reifegrades, und, und und. Diese Maßnahmen funktionieren auch, doch die paar Prozentpunkte Geschwindigkeitsgewinn sind homöopathisch, verglichen mit manchem Wettbewerber, die teilweise doppelt so schnell entwickeln und in kürzester Zeit enorm innovative Produkte auf den Markt bringen.

Zwei Experten konnte ich nun für ein gemeinsames Webinar am 18.06.2026 gewinnen, und zwar Martin Eigner und Joachim Pfeffer (Webinar-Anmeldung). Die Diskussion wird drei Perspektiven auf moderne Produktentwicklung verbinden: Product Velocity, Agile Systems Engineering und das erweiterte V-Modell. Hinter allen drei Ansätzen steht dieselbe Frage: Warum schaffen manche Organisationen schnelle Lern- und Integrationszyklen, während andere trotz hoher Methodenreife nur langsam vorankommen?

Geschwindigkeit entsteht nicht durch einzelne Methoden

Eine Methode verbessert in der Regel nur einen Teil des Systems. Wer den Rest des Systems dabei ignoriert, verlagert möglicherweise das Problem. Oft verpufft dadurch der Gewinn. Im schlechtesten Fall entsteht ein neuer Engpass, der den Gesamtfluss bremst.

Viele Organisationen haben genau das erlebt: Sprints in der Softwareentwicklung laufen reibungslos, während Hardware-Zulieferung und Systemintegration nach wie vor monatelang dauern. MBSE-Modelle entstehen schneller als je zuvor, aber niemand konsumiert sie verlässlich downstream. Die Methode funktioniert, doch das Gesamtsystem bleibt langsam.

„The goal is not to optimize each part separately, but to optimize the whole system.“

Eliyahu M. Goldratt

Goldratt hat das Problem für die Produktion formalisiert. In der Produktentwicklung gilt dasselbe: Der Durchsatz des Gesamtsystems wird durch das schwächste Glied bestimmt, nicht durch die Summe der Einzelleistungen.

Produktentwicklung ist heute ein vernetztes System

Mechatronische Systeme sind schon komplex. Aber cybertronische Systeme, also Systeme, die kommunizieren, Informationen verteilen und ihr Verhalten autonom anpassen, sind es nochmals in einer anderen Größenordnung. Eigner et al. beschreiben sie als Systeme mit einer großen Zahl stark vernetzter Elemente, dynamischen Systemgrenzen und wechselseitigen Abhängigkeiten zwischen den Elementen.

Bei solchen Entwicklungen funktioniert lokale Optimierung überhaupt nicht mehr. Wer eine Disziplin effizienter macht, ohne die Schnittstellen zu den anderen anzupassen, erzeugt Reibung an den Übergängen. Die Schnittstellen sind das eigentliche Problem, nicht die Kompetenz der einzelnen Teams.

Bestehende Ansätze wie VDI/VDE 2206 oder MBSE-Frameworks sind gut. Sie beschreiben, wie man ein komplexes System methodisch durchdenkt. Was sie nicht automatisch lösen: die organisatorischen Fragen rund um Entscheidungsfähigkeit, Verantwortung und Feedbackzyklen. Genau hier verlieren viele Unternehmen Geschwindigkeit, die sie mit Methoden nie wieder aufholen.

Die Perspektive der Product Velocity

Product Velocity beschreibt, wie schnell eine Organisation lernt und integriert. Nicht wie viele Features sie produziert. Die Velocity Loop macht diesen Unterschied sichtbar: Kurze Zyklen, frühe Integration, schnelles Feedback, daraus resultierende Entscheidungen, und wieder von vorn. Wer diesen Loop verlangsamt, zum Beispiel durch späte Integration oder lange Entscheidungswege, verliert Geschwindigkeit strukturell, nicht durch Ineffizienz in einzelnen Teams.

Vier Prinzipien treiben Product Velocity: Value Thinking, Shift Left, Architect for Flow und Accelerate.

Die Perspektive des erweiterten V-Modells (Martin Eigner)

Die bereits erwähnte VDI 2206 hat das V-Modell als Makrozyklus für die Entwicklung mechatronischer Systeme etabliert: links der Entwurf, rechts die Verifikation und Validation, in der Mitte die Systemintegration. Das ist solide, aber es reicht für komplexe Produkte nicht mehr aus.

Das MVPE-Modell (Bild) erweitert genau diesen linken Ast des V. Es führt drei überlagerte Modellierungsebenen ein: Auf der Spezifikationsebene entstehen qualitative Modelle mit Anforderungen, Funktionen und logischer Systemstruktur, typischerweise in SysML. Auf der zweiten Ebene kommen Simulationsmodelle hinzu, etwa in Matlab oder Modelica. Auf der dritten Ebene folgt die disziplinspezifische Ausdetaillierung in CAx-Werkzeugen. Durchgängig differenziert das Modell vier Artefakttypen: Requirements (R), Functions (F), Logical Architecture (L) und Physical Parts (P).

The Evolution of the V-Model: From VDI 2206 to a System Engineering Based Approach for Developing Cybertronic Systems

Martin Eigner, Thomas Dickopf & Hristo Apostolov

PDF Download (Springer)

Der entscheidende Schritt darüber hinaus ist das mecPro²-Framework, welches ebenfalls in dem Paper beschrieben wird.. Es beschreibt den Systementwurf auf vier Konkretisierungsebenen: Kontextebene, Funktionsebene, Prinziplösungsebene und Technische Lösungsebene. Auf der Kontextebene wird das System zunächst als Black Box beschrieben, die Anforderungen aus natürlicher Sprache in ein Systemmodell überführt. Die Funktionsebene identifiziert lösungsneutrale Systemfunktionen inklusive aller Material-, Energie- und Signalflüsse. Auf der Prinziplösungsebene werden Lösungsalternativen systematisch identifiziert, bewertet und ausgewählt. Die technische Lösungsebene erreicht schließlich die maximale Konkretisierung.

In der Praxis folgt der Entwurf damit einer klaren Logik vom Groben zum Feinen. Alternativen werden methodisch verglichen. Und Traceability von Anforderungen bis zur physischen Lösung, ist im Prozess verankert.

Die Perspektive von Agile Systems Engineering und Value Flow (Joachim Pfeffer)

Joachim Pfeffer arbeitet seit über 20 Jahren als Berater, Trainer und Coach an der Schnittstelle von Agilität und physischer Produktentwicklung. In seinen Büchern zeigt er, wie Lean Development und agile Ansätze auf Steuergeräte, Brennstoffzellen, Halbleiter und Maschinen übertragbar sind. Der Fokus liegt auf Produkt-Inkrementen, agilen Systemarchitekturen und der Frage, wie sich Wertflüsse in der Produktentwicklung sichtbar machen und optimieren lassen.

Sein zentrales Argument: Nicht Technologie ist die eigentliche Hürde, sondern Organisation. Wer Value Stream Mapping in Workshops einsetzt, hört von Entscheidern regelmäßig: „So können wir nicht arbeiten.“ Teams optimieren sich intern, aber niemand trägt Verantwortung für den Wertfluss durch die Abteilungen hindurch. Genau da bricht Geschwindigkeit zusammen.

Gemeinsame Muster hinter schneller Produktentwicklung

Hinter allen drei Perspektiven liegen dieselben Mechanismen. Saab und BYD, zwei der im Webinar betrachteten Beispiele, machen sie greifbar.

Erstens: kurze Integrationszyklen. Wer früh und häufig integriert, findet Probleme dort, wo sie entstehen, nicht Monate später, wenn der Aufwand für die Korrektur explodiert ist.

Zweitens: Entscheidungsfähigkeit nah am Wissen. Lange Eskalationsketten kosten Zeit. Organisationen, die schnell entwickeln, haben Entscheidungsrechte dort verankert, wo das fachliche Urteil liegt.

Drittens: Systemdenken statt Disziplindenken. Mechanik, Software, Elektronik und Services sind in modernen Produkten so verwoben, dass jede rein disziplinäre Optimierung Reibung an den Grenzen produziert. Methoden wie das RFLP-Modell oder das mecPro²-Framework helfen, diese Grenzen sichtbar zu machen und modellbasiert zu überbrücken.

Viertens: Plattformen statt Einzellösungen. Geschwindigkeit skaliert nicht durch Wiederholung, sondern durch Wiederverwendung. Wer Architekturentscheidungen auf Plattformebene trifft, reduziert den Aufwand für jede nachfolgende Variante.

Drei Perspektiven in einer gemeinsamen Diskussion

Martin Eigner bringt die methodische Tiefe des erweiterten V-Modells: Wie modelliert man cybertronische Systeme so, dass Komplexität handhabbar bleibt? Joachim Pfeffer bringt die organisatorische Perspektive: Wo verliert der Wertfluss seine Energie, und was lässt sich ohne Technologieinvestition sofort verändern? Und ich werde die Verbindung zur Product Velocity herstellen: Was macht einen Feedback- und Integrationszyklus tatsächlich schnell?

Das Webinar kombiniert kurze Impulse mit einer moderierten Diskussion und Fragen aus dem Teilnehmenden. Wer konkrete Fälle mitbringt, ist herzlich willkommen.

Zur Anmeldung

Fazit

Methoden allein beschleunigen keine Produktentwicklung. Was zählt, ist, ob die Lernzyklen des Gesamtsystems kürzer werden. Das erfordert Systemdenken auf Organisationsebene, Traceability im Modell, Entscheidungsfähigkeit dort, wo das Wissen sitzt, und den Mut, Wertflüsse sichtbar zu machen, auch wenn das unbequeme Wahrheiten zeigt. Wer das nicht angeht, wird mit homöopathischen Prozentpunkten nicht aufholen.