Nicht die Ingenieure: Wenn das Vorgehensmodell zum Engpass wird

Eine Mission des Starship soll rund 10 Millionen Dollar kosten (wenn es mal fertig ist). Ein Start von Artemis (oder offiziell Space Launch System, SLS) kostet die NASA etwa 4,1 Milliarden. Das ist Faktor 410, im selben Land, mit Absolventen derselben Universitäten und teils denselben Zulieferern. Der Unterschied liegt mit Sicherheit nicht an besseren Ingenieuren. Der Unterschied liegt in der Geschwindigkeit, mit der die jeweilige Organisation lernt. Für Systems Engineering ist das eine unbequeme Diagnose, denn diese Geschwindigkeit steckt nicht in den Köpfen der Beteiligten, sondern im Vorgehensmodell. Ups!

Das V-Modell rechnet mit bekannten Problemen

Das V-Modell, ob nach VDI 2206 oder als V-Modell XT, ordnet die Entwicklung entlang einer klaren Logik. Links steht die Zerlegung: Anforderungen, Systemarchitektur, Detailentwurf. Rechts steht die Integration mit Modultest, Systemintegration sowie Verifikation und Validierung. Die Annahme darunter ist, dass sich die Anforderungen zu Beginn festlegen lassen und wenige Iterationen ausreichen. Unter dieser Annahme ist das Modell rational. Bei sicherheitskritischer Hardware mit hohen Änderungskosten zahlt sich frühe Festlegung aus.

Die Annahme trägt nur, solange die Unsicherheit gering bleibt. Beim Wechsel zur Elektromobilität, bei neuer Fahrzeugsoftware oder bei unklaren Märkten kippt sie. Dann zeigt sich erst weit rechts im V, bei Integration und Validierung, ob die Spezifikation links getaugt hat. Genau dort ist eine Änderung am teuersten. Das Modell serialisiert das Lernen. Pro Programm läuft eine einzige vollständige Schleife.

Die Zahlen aus der Automobilindustrie illustrieren das. BYD entwickelt ein Fahrzeug in rund 18 Monaten, Volkswagen nach eigenen Effizienzprogrammen in etwa 40. Porsche legte sich 2018 auf sechs Milliarden Euro für Elektroantriebe fest, korrigierte den Kurs später wieder und drehte damit rund zehn Milliarden Euro im Kreis. Xiaomi, ein Smartphone-Hersteller, verkaufte mit dem SU7 in China mehr Limousinen als Porsche mit dem Taycan. Niemand wird behaupten, Xiaomis Ingenieure seien die besseren.

Lernen ist die eigentliche Engpassgröße

Bei hoher Unsicherheit ist die bindende Restriktion nicht die Qualität eines einzelnen Entwurfs, sondern die Rate, mit der eine Organisation Annahmen in gesichertes Wissen überführt. Jeder Durchlauf von der Anforderung über den Entwurf bis zur Validierung ist ein Lernzyklus. Wer das V einmal von links oben nach rechts oben durchläuft, erhält genau einen großen Lernzyklus pro Programm. Das ist die strukturelle Bremse.

Schnelle Organisationen verkürzen diesen Zyklus, statt ihn zu perfektionieren. Saab entwickelt den Gripen E mit 2.000 bis 4.000 Beteiligten in über 100 Teams. Ein technischer Blocker eskaliert dort vom morgendlichen Standup binnen einer Stunde bis zur Entscheidung auf Führungsebene. Die relevante Kennzahl ist nicht die Teamgröße, sondern die Latenz einer Entscheidung. Ein V-Modell mit einer Freigabeschleife über Quartale hat diese Latenz strukturell eingebaut.

Architektur entscheidet, was sich parallel lernen lässt

Wie viele Lernzyklen gleichzeitig laufen können, entscheidet die Architektur. Modulare Systeme mit stabilen Schnittstellen erlauben es Teams, unabhängig voneinander zu lernen. Eng gekoppelte Systeme erzwingen das Gegenteil. Teilt ein Subsystem versteckte Abhängigkeiten mit drei anderen, löst jede Änderung eine teamübergreifende Neuverhandlung aus. Aus Entwicklungsarbeit wird Abstimmungsarbeit, und die Integration staut sich, lange bevor das erste Release ansteht.

Damit wird die Schnittstelle zum eigentlichen Hebel des Systems Engineering. Eine stabile Schnittstelle ist ein Vertrag, der den rechten Ast des V verkürzt, weil Integration vorhersagbar wird. Sie ermöglicht, dass Untersysteme als Black Box behandelt werden können. Teams können entwickeln, ohne Angst haben zu müssen, dass Änderungen unerwartete Konsequenzen haben, ohne dass die Änderungswünsche monatelang in Gremien feststecken.

Conways Gesetz wirkt hier doppelt. Die Architektur prägt die Organisation, und die Organisation friert die Architektur ein. Wer parallel lernen will, muss die Trennlinien zwischen den Subsystemen bewusst legen, bevor die Organisation sie zufällig festlegt.

Verifikation nach links ziehen

Der rechte Ast des V ist teuer, weil er spät kommt. Integration, Verifikation, Validierung und Zertifizierung fallen dann an, wenn Hardware existiert und Änderungen Geld kosten. Model-Based Systems Engineering verschiebt einen Teil dieser Prüfung nach vorn. Eigenschaften lassen sich gegen ein Modell verifizieren, bevor das erste Blech gebogen ist. So wandert die Verifikation dorthin, wo Lernen billig ist.

Zertifizierung muss kein Endgate bleiben. Der Brandschutzspezialist Wagner führt die sicherheitstechnische Absicherung kontinuierlich mit und hält die TÜV-Konformität über die gesamte Entwicklung, statt sie am Ende in einem großen Schritt nachzuweisen. Ein Sicherheitsnachweis nach ISO 26262 kann ein lebendes Artefakt sein, das mit jeder Iteration mitwächst. Set-Based Concurrent Engineering geht in dieselbe Richtung. Mehrere Lösungsvarianten bleiben offen, bis Messdaten eine davon ausschließen, statt sich früh auf einen Punkt festzulegen und später teuer umzuplanen. Die Traceability bleibt erhalten. Sie liefert dann schnelles Feedback statt nur Material für das Audit.

Fazit

Deutschlands Rückstand bei der Entwicklungsgeschwindigkeit ist kein Talentproblem. Er steckt im Zusammenspiel aus Vorgehensmodell und Organisation, und beides ist konstruiert, also veränderbar. Die Disziplin, die das V-Modell hervorgebracht hat, kann es auch neu fassen. Der rechte Ast lässt sich verkürzen, ohne die Strenge aufzugeben, die sicherheitskritische Produkte verlangen.

Dafür muss sich die Leitfrage ändern. Sie lautet nicht mehr, ob die Spezifikation vollständig und verifiziert ist. Sie lautet, wie viele validierte Lernzyklen eine Organisation schafft, bevor der Markt weiterzieht. Diese Verschiebung beschreibt der Ansatz von Product Velocity mit vier Prinzipien: Wertorientierung, Architektur für Flow, Lernen nach links ziehen und Auslieferung als Beginn des Lernens. Die Ingenieure sind selten das Problem. Das System, in dem sie arbeiten, ist es meistens.