Warum die moderne Produktentwicklung immer noch so langsam vorankommt

Warum entwickeln manche Unternehmen komplexe Produkte innerhalb weniger Jahre, während andere trotz Agile, MBSE, DevOps und moderner Toolchains kaum an Fahrt gewinnen? In dieser Webinar-Aufzeichnung diskutieren Martin Eigner, Joachim Pfeffer und Michael Jastram, was die moderne Produktentwicklung tatsächlich beschleunigt. Die Aufzeichnung ist auf Deutsch.

Die Aufnahme ist auf Deutsch. Dieser Artikel fasst die wichtigsten Punkte auf Englisch zusammen.

Der Ausgangspunkt war einfach. Viele Unternehmen haben in Agile, MBSE, DevOps, PLM, ALM, Simulation und moderne Toolchains investiert. Die Mitarbeiter sind kompetent. Die Werkzeuge stehen zur Verfügung. Die Methoden sind bekannt. Und dennoch benötigen viele Unternehmen immer noch Jahre, um komplexe Produkte auf den Markt zu bringen.

Der Kontrast lässt sich kaum noch übersehen. BYD spricht davon, Autos in 18 Monaten zu entwickeln. Volkswagen hat dazu beigetragen, die Entwicklungszeit von 48 Monaten auf 40 Monate zu verkürzen. Der Unterschied ist zu groß, um ihn mit “besseren Werkzeugen” oder “agileren Teams” zu erklären. Der Mechanismus liegt tiefer.

Martin Eigner über Systeme, Werkzeuge und organisatorische Silos

Martin Eigner Er begann mit einem Überblick über Systemtechnik und PLM. Er argumentierte, dass das klassische V-Modell nach wie vor seinen Wert habe, allerdings nur, wenn es für die moderne interdisziplinäre Entwicklung erweitert werde.

Die mechanische, elektrische und Software-Entwicklung verläuft nicht im gleichen Tempo. Dabei kommen unterschiedliche Methoden, Werkzeuge und Arbeitskulturen zum Einsatz. PLM-, ALM- und ERP-Systeme haben sich zu eigenständigen Welten entwickelt. Dies führt zu Übergaben, Datenduplikaten und langsamen Veränderungsprozessen.

Martin wies zudem auf eine tiefer liegende Ursache hin. Die Ingenieurausbildung ist nach wie vor nach Fachrichtungen gegliedert. Maschinenbauingenieure, Elektroingenieure und Softwareentwickler lernen unterschiedliche Denkmodelle. Komplexe Produkte zwingen diese Welten jedoch dazu, sich zu vereinen. Unternehmen stellen dann fest, dass ihre Methoden und Werkzeuge sie nach wie vor voneinander trennen.

KI kann insbesondere beim Veränderungsmanagement, bei der Wirkungsanalyse, bei der FMEA, bei Qualitätsprozessen und bei Simulationen hilfreich sein. Aber KI ersetzt nicht das ingenieurwissenschaftliche Denken. Sie benötigt Daten, Kontext und Architektur. Ein Chatbot, der einfach auf eine alte, monolithische Toolchain aufgesetzt wird, sorgt nicht für eine schnellere Entwicklungsorganisation.

Joachim Pfeffer über agile Hardware und Flow

Joachim Pfeffer stellte eine gängige Sichtweise in Frage. Die Frage ist nicht, ob man das V-Modell oder Scrum verwenden soll. Beide Ansätze dienen der Lösung unterschiedlicher Probleme.

Das V-Modell ist ein Konsistenzmodell. Es hilft dabei, die Komplexität von Produkten zu bewältigen. Agile Methoden befassen sich mit der organisatorischen Komplexität. Bei der Entwicklung komplexer Hardware und Systeme sind beide Ansätze erforderlich.

Joachim konzentrierte sich darauf, wo Zeit verloren geht. Die Menschen sind beschäftigt, aber die Produkte warten. Die Arbeit wartet auf Manager, Experten, Testumgebungen, Überprüfungen und Genehmigungen. Eine hohe Auslastung führt zu Warteschlangen. Große Chargen verzögern den Lernprozess. Stage-Gate-Prozesse schieben zu viel Arbeit auf einmal durch das System.

Die praktische Antwort lautet Schlanker Durchfluss. Den Arbeitsbestand reduzieren. In kleineren Schritten vorgehen. Früher integrieren. Früher testen. Automatisieren, wo Automatisierung Wartezeiten vermeidet. Die Entwicklung des Gripen durch Saab wurde als Beispiel für eine schrittweise Flugzeugentwicklung mit regelmäßigen flugfähigen Meilensteinen diskutiert.

Das Schwierige daran ist die Umsetzung. Joachim beschrieb Fälle, in denen Führungsteams Maßnahmen identifiziert hatten, mit denen sich die Markteinführungszeit um 30 Prozent verkürzen ließ, diese dann aber nicht umsetzten. Der Engpass liegt nicht immer im Wissen. Viele Unternehmen wissen bereits, was zu tun ist. Sie messen dem Ganzen jedoch nicht genügend Bedeutung bei.

Michael Jastram über Produktgeschwindigkeit

Michael Jastram hat das Thema wie folgt umrissen: Product Velocity.

