China Speed und die Krise des klassischen Systems Engineerings

China entwickelt Elektrofahrzeuge heute in Entwicklungszyklen, die in Deutschland lange als unrealistisch galten. BYD spricht von etwa 18 Monaten von Konzept bis Marktstart. Volkswagen kündigte 2025 an, den eigenen MEB-Zyklus auf etwa 40 Monate reduziert zu haben. Noch vor wenigen Jahren lagen die Zahlen deutlich höher.

Die deutsche Diskussion erklärt diesen Abstand gerne mit Subventionen, niedrigen Lohnkosten oder mangelnder Regulierung. Aber das erklärt nicht, warum chinesische Unternehmen gleichzeitig bei OTA-Infrastruktur, Softwareplattformen, Batterieintegration und digitalem Kundenzugang schneller wurden. Es erklärt auch nicht, warum viele europäische OEMs heute Methoden übernehmen, die sie vor wenigen Jahren noch als „nicht automotive“ abgelehnt hätten.

Das Interview mit Yuchao Luo (Video) liefert eine seltene Perspektive auf diese Entwicklung. Luo arbeitete sowohl bei NIO als auch vorher bei Bosch in Bamberg. Er kennt chinesische EV-Entwicklung ebenso wie deutsche Automotive-Prozesse. Seine Aussagen sind deshalb interessant, weil sie keine politische oder kulturelle Debatte führen. Er beschreibt Mechanismen. Genau dort wird das Thema für Systems Engineering relevant.

Yuchao Luo

Yuchao Luo (LinkedIn) studierte Fahrzeugtechnik in China und kam 2013 für ein Masterstudium nach Deutschland. Während dieser Zeit absolvierte er ein Praktikum bei Bosch in Bamberg. 2017 kehrte er nach China zurück und arbeitete zunächst bei NIO, einem der frühen chinesischen EV-Hersteller. Danach wechselte er zu Z-One Software, einer hundertprozentigen Tochter von SAIC, die an der Softwareplattform für Premiumfahrzeuge arbeitet.

Heute berät Luo Unternehmen im Umfeld von Agile, ASPICE und AI-gestützter ALM-Entwicklung. Interessant an seiner Perspektive ist weniger die Begeisterung für „China Speed“. Interessant ist seine Beschreibung der organisatorischen Unterschiede zwischen klassischen OEMs und neuen EV-Unternehmen.

Viele Aussagen erinnern an Diskussionen, die im Systems Engineering seit Jahren geführt werden. Plattformarchitekturen. Verkürzte Feedbackzyklen. Continuous Integration. OTA-Updates. Frühe Verifikation. Direkter Kundenzugang. Der Unterschied liegt darin, dass chinesische EV-Unternehmen diese Mechanismen unter massivem Wettbewerbsdruck praktisch anwenden mussten, während viele europäische Organisationen sie bis heute als Zukunftsthema behandeln.

Zusammenfassung des Interviews

Luo beschreibt den eigentlichen Bruchpunkt zwischen klassischer Automotive-Entwicklung und den neuen EV-Herstellern in den Jahren 2017 und 2018. In dieser Phase entstanden in China zahlreiche neue Unternehmen rund um Elektrofahrzeuge und softwaredefinierte Fahrzeuge. Viele Gründer kamen aus dem Internet- oder Smartphone-Umfeld. Sie brachten andere technische Reflexe mit.

Während klassische OEMs über Freigabeprozesse und Lieferketten diskutierten, bauten neue Anbieter OTA-Infrastruktur und direkte Kundenfeedbackschleifen auf. Luo beschreibt einen entscheidenden Unterschied: Kundenfeedback allein reicht nicht. Entscheidend ist die Fähigkeit, auf dieses Feedback innerhalb kurzer Zeit zu reagieren.

Das erinnert stark an DevOps-Diskussionen der letzten Jahre. Auch dort war der eigentliche Durchbruch nicht Monitoring oder Telemetrie. Entscheidend war die Fähigkeit, Änderungen schnell und sicher in Betrieb zu bringen.

Nio’s Firefly EV earns five-star Euro NCAP rating as deliveries surge

ev.com, September 9, 2025

Artikel lesen

Luo beschreibt außerdem einen kulturellen Unterschied bei der Reihenfolge der Fragen. In Deutschland wird bei neuen Technologien häufig zuerst gefragt, ob etwas compliant und sicher ist. In China wird zunächst gefragt, ob etwas funktioniert und wie man daraus lernen kann. Die Compliance-Frage folgt danach.

Das bedeutet ausdrücklich nicht, dass chinesische Unternehmen Sicherheit ignorieren. Luo erwähnt selbst Batterieprobleme und Qualitätsprobleme bei frühen EV-Anbietern. Der Unterschied liegt in der Organisationslogik. Deutsche Unternehmen versuchen Unsicherheit möglichst früh auszuschließen. Chinesische Unternehmen akzeptieren Unsicherheit länger und reduzieren sie iterativ.

Besonders interessant ist seine Sicht auf Qualität. Luo zitiert einen Bosch-China-Manager mit einer provokanten Aussage:

