Aktuelles / News
Mit wachsender Robotik verändert sich nicht nur das Produkt.
Auch das Engineering muss sich weiterentwickeln.
In frühen Phasen zählen Geschwindigkeit, technologische Tiefe und schnelle Lernzyklen.
Mit zunehmender Zahl an Kunden, Anwendungen und Deployments kommen weitere Anforderungen hinzu:
• Wie viel Standardisierung braucht das Produkt?
• Wie werden Varianten beherrschbar?
• Wie lassen sich Erfahrungen aus einzelnen Anwendungen systematisch für weitere Produkte nutzen?
• Welche Entscheidungen müssen näher an Architektur und Produktstrategie rücken?
• Und wie bleiben Entwicklungsprozesse schnell, obwohl Produkt und Organisation komplexer werden?
Dabei geht es nicht darum, jungen Unternehmen möglichst früh große Prozesse zu geben.
Es geht darum, Strukturen dort weiterzuentwickeln, wo sie Wachstum ermöglichen.
Gerade in der Robotik müssen Produktarchitektur, Engineering, Qualität und Organisation deshalb zunehmend zusammengedacht werden.
Skalierung bedeutet nicht nur, mehr Roboter zu liefern. Es heißt auch, die Engineeringfähigkeit mitwachsen zu lassen.
Viele MBSE Transformationen bleiben organisatorisch Methodeneinführungen mit Transformationsetikett.
Ich sehe in Unternehmen immer wieder dieses Muster:
Der Einstieg in MBSE erfolgt über ein Tool, beispielsweise ein ALM System. Dazu kommen Methoden und Tooltrainings. Requirements Engineering wird geschult, Modellierung wird geschult, das Tool wird geschult.
Und irgendwann heißt das Ganze „MBSE Transformation“.
Das Problem ist nicht das Tool. Und auch nicht das Training.
Das Problem entsteht, wenn man erwartet, dass sich dadurch die Organisation gleich mitverändert.
Denn danach arbeiten die Menschen häufig weiter in denselben Strukturen:
• Verantwortlichkeiten bleiben unklar.
• Entscheidungswege und Reviews bleiben unverändert.
• Organisation und Produktarchitektur passen nicht zusammen.
• Führung erwartet neue Methoden, steuert aber nach der alten Logik.
Eine aktuelle Veröffentlichung im Systems Engineering Journal passt bemerkenswert gut zu dieser Beobachtung. Die Autor:innen identifizieren 49 Barrieren für Digital Engineering Transformation in sechs miteinander verbundenen Dimensionen:
People. Technology. Processes. Culture. Infrastructure. Goals.
Viele dieser Barrieren wirken über mehrere Transformationsziele hinweg. Digital Engineering ist damit eben nicht nur eine technische oder methodische Herausforderung.
MBSE Transformation ist eine soziotechnische Transformation.
Wenn sich die Engineering Arbeitsweise verändert, müssen Rollen, Entscheidungswege, Prozesse, Organisation und Führung mitgedacht werden. Sonst trainieren wir eine neue Engineering Logik und schicken die Menschen anschließend zurück in eine Organisation, die weiterhin nach der alten funktioniert.
Eine Automotive Fabrik kann vergleichsweise schnell Defense Produkte fertigen.
Eine Engineering Organisation lässt sich nicht einfach umetikettieren.
Automotive bringt enorme Kompetenz in Industrialisierung, Standardisierung, Lieferantenentwicklung und Lean Production mit.
Aber ein Defense Produkt, das für kleine Stückzahlen entwickelt wurde, wird nicht allein dadurch skalierbar, dass zusätzliche Fertigungskapazität vorhanden ist.
Wenn Produktarchitektur, Variantenlogik, Prüfkonzept und Supply Chain auf Kleinserie ausgelegt sind, skaliert man zunächst vor allem die Probleme.
Deshalb beginnt der industrielle Hochlauf früher:
• Produktarchitekturen verändern, damit Systeme modularer und besser industrialisierbar werden.
• Standardisieren, wo individuelle Lösungen keinen entscheidenden Mehrwert schaffen.
• Komplexität herausnehmen, damit stabile und wirklich leane Fertigungsflüsse möglich werden.
• Supply Chains bereinigen und hochfahren, Abhängigkeiten reduzieren und Lieferanten auf höhere Volumen vorbereiten.
• Engineering und Entscheidungswege anpassen, damit Varianten, Änderungen und Industrialisierung nicht zum neuen Engpass werden.
Die entscheidende Frage lautet deshalb nicht nur: Wo können wir produzieren?
Sondern: Ist das Produkt überhaupt so gestaltet, dass es sich skalieren lässt?
Wer Defense skalieren will, muss deshalb nicht nur Fertigungskapazität aufbauen.
Er muss Produkte für Skalierung neu denken.
Noch eine Methode oder Entscheidung?
Brauchen wir wirklich noch eine Methode – oder endlich eine Entscheidung?
Im Engineering versuchen wir oft, Unsicherheit weiter zu reduzieren.
Wir starten noch eine Shainin Analyse.
Wir schärfen das Requirements Engineering.
Wir vertiefen die FMEA.
Wir setzen einen weiteren Lean Workshop auf.
Wir ergänzen ein Review, einen Reifegradcheck oder ein weiteres Analyseformat.
Jede dieser Methoden kann sinnvoll und notwendig sein.
Aber keine Methode nimmt uns die Entscheidung ab.
Es gibt einen Punkt, an dem zusätzliche Analyse kaum noch relevante Sicherheit schafft – während das Nichtentscheiden zunehmend teuer wird.
Genau diese Spannung haben wir bereits in The Art of Engineering Leadership beschrieben: Entscheidungen entstehen nicht erst dann, wenn Unsicherheit verschwunden ist. Sie müssen dann getroffen werden, wenn die Entscheidungsgrundlage ausreichend belastbar ist. Die Abbildung zeigt diesen Zusammenhang zwischen zunehmender Entscheidungssicherheit und dem richtigen Entscheidungszeitpunkt.
Und hier wird Methodenkompetenz zur Führungsfrage.
Shainin kann Ursachen eingrenzen.
Requirements Engineering kann Klarheit schaffen.
FMEA kann Risiken transparent machen.
Lean kann Verschwendung und Störungen sichtbar machen.
Aber keine dieser Methoden beantwortet die Frage:
Wann wissen wir genug, um zu entscheiden?
Wenn wir Methoden immer weiter vertiefen, obwohl der wesentliche Zielkonflikt längst sichtbar ist, steigt nicht mehr automatisch die Entscheidungsqualität.
Dann steigt vor allem der Preis des Wartens.
Die entscheidende Frage lautet deshalb nicht: Welche Methode brauchen wir noch?
Sondern:
Ist wirklich noch Analyse erforderlich oder fehlt einfach die Entscheidung?
Engineering Leadership bedeutet auch, genau diesen Punkt zu erkennen.
Wenn Sie mehr erfahren wollen, oder an einem „Engineering Scalability / Transformation Reality Check“interessiert sind:
Haben wir Entscheidungsfähigkeit ausreichend organisiert?
Entscheidungsfähigkeit muss organisiert werden.
Verantwortung wird in vielen Engineering-Organisationen dezentral erwartet.
Entscheidungsrechte, Informationen und Eskalationswege bleiben jedoch zentral, unklar oder widersprüchlich.
Dann entsteht kein Empowerment.
Dann entsteht Verantwortung ohne Gestaltungsmacht.
Gerade in wachsenden Organisationen wird das zum Engpass. Führungskräfte können nicht mehr jede technische Entscheidung selbst begleiten. Gleichzeitig werden Teams nicht automatisch entscheidungsfähig, nur weil ihnen mehr Verantwortung übertragen wird.
Entscheidungsfähigkeit braucht Struktur.
Aus meiner Sicht vor allem drei Dinge:
• Klare Entscheidungsräume: Wer entscheidet was, mit welchem Mandat und wo liegen die Grenzen?
• Passende technische und organisatorische Schnittstellen: Produktarchitektur und Verantwortungsstruktur müssen so zusammenspielen, dass Entscheidungen überhaupt lokal getroffen werden können.
• Eine belastbare Informationsbasis: Anforderungen, Architektur, Reifegrad und Auswirkungen von Entscheidungen müssen nachvollziehbar sein.
Der kritische Punkt ist:
Entscheidungsfähigkeit lässt sich nicht delegieren. Sie muss gestaltet werden.
Damit verändert sich auch die Führungslogik.
Führung muss weniger Entscheidungen an sich ziehen und stärker dafür sorgen, dass im System gute Entscheidungen entstehen können.
Das bedeutet: technische Autorität klären, Entscheidungsräume definieren, Eskalationen bewusst gestalten und Abhängigkeiten reduzieren.
Gerade beim Skalieren ist das zentral.
Denn wenn jede relevante Entscheidung weiterhin nach oben wandert, wächst die Organisation – aber nicht ihre Leistungsfähigkeit.
Skalierbar wird Engineering erst dann, wenn Entscheidungen nicht mit der Hierarchie wachsen.
Wenn Sie mehr erfahren wollen, oder an einem „Engineering Scalability / Transformation Reality Check“interessiert sind:
Wachsen oder skalieren?
Wachstum ist kein Skalieren. Gerade im Engineering wird das schnell sichtbar.
Der Defense-Markt zeigt das derzeit besonders deutlich: Neue Aufträge, neue Programme, neue Lieferant*innen, zusätzliche Standorte, mehr Varianten und hoher Zeitdruck treffen auf Engineering-Organisationen, deren Strukturen oft für deutlich stabilere Rahmenbedingungen entstanden sind.
Das Problem ist aber keineswegs auf Defense beschränkt. Auch Robotics, Aerospace, Maschinenbau und schnell wachsende Technologieunternehmen stehen vor derselben Frage:
Wie wächst Engineering-Leistung, ohne dass Koordinationsaufwand und Komplexität im gleichen Maß mitwachsen?
Die naheliegende Antwort auf Wachstum lautet häufig: mehr Personal.
Das kann notwendig sein. Aber mehr Personal erhöht zunächst nur die Kapazität. Skalierbar wird Engineering erst, wenn zusätzliche Menschen nicht im gleichen Maß zusätzliche Abstimmung erzeugen.
Dafür müssen sich mehrere Dinge gleichzeitig verändern:
- Produkt- und Variantenarchitektur: Modularisierung, klare Schnittstellen und eine beherrschbare Variantenlogik reduzieren Komplexität an der Quelle.
- Verantwortungs- und Entscheidungsarchitektur: Entscheidungen müssen dort getroffen werden können, wo Wissen und Verantwortung liegen.
- Entwicklungsfluss und Reifegradlogik: Klare Commit Points, transparente Reife und frühe Integration verhindern, dass Probleme nur schneller weitergereicht werden.
- Wissens- und Datenmodell: Anforderungen, Architektur, Nachweise und Änderungen müssen konsistent verknüpft sein.
- Kompetenz- und Integrationsfähigkeit: Neue Mitarbeitende, Teams und Lieferant*innen müssen schnell anschlussfähig werden.
Und auch die Führungslogik muss sich verändern.
Je größer eine Engineering-Organisation wird, desto weniger kann Führung über persönliche Intervention, Einzelentscheidungen und direkte Kontrolle funktionieren.
Führung muss stärker das System gestalten, in dem gute Entscheidungen entstehen:
klare Verantwortungsräume schaffen, Entscheidungsfähigkeit verteilen, technische Leitplanken setzen, Abhängigkeiten beherrschbar machen und dafür sorgen, dass Wissen nicht an einzelnen Personen hängt.
Mehr Menschen, die im gleichen System auf die gleiche Weise arbeiten, machen dieses System nicht automatisch leistungsfähiger.
Die eigentliche Skalierungsfrage lautet deshalb nicht:
Wie bekommen wir mehr Menschen ins Engineering?
Sondern:
Wie verändern wir Architektur, Organisation und Führungslogik so, dass mehr Kapazität tatsächlich zu mehr Entwicklungsleistung wird?
Wenn Sie mehr erfahren wollen, oder an einem „Engineering Scalability / Transformation Reality Check“interessiert sind:
