Systems Engineering Trends

Donnerstags in 5 Minuten für Ingenieure und Entscheider: Systems Engineering ohne Hype, dafür mit Tiefgang

InterviewWerkzeuge

Warum wir neue Entwicklungswerkzeuge brauchen: Einblicke in MBSE von Pari Singh (Teil 1)

Systems Engineering, wie es heute praktiziert wird, ist kaputt — zumindest nach Ansicht von Pari Singh. Er ist der Meinung, dass Entwicklungswerkzeuge im „dunklen Zeitalter“ feststecken und ist entschlossen, dies zu ändern. Und er ist mit seinem Unternehmen Flow Engineering auf einem guten Weg, dies zu ändern.

Pari Singh hat eine Ausbildung als Maschinenbauingenieur und wurde in die Forbes 30 under 30-Liste 2019 aufgenommen. Mit seinem 2019 gegründeten Unternehmen Flow Engineering will er die Produktentwicklung revolutionieren.

Ich hatte das Vergnügen, am 21. Juni 2024 mit Pari Singh über Systems Engineering im Allgemeinen und speziell über MBSE zu sprechen. Im Folgenden das Gespräch in Text und als Video.

Hinweis: Am 1. August moderiert Michael Jastram ein Webinar über die KI-Erweiterung von Raiqon für Codebeamer in der Automobilentwicklung. Kostenlos registrieren >>

Dieser Artikel wurde auch auf Englisch im Formal Mind-Blog veröffentlicht.

Pari Singh & Flow Engineering

Obwohl Paris Firma, Flow Engineering, SaaS-Software anbietet, hat das Unternehmen einen unglaublichen Pivot vollzogen. Pari begann als Maschinenbauingenieur, der von SpaceX beeindruckt war, was ihn in die Raumfahrtindustrie trieb. Um 2010, als er noch an der Universität war, gründete er ein Unternehmen für die Entwicklung von Raketentriebwerken.

Daraufhin baute Pari kurzerhand ein Unternehmen auf, das in der Lage war, Raketentriebwerkskonstruktionen innerhalb von Stunden zu liefern, wo die Konkurrenz Monate benötigte. Dies gelang ihm durch den Aufbau eines ausgeklügelten Netzwerks miteinander verbundener Modelle (Matlab, CAD, FEM usw.) mit Rückkopplungsschleifen. Er erkannte, dass der Markt agiler Hardware braucht und dass die handelsüblichen Werkzeuge für Teams, die agil arbeiten wollten, völlig ungeeignet waren.

Dies führte zu einer Neuausrichtung des Geschäftsmodells. Als er mit Investoren sprach, erkannten sie, dass (1) die traditionelle Entwicklung grundsätzlich nicht mehr funktioniert, (2) dass er einen neuen Ansatz für die mechanische Systementwicklung erfunden hat und (3) dass sein Unternehmen, wenn es einen Weg findet, dies zu formalisieren und als Produkt an deren ursprünglichen Kunden zu geben, das Problem lösen können, für das sie das Unternehmen ursprünglich gegründet hatten, nämlich der gesamten Branche zu helfen, sich viel schneller zu bewegen.

Um Marktakzeptanz zu erlangen, haben die Endnutzer bei Flow höchste Priorität. Unternehmen wie Dassault oder Siemens verkaufen an die Chefingenieure oder Entscheider, was oft zu einer mittelmäßigen Nutzererfahrung führt. Für Flow ist eine bessere Usability für den Endnutzer der Schlüssel. Das Unternehmen erwartet, dass Entscheider überzeugt werden, wenn die Nutzer den Wert der Lösung erkennen.

Das vollständige interview, durchgeführt von Michael Jastram
Ein weiteres interessantes Interview, geführt von Mo Islam bei Payload

Interview with Pari Singh

Michael Jastram führte das Interview mit Pari Singh am 21. Juni 2024

Du äußerst Dich deutlich zum agilen Engineering, das sich mittlerweile bewährt hat. Warum tun sich so viele Unternehmen schwer mit der Einführung?

Ich würde gerne etwas über den Kontext dieses Wandels sagen, denn ich glaube nicht, dass die Systems-Engineering-Gemeinschaft schon eine gute Definition dafür hat, was genau der Wandel ist. Viele Leute sagen, Agilität bedeutet zweiwöchige Sprints, Software MVPs, aber das beschreibt es nicht wirklich. Daher möchte ich mit etwas Abstand einen Überblick über den Kontext geben, in dem sich diese Veränderung vollzieht und warum sie so wichtig ist.