Der Kerngedanke besteht darin, über ein einzelnes Team, eine einzelne Methode oder ein einzelnes Tool hinauszublicken. DevOps funktioniert gut bei Software, lässt sich jedoch nicht eins zu eins auf regulierte cyber-physische Produkte übertragen. Bei diesen Produkten müssen die Bereiche Entwicklung, Bereitstellung, Geschäftsführung und Systemverwaltung zusammenarbeiten.

Der „Velocity Loop“ wurde als Übersicht zur Diagnose von Engpässen in diesen Bereichen vorgestellt. Er zeigt, wo Übergaben ins Stocken geraten, wo sich Warteschlangen bilden und wo Rückmeldungen zu spät eintreffen.

Michael fasste daraufhin vier Prinzipien der „Product Velocity“ zusammen.

„Value Thinking“ bedeutet, dass die Arbeit der Ingenieure auf den Nutzen für Kunden und Stakeholder ausgerichtet sein muss. Berichte, Dokumente und Überprüfungen, die niemand nutzt, sind Verschwendung.

„Architect for Flow“ bedeutet, dass Produktarchitektur und Organisation aufeinander abgestimmt sein müssen. Das Conway-Gesetz wird zu einer praktischen Gestaltungsvorgabe. Wenn die Architektur der Organisation entgegenwirkt, häufen sich die laufenden Projekte an und Entscheidungen verzögern sich.

„Shift Left“ bedeutet mehr als nur eine frühzeitige Analyse. Es bedeutet, das Lernen, die Validierung und die Integration in kürzere Zyklen zu verlagern.

Plattform-Hebelwirkung sorgt für reproduzierbare Geschwindigkeit. Die Geschwindigkeit von BYD lässt sich nicht mit einer einzigen Maßnahme erklären. Sie beruht auf mechanischen, elektrischen und Software-Plattformen, die Anpassungen kostengünstiger und schneller machen.

Die Fallstudien verdeutlichten dies. Wagner verkürzte die Zulassungszeit für einige Systeme von Monaten auf Wochen oder Tage, indem das Unternehmen eine sichere Testumgebung mit TÜV-Zulassung schuf. ZF reduzierte die Validierungszeit durch Simulation, MBSE und KI von 12 Monaten auf 2 Monate. SHW nutzte Design-Compiler-Technologie, um schneller und präziser auf Kundenanfragen reagieren zu können.

Was die Diskussion beigetragen hat

Die Diskussion verlagerte sich schnell von den Methoden hin zum Thema Führung.

Zunächst wurde das Thema KI angesprochen. Die Podiumsteilnehmer waren sich einig, dass aktuelle KI-Systeme nützlich sind, da sie große Informationsmengen verarbeiten. Sie ersetzen jedoch nicht das ingenieurwissenschaftliche Urteilsvermögen. Ihre Stärke entfaltet sich, wenn sie mit sauberen Daten, soliden Architekturen und klar definierten Prozessen arbeiten.

Die Diskussion wandte sich dann den Konzepten “Shift Left” und „Front-Loading“ zu. „Front-Loading“ bedeutet, sich Wissen bereits frühzeitig anzueignen. „Shift Left“ geht noch einen Schritt weiter. Dabei werden Verifizierung, Integration und Lernen in kleinere Inkremente aufgeteilt. Das Ziel besteht darin, dem „Moment der Wahrheit“ alle paar Wochen statt alle paar Jahre zu begegnen.

Im Hinblick auf den deutschen Mittelstand diskutierte das Podium die Realitäten von „Configure-to-Order“ und „Engineer-to-Order“. Deutsche Unternehmen sind stark in der kundenspezifischen Anpassung. Diese Stärke wird jedoch zu einem Geschwindigkeitsproblem, wenn Plattformen, Varianten, PLM, ERP und Konstruktionsprozesse nicht aufeinander abgestimmt sind.

Die Diskussion endete mit dem Thema Führung. Beschleunigung erfordert Führung von oben und Eigeninitiative der Teams. Die Menschen brauchen Zeit, Befugnisse und Freiraum, um das System, in dem sie arbeiten, zu verändern. Ohne all das bleibt die Transformation nur eine Präsentation.

Das Gespräch fortsetzen

Dieses Webinar hat ein Muster bestätigt, das wir in vielen Unternehmen beobachten. Schnelligkeit entsteht nicht durch die Einführung einer weiteren Methode. Sie entsteht dadurch, dass man die Art und Weise verändert, wie Entscheidungen, Architektur, Werkzeuge, Feedback und Verantwortung zusammenwirken.

Formal Mind arbeitet mit Unternehmen zusammen, die die Produktgeschwindigkeit in realen Entwicklungsorganisationen analysieren und verbessern möchten. Dies kann mit einem gezielten Workshop, einer Engpassanalyse oder einer 30-tägigen Intervention beginnen.

Wenn Sie das Gespräch fortsetzen möchten, wenden Sie sich bitte gemeinsam an die Podiumsteilnehmer oder kontaktieren Sie uns einzeln.

Kontakt

• Michael Jastram für die Produktgeschwindigkeit, die Engpassdiagnose und 30-tägige Maßnahmen.
• Martin Eigner für PLM, MBSE, Systemtechnik, das erweiterte V-Modell und die virtuelle Produktentwicklung.
• Joachim Pfeffer für agile Hardware-Entwicklung, Lean-Entwicklung, Scrum, Kanban und organisatorischen Wandel.