Wir rocken Engineering

In der Folge geht es um die Frage, wie MBSE dazu genutzt werden kann, Entwicklungsprojekte besser zu strukturieren und Entscheidungen wirksamer vorzubereiten. Der Gastgeber ordnet die Episode als Gespräch über „Modellierung zur Entscheidungsfähigkeit“ ein und beschreibt, dass Modelle nicht Selbstzweck sein sollen, sondern konkrete Projektfragen beantworten helfen. Zu Gast ist Bastian Ribbers. Er schildert seinen Weg vom Studium der Konstruktion und Entwicklung über die Arbeit in der Konstruktion bis hin zur Beratung im Bereich Systems Engineering und MBSE. Dort unterstützt er Kunden dabei, Produktentwicklung strategisch und effizient zu organisieren und Projekte besser steuerbar zu machen. Ein Schwerpunkt des Gesprächs ist die Kritik an MBSE, wenn Modelle vor allem vollständig und detailliert aufgebaut werden, ohne dass klar ist, welche Entscheidung damit unterstützt werden soll. Ribbers betont, dass Modelle gezielt auf Fragestellungen ausgerichtet sein sollten, statt nur Dokumente in anderer Form zu ersetzen. Wichtig sei, die jeweils benötigte Evidenz für eine Entscheidung früh zu identifizieren. Daran anknüpfend erklärt er, dass man Entscheidungspunkte entlang von Meilensteinen oder Review Gates vorbereiten kann. Dafür werden konkrete Entscheidungsfragen abgeleitet, Informationsbedarfe definiert und festgelegt, wie diese nachgewiesen und bewertet werden sollen. So lasse sich erkennen, welche Daten, Analysen oder Nachweise noch fehlen. Ein weiterer Punkt ist der Umgang mit Risiken und Alternativen. Ribbers beschreibt, dass frühzeitig mitgedacht werden sollte, was geschieht, wenn eine Entscheidung noch nicht getroffen werden kann. Auch Alternativen, zum Beispiel unterschiedliche Technologien, sollen systematisch verglichen werden. Zum Schluss erläutert er sein Verständnis von MBSE: Entscheidend sei nicht ein einziges großes Modell, sondern die strukturierte und verknüpfbare Aufbereitung von Informationen über verschiedene Modelle und Werkzeuge hinweg. Der praktische Nutzen liege darin, Projekte zielgerichtet zu steuern, ohne sich in Formalität oder Modellierung zu verlieren.

In dieser Episode sprechen wir über SysML V2, Git und die Frage, wie sich die textuelle Notation bei der Versionsverwaltung verhält. Wir ordnen zunächst ein, was Git als Versionsverwaltungssystem leistet und warum Branches, Commits und Merges besonders wichtig sind. Wir erklären dann, dass SysML V2 nicht nur aus Text besteht, sondern ein zugrunde liegendes Modell mit verschiedenen Views hat. Die textuelle und die grafische Darstellung sind dabei zwei gleichwertige Ansichten auf dasselbe Modell und nicht das Modell selbst. Ein Schwerpunkt liegt auf den unerwarteten Herausforderungen beim Arbeiten mit textueller SysML-V2-Notation in Git. Wenn Elemente, Referenzen oder Abhängigkeiten geändert werden, erkennt ein textbasierter Merge nicht ohne Weiteres, welche inhaltlichen Auswirkungen das auf andere Teile des Modells hat. Wir diskutieren außerdem, dass zwar Editoren Syntax und Semantik prüfen können, Git beim Zusammenführen aber nur auf Textebene arbeitet. Dadurch kann ein automatischer Merge als erfolgreich erscheinen, obwohl das Modell später im Tool inkonsistent ist. Zum Schluss sprechen wir über mögliche Umgangsweisen. Wir betonen die Notwendigkeit von Awareness, einer Modell-zentrierten Sicht auf Diff und Merge sowie zusätzlicher Tool-Unterstützung, damit bei SysML V2 nicht nur Text, sondern das Modell als Ganzes berücksichtigt wird.

Prozesse schaffen Orientierung Prozesse sind wichtig. Sie zeigen, wie Arbeitsschritte ineinandergreifen und wer wofür verantwortlich ist. Sie machen Schnittstellen sichtbar und helfen Teams, mit einer verlässlichen Grundlage weiterzuarbeiten. Auch Freigaben gehören dazu. Sie schaffen Klarheit darüber, wann ein Arbeitsergebnis geprüft und bereit für den nächsten Schritt ist. So behalten alle den Überblick – und unfertige Ergebnisse geraten nicht unkontrolliert in Umlauf. Klare Abläufe können außerdem dabei helfen, Automatisierungspotenziale zu erkennen. Wenn Eingaben und Arbeitsschritte verlässlich feststehen, lässt sich besser beurteilen, welche Aufgaben automatisiert werden können – und ob künstliche Intelligenz dabei sinnvoll unterstützen kann. Prozesse dürfen Projekte nicht ausbremsen Genauso wichtig ist aber die Frage, ob jeder Prozessschritt in jedem Projekt wirklich notwendig ist. Bringt dieser Schritt einen Mehrwert? Muss das Ergebnis überhaupt erstellt werden? Oder lässt sich das Ziel auf einem anderen Weg besser erreichen? Nicht jeder Prozess passt unverändert zu jeder Situation. Manchmal braucht es zusätzliche Schritte. Manchmal lassen sich Schritte weglassen, die im konkreten Projekt keinen Nutzen bringen. Für mich bedeutet gutes Prozessdenken deshalb nicht, Regeln blind zu befolgen. Es bedeutet, Abläufe ernst zu nehmen und sie regelmäßig auf ihre Wirkung zu prüfen. Prozesse sollen Orientierung geben – und dabei helfen, gute Ergebnisse effizient zu erreichen.

In dieser Episode spreche ich mit Benjamin Zimmer über den Digital Thread im Systems Engineering. Wir klären, was sich hinter dem Begriff verbirgt und wie Unternehmen Entwicklungsdaten, Anforderungen, Tests, Hardware- und Softwareinformationen durchgängig miteinander verknüpfen können. Dabei geht es unter anderem um bessere Traceability, effektiveres Change Management und schnellere Impact-Analysen. Benjamin zeigt, welchen praktischen Nutzen ein Digital Thread bei Änderungen, Kundenproblemen sowie der Verifizierung und Validierung bietet. Außerdem sprechen wir darüber, warum Unternehmen nicht mit einem riesigen Digitalisierungsprojekt starten sollten. Stattdessen empfehle ich, zunächst ein konkretes Problem und einen überschaubaren Use Case auszuwählen. So lassen sich erste Erfolge sichtbar machen und Schritt für Schritt weitere Bereiche einbinden.

In dieser Episode spreche ich über die fünf häufigsten Hörerfragen zu KI im Ingenieurbüro. Ich erkläre, wie ich KI-Assistenten für die Erstellung von Lastenheften eingesetzt haben und welche Schritte mein Prozess umfasst: erfassen, sortieren, füllen, prüfen und freigeben. Außerdem beschreibe ich, wie ich die Assistenten konfiguriert haben. Dabei nutze ich keine eigene Modelltrainierung, sondern gebe per Prompt vor, wie die Assistenten mit den Quellen umgehen sollen, was sie tun dürfen und was nicht. Ziel ist, Halluzinationen zu vermeiden und sich an die vorliegenden Dokumente zu halten. Dann gehe ich auf das Ausgabeformat ein. Ich erzeuge Markdown-Dateien, stelle sie in Obsidian dar und exportieren sie bei Bedarf als PDF. Zusätzlich erwähne ich, dass auch ein Transfer in CSV oder künftig direkt in eine SysMLv2-Spezifikation möglich sein könnte. Ein weiterer Schwerpunkt ist der Einsatz von KI bei der Bewertung und Weiterentwicklung von Lastenheften. Ich sehe KI nicht als Ersatz, sondern als Unterstützung beim Finden von Informationen, Lücken und Parallelen. Für die Weiterentwicklung zu Pflichtenheften betone ich, dass neben dem Lastenheft auch eine grobe Systemarchitektur und vorhandene Dokumentation eingebracht werden können, die Ergebnisse aber immer menschlich geprüft werden müssen.