In der Systems-Engineering-Gemeinschaft vollzieht sich derzeit ein Wandel, wie er nur selten stattfindet. Das letzte Mal, dass ein Wandel in dieser Größenordnung stattgefunden hat, war wahrscheinlich in den 1960er Jahren, als Systems Engineering in den Anfängen entstand. Dieser Wandel vollzieht sich von einem eher traditionellen, von oben nach unten verlaufenden, wasserfallorientierten 10-Jahres-Entwurfszyklus, bei dem es darum geht, mit externen Auftragnehmern zusammenzuarbeiten und sehr rigoros zu sein, hin zu einem viel agileren und iterativen Arbeitsablauf. Und das bedeutet zwei Dinge.

Erstens bedeutet es, dass es eine Mischung aus Top-Down-Anforderungsmanagement und Bottom-Up-Design gibt. Früher, als unsere Systeme noch weniger komplex waren, konnten wir alle unsere Anforderungen von der Missions- über die System- und Subsystem- bis hinunter zur Komponentenebene festlegen und mit diesen Annahmen richtig liegen. Aber da unsere Produkte viel komplexer geworden sind, ist das nicht mehr möglich, weil unsere Systeme jetzt so komplex und funktionsübergreifend sind, dass eine winzige Änderung in einem Team zu komplexen Änderungen in anderen Teams und anderen Organisationen führen kann, die wiederum komplexe Änderungen verursachen. Und in den meisten Fällen haben wir kein System dieses Ausmaßes oder dieser Komplexität entwickelt. Oftmals verstehen wir zu Beginn des Projekts die Systeminteraktionen zwischen Software und Hardware nicht vollständig. Und diese Dinge müssen im Laufe der Entwicklung verstanden werden.

Es ist also die Veränderung von Wasserfall zu agil. Wasserfall ist weitgehend von oben nach unten gesteuert und darauf ausgelegt, Veränderungen zu vermeiden. Agil bedeutet, dass wir in der Anfangsphase Annahmen über unsere Anforderungen haben, aber wir sind offen für Neues, denn Veränderungen sind unvermeidlich.

Und wir werden sicher nicht mit allen unseren technischen Annahmen richtig liegen, weil wir so etwas noch nie gebaut haben. Daher brechen agile Teams die Anforderungen nicht nur von der Missions- auf die System- oder Subsystemebene herunter, sondern sie lassen die Anforderungen von L0, L1 bis hinunter zu L3, L4, L5 fließen. Sie haben also eine vollständige Rückverfolgbarkeit von der Auftragsebene bis hinunter zu einer bestimmten Komponentenebene. Das ist die erste große Veränderung.

Die zweite große Veränderung ist die Erkenntnis, dass der iterative Ansatz der richtige Weg ist. Ein Bekannter aus meinem Netzwerk hat vor kurzem diese Geschichte erzählt, die besagt, dass es, wenn man ein Sechs-Zoll-Teleskop bauen will, in der Regel schneller ist, ein Drei-Zoll-Teleskop zu bauen und dann ein Sechs-Zoll-Teleskop zu bauen, als ein Sechs-Zoll-Teleskop sofort zu bauen.

Das ist eine wirklich gute Analogie. Die besten Teams der Welt beginnen nicht mit der kompliziertesten Version und versuchen, ihre Annahmen frühzeitig festzulegen. Vielmehr finden sie die kleinste Einheit eines integrierten Systems, die sie bauen können, um das Risiko zu verringern und aus ihren Annahmen zu lernen. Und dann fügen sie im Laufe der Zeit iterativ weitere Schichten hinzu, um sehr schnell lernen und entwickeln zu können.

Wenn ich das umformulieren darf: Du schlägst den aus der Software bekannten MVP-Ansatz vor, nur dass wir bei der Software das Produkt weiterentwickeln können, während Sie bei der Hardware ein zweites Teleskop bauen müssen. Aber die Idee ist dieselbe.

Genau. Dieser Ansatz klingt sehr verschwenderisch. Hardware-Ingenieure mögen das nicht, weil sie dreimal bauen müssen, statt nur einmal.

Aber wenn man sich Unternehmen wie SpaceX, Tesla und die am schnellsten wachsenden Unternehmen der Welt anschaut, sehen wir, dass dieser Ansatz viel effizienter ist als der traditionelle Ansatz. Wenn man zum Beispiel den Starliner von Boeing mit dem Dragon von SpaceX vergleicht, stellt man fest, dass der Dragon in der Hälfte der Zeit und mit der Hälfte der Kosten mehr erreicht hat. Sie haben mehrere Dragons gebaut, daraus gelernt und sie wieder verworfen. Dieser iterative Ansatz klingt langsamer und teurer. Aber in der Praxis hat sich gezeigt, dass es viel schneller, effizienter und sicherer ist, so zu arbeiten.

Dem kann ich nur zustimmen. Ich muss an die Starship-Testflüge denken: Was mich wirklich gestört hat, war die Schlagzeile, die ich neulich bei Tagesschau las: „Starship“-Testflug im vierten Versuch geglückt, was impliziert, dass die ersten drei nicht erfolgreich waren.

Wir brauchen wirklich einen Paradigmenwechsel, bei dem die Leute verstehen, dass eine explodierte Rakete (beim Testflug) kein Fehlschlag ist, sondern ein erfolgreicher Test, weil sie Daten geliefert hat. Wie können wir also diesen Paradigmenwechsel erreichen?

Das ist sehr schwierig. Der Schlüssel ist, sich nicht auf die Erfüllung der Anforderungen zu konzentrieren, sondern auf das Lernen. Dies ist eines der Dinge, die SpaceX immer wieder im Live-Stream für IFT-4 wiederholt hat. Sie sagten, die Nutzlast sind die Daten. Es geht nicht um den erfolgreichen Flug, es geht nicht darum, dass wir alle unsere Anforderungen erfüllen, es geht nicht darum, dass wir unsere V&V erfolgreich abschließen. Aber die Nutzlast sind die Daten.

Und wenn wir in der Lage sind, wirklich gute Daten aus dem Gefährt zu bekommen und seine genauen Grenzen zu verstehen, wo wir gut und wo wir schlecht abschneiden, dann können wir den IFT-5 oder die nächste Rakete viel schneller, viel besser und viel schneller entwickeln. Im Kern geht es also darum, sich auf das Lernen zu konzentrieren. Der nächste Schritt, der sich daraus ableitet, ist: Wie können wir so schnell wie möglich lernen?

Die zweite große Schwierigkeit für Systemingenieure besteht darin, aus dem „Land der Anforderungen, der Analyse und des Denkens“ herauszukommen und in das „Land des Handelns“ zu wechseln. Das ist ein sehr schwieriger Übergang für Systems Engineers. Ich kann das nachempfinden: Ich bin von Haus aus Maschinenbauingenieur. Ich habe meine gesamte frühe Karriere damit verbracht, analytische Modelle zu entwickeln, um Raketentriebwerke zu entwickeln. Aber man lernt sehr viel, wenn man einfach nur das kleinste Ding baut, es testet und dann das nächste und das nächste und das nächste baut. Und wenn man sich Apollo ansieht, dann ist das ein großer Teil dessen, was sie getan haben.

Die Ingenieure haben erkannt, dass sie zwar die Apollo-Missionen durchführen müssen, um zum Mond zu fliegen, aber dass sienicht direkt von „hier“ zur Mondlandung kommen werden. Bevor sie auf dem Mond landen können, müssen sie in eine Mondumlaufbahn. Dafür brauchen sie mehrere Raketenstufen. Vorher müssen sie in eine Erdumlaufbahn. Dazu müssen sie durch die Kármán-Linie, um in den Orbit zu kommen. Und der schnellste und billigste Weg, die Kármán-Linie zu überwinden, besteht darin, eine Rakete, wie es sie damals gab, mit einem Menschen an der Spitze zu bestücken und sie zu starten. Der schnellste Weg, um zu lernen, bestand darin, einen Menschen auf einer ICBM-Rakete nachzurüsten und dann so schnell wie möglich zu lernen. Und so sind wir zum Mond gekommen.

Ich stimme dem zu. Die Apollo-Ingenieure haben die Iterationen in dem Tempo durchgeführt, das mit der verfügbaren Technologie machbar war. Aber ich stimme nicht mit der Aussage überein, dass die Systems Engineers nicht von den Anforderungen abrücken wollen.

Ich glaube, es geht eher um die Angst der Entscheider, die meinen, dass eine explodierte Testrakete als Fehlschlag angesehen wird, was nicht der Fall ist. Also noch einmal: Wie können wir diesen Paradigmenwechsel vollziehen? Wie können wir mit den Entscheidern sprechen und ihnen ermöglichen, den Ingenieuren die Freiheit zu geben, agil zu arbeiten?

Lass mich Dir zwei oder drei Antworten geben und wieder etwas Kontext. Ich denke, der Kontext ist für unsere Branche wirklich wichtig: Wenn man sich nur den Stand heute ansieht, macht die Art und Weise, wie wir entwickeln, überhaupt keinen Sinn. Aber wenn man es im breiten Kontext der letzten 20 oder 30 Jahre betrachtet, wird plötzlich klar, warum wir so arbeiten wie wir arbeiten. Das Systems Engineering entstand aus den ersten öffentlich finanzierten Missionen, den Weltraummissionen. Das waren die Anfänge dessen, was ich echtes Systems Engineering nenne. Und das wird in der Regel vom Steuerzahler finanziert.