„Even though you set your process for a lot of compliance, for the very strict standards, you have no proof.“

Yuchao Luo, citing Bosch manager

Die Aussage zielt nicht gegen Prozesse oder Standards. Sie richtet sich gegen die Vorstellung, dass Prozesskonformität automatisch Qualitätsbeweis sei. Ein Fahrzeug, das in Millionen Stückzahlen im Markt betrieben wird, erzeugt eine andere Art von Evidenz als ein sauber dokumentierter Prozess mit wenigen Testfahrzeugen.

Damit trifft Luo einen empfindlichen Punkt des klassischen Systems Engineerings. Viele Organisationen optimieren heute die Nachweisbarkeit von Prozessen. Sie optimieren deutlich weniger die Geschwindigkeit von Lernen und Evidenzgewinn.

Auch seine Aussagen zu MBSE sind bemerkenswert differenziert. Luo lehnt MBSE nicht ab. Er beschreibt aber ein Timing-Problem. In stabilen Domänen mit bekannten Komponenten funktionieren modellbasierte Ansätze hervorragend. In Bereichen des softwaredefinierten Fahrzeugs entstehen dagegen viele Funktionen erstmals. Dort existieren weder stabile Modelle noch wiederverwendbare Architekturen. Direkte Implementierung dominiert deshalb zunächst.

Das erklärt möglicherweise einen Teil der MBSE-Frustration vieler Unternehmen. Nicht jedes Problem ist bereits stabil genug, um sinnvoll modelliert zu werden.

Implikationen für das Systems Engineering

Das Interview zeigt vor allem eines: Viele Probleme heutiger Produktentwicklung sind keine Methodenprobleme. Sie sind Strukturprobleme.

Das klassische V-Modell entstand in einer Welt mit langen Hardwarezyklen, klar getrennten Domänen und relativ stabilen Produktdefinitionen. Diese Welt existiert im softwaredefinierten Fahrzeug nur noch teilweise.

Viele Organisationen führen deshalb heute moderne Werkzeuge ein, ohne ihre Entwicklungslogik zu verändern. Continuous Integration wird eingeführt, aber Freigabeentscheidungen bleiben monatelang blockiert. MBSE wird eingeführt, aber Änderungen wandern weiterhin durch hierarchische Gremien. Agile Teams entstehen, aber die Architektur verhindert unabhängige Arbeit.

Das Resultat wirkt modern und bleibt langsam. Gerade Systems Engineering trägt dafür eine Mitverantwortung. In vielen Unternehmen entwickelte sich SE über Jahre zu einer Dokumentations- und Governancefunktion. Die eigentliche Systemgestaltung rückte in den Hintergrund. Architekturentscheidungen wurden organisatorisch entkoppelt von Delivery-Geschwindigkeit und operativem Lernen.

Das ist einer der Gründe, warum klassische Automotive-Organisationen Schwierigkeiten mit dem softwaredefinierten Fahrzeug haben. Das Problem ist nicht fehlende Kompetenz. Deutsche OEMs besitzen enorme technische Tiefe. Das Problem ist die Kopplung zwischen Organisation, Architektur und Entscheidungswegen.

Product Velocity ergänzt Systems Engineering

Hier wird die Diskussion um Product Velocity relevant. Product Velocity beschreibt genau diese Zusammenhänge zwischen Business, Architektur, Entwicklung und operativer Rückkopplung. Die vier Prinzipien lauten: Value Thinking, Architect for Flow, Shift Left und Accelerate.

Interessant ist dabei, dass chinesische EV-Unternehmen diese Prinzipien oft anwenden, ohne den Begriff zu verwenden. Die Mechanismen entstehen aus Wettbewerbsdruck und Organisationsdesign.

Besonders deutlich wird das beim Prinzip „Architect for Flow“. BYD oder NIO reduzierten nicht einfach Prozesse. Sie bauten Architekturen, die schnelle Änderungen überhaupt erst ermöglichen. OTA, Plattformstrategien, vertikale Integration und Softwareplattformen reduzieren organisatorische Kopplung.

Viele deutsche Unternehmen versuchen dagegen, Geschwindigkeit auf bestehende Strukturen aufzusetzen. Das funktioniert nur begrenzt. Komplexität verschwindet nicht. Sie verlagert sich.

Auch „Shift Left“ wird häufig missverstanden. Shift Left bedeutet nicht einfach mehr frühe Reviews oder mehr Simulation. Es bedeutet, Unsicherheit möglichst früh sichtbar zu machen. Das setzt kurze Feedbackzyklen voraus. Viele deutsche Prozesse erzeugen dagegen lange Phasen scheinbarer Stabilität, gefolgt von späten Integrationskrisen.

Interessanterweise beschreibt Luo genau diese Dynamik indirekt bei AI-gestützter Entwicklung. Europäische Organisationen fragen zuerst nach vollständiger Korrektheit. Chinesische Unternehmen akzeptieren zunächst 70 bis 80 Prozent Qualität und kombinieren das mit menschlicher Review.

Das entspricht letztlich klassischem Engineering-Denken. Auch Menschen produzieren keine fehlerfreien Ergebnisse. Deshalb existieren Reviews, Tests und Verifikation überhaupt.

Was passieren muss, um wieder wettbewerbsfähig zu werden

Die entscheidende Frage lautet nicht, ob Deutschland chinesische Methoden kopieren sollte. Die entscheidende Frage lautet, welche strukturellen Eigenschaften schnelle Produktentwicklung ermöglichen.

Viele Diskussionen drehen sich noch immer um Einzelmethoden. Agile. MBSE. DevOps. AI. Das greift zu kurz. Wettbewerbsfähigkeit entsteht heute aus der Fähigkeit, technische und organisatorische Lernzyklen zu verkürzen. Dafür müssen mehrere Dinge passieren:

Erstens müssen Architekturen stärker auf Änderbarkeit ausgelegt werden. Viele heutige Fahrzeugplattformen erzeugen enorme Koordinationskosten zwischen Teams und Lieferanten. Jede Änderung zieht eine Kette organisatorischer Abhängigkeiten nach sich. Das Resultat sind langsame Entscheidungen und hohe Integrationskosten.

Zweitens müssen Entwicklungsorganisationen lernen, operative Evidenz ernst zu nehmen. Viele Unternehmen vertrauen noch immer stärker auf Planungsartefakte als auf reale Nutzungsdaten. Das war in klassischen Hardwarezyklen lange akzeptabel. Im softwaredefinierten Fahrzeug reicht es nicht mehr.

Drittens muss Systems Engineering wieder stärker als integrierende Disziplin verstanden werden. Nicht als Dokumentationsinstanz, sondern als aktiver Gestalter von Systemgrenzen, Schnittstellen und Entscheidungsstrukturen.

Das bedeutet ausdrücklich nicht, dass das V-Modell abgeschafft werden muss.

Die Rolle des V-Modells

Das V-Modell enthält weiterhin sinnvolle Grundideen: Zerlegung komplexer Systeme, Verifikation gegen Anforderungen, systematische Integration. Das Problem liegt weniger im Modell selbst als in seiner praktischen Interpretation.

In vielen Unternehmen wurde das V-Modell zu einer sequenziellen Governance-Maschine. Entscheidungen wandern linear durch Organisationen. Rückkopplung erfolgt spät. Verantwortung fragmentiert sich entlang von Dokumenten und Freigaben. Aber genau dort entsteht die eigentliche Trägheit.

Ein modernes V-Modell müsste anders gelebt werden. Frühe und kontinuierliche Verifikation statt später Freigabeereignisse. Kontinuierliche Integration statt periodischer Großintegration. Systemarchitekturen, die unabhängige Entwicklung ermöglichen. Kürzere Entscheidungswege. Operative Daten als Teil der Entwicklung.

Interessanterweise existieren viele technische Voraussetzungen bereits. Deutsche OEMs besitzen große HIL-Landschaften, leistungsfähige Simulationsumgebungen und hohe Kompetenz im funktionalen Safety Engineering. Das Problem ist weniger Technologie als organisatorische Nutzung.

Viele Organisationen behandeln moderne Entwicklungsinfrastruktur noch immer wie klassische Qualitätssicherung. Eigentlich müsste sie zur Beschleunigung von Lernen genutzt werden.

Auch politisch und regulatorisch wird sich etwas ändern müssen. Luo beschreibt einen wichtigen Unterschied im Umgang mit OTA-Regulierung in China. Dort wurde OTA nicht verboten oder massiv eingeschränkt. Stattdessen wurde Transparenz eingeführt. Updates müssen gemeldet werden. Der Iterationsmechanismus bleibt erhalten.

Das ist ein interessanter Gedanke für europäische Regulierung insgesamt. Innovation und Nachweisbarkeit müssen kein Widerspruch sein. Gefährlich wird es erst, wenn Compliance jede frühe Iteration verhindert.

Fazit

Das Interview mit Yuchao Luo zeigt keine technologische Überlegenheit chinesischer Unternehmen. Es zeigt Unterschiede in Organisationslogik, Architekturdenken und Umgang mit Unsicherheit.

Deutschland besitzt weiterhin enorme technische Kompetenz im Systems Engineering. Viele der weltweit wichtigsten Methoden und Standards entstanden genau hier. Das Problem liegt deshalb nicht im fehlenden Wissen. Das Problem liegt in der Geschwindigkeit organisatorischen Lernens.

Viele Unternehmen optimieren heute noch immer auf lokale Prozesskonformität statt auf globale Entwicklungsdynamik. Das funktionierte in stabilen Märkten mit langen Produktzyklen. Im softwaredefinierten Fahrzeug funktioniert es immer schlechter.

Die eigentliche Herausforderung besteht deshalb nicht darin, agile Methoden einzuführen oder AI-Werkzeuge auszurollen. Die Herausforderung besteht darin, Entwicklungssysteme so zu gestalten, dass Lernen schneller wird als die Veränderung des Marktes.

Genau dort beginnt Product Velocity.