Es handelt sich in der Regel um eine Mission, die wir noch nie zuvor durchgeführt haben und die sehr, sehr schwierig ist. Und das ist das Ergebnis dieser beiden Dinge: Wenn der Kongress Geld zur Verfügung stellt, wenn Steuergelder in Missionen fließen, die sehr, sehr komplex sind, die viele Menschen beschäftigen. Dann gilt das Paradigma, dass man es beim ersten Mal richtig machen muss. Wenn ein Politiker 10 Milliarden Dollar oder eine Milliarde Dollar für diese große Mission ausgibt und sie scheitert, dann sieht das wirklich schlecht aus. Das ist der Ursprung des Systems Engineering Aber jetzt sehen wir, dass private Unternehmen all die Fehler der öffentlich finanzierten Missionen kopieren. Und das ist der Fehler. Der Fehler besteht darin, anzunehmen, dass die gleichen Regeln gelten wie für ein privates Unternehmen, das Geld verdienen und wirklich großartige, sichere und zuverlässige Produkte herstellen und sehr schnell vorankommen will. Das ist die grundlegende Veränderung, die wir verstehen und umsetzen müssen.

Das erklärt, warum Start-ups es geschafft haben, diese Ansätze zu übernehmen, und dass große bestehende Organisationen damit zu kämpfen haben. Hast Du eine Vorstellung, ob und wenn ja, wie bestehende große Organisationen diesen Wandel vollziehen können?

Wenn Du mir vor drei Jahren diese Frage gestellt hättest, hätte ich gesagt, das sei unmöglich. In der Wissenschaft gibt es ein großartiges Prinzip, das besagt, dass der Weg zu revolutionären Veränderungen darin besteht, die alten Menschen aussterben und die neue Generation heranwachsen zu lassen. Ich bin wirklich froh, dass ich in diesem Punkt eines Besseren belehrt worden bin.

Ich schaue mir also bestimmte Unternehmen wie Blue Origin an, die eigentlich mit einem viel traditionelleren, konservativen Modell begonnen haben. Sie haben viele Führungskräfte von Northrop Grumman und anderen traditionellen Luft- und Raumfahrtunternehmen eingestellt und sich diese Kultur zu eigen gemacht, was sie fast umgebracht hätte. Sie stellen derzeit auf einen agileren Ansatz um, und sie machen ihre Sache recht gut. Wir werden sehen, ob es funktioniert und ob eine solche Umstellung in einem Unternehmen mit 10.000 Mitarbeitern möglich ist.

Aber ich bin inzwischen vorsichtig optimistisch, was diese Veränderung angeht. Der einfachste und schnellste Weg, dies zu erreichen, ist der Aufbau eines Skunk Works Teams. Anstatt die bestehenden Leute und die bestehende Kultur zu nehmen und zu versuchen, eine neue Methode nachzurüsten, sollten wir ein neues Team mit einer neuen Mission aufbauen, um etwas Schwieriges zu tun, bei dem der einzige Weg agil ist. Und dann nehmen wir dieses Team und setzen es an verschiedenen Stellen in unserer Organisation ein, um auf diese Weise einen kulturellen Wandel herbeizuführen.

Kultureller Wandel geschieht durch eine Mischung aus „Bottom-up“, „Top-down“, Entscheidungsbefugnissen und — ehrlich gesagt — einem Auslöser. Und dieser Auslöser ist in der Regel ein Großbrand, etwas, das furchtbar schief gelaufen ist und uns dazu zwingt, unsere Prozesse neu zu bewerten. Und meine Sorge ist, dass wir auf viele Großbrände warten werden, bis sie passieren. Wenn ich mir Unternehmen wie Boeing anschaue, dann sehe ich, dass ein Brand nach dem anderen, ein Fehler nach dem anderen, ein Rückruf nach dem anderen diese Dinge verursacht. Und ich hoffe, dass wir einen Weg finden werden.

Ende von Teil 1

Der zweite und letzte Teil des Interviews wird am 11.08.2024 veröffentlicht (vor diesem Datum wird der Link nicht funktionieren). Wer vorher schon wissen möchte wie es weitergeht, kann sich das oben eingebettete Video anschauen oder das vollständige Interview hier auf Englisch lesen.

Michael Jastram

Creator and Author of SE-Trends