BLOGS
Warum MBSE-Deployment-Herausforderungen Engineering-Teams ausbremsen
Die meisten Unternehmen, die mit MBSE-Deployment-Herausforderungen kämpfen, haben kein Tool-Problem. Sie haben ein Problem nach dem Go-live. Die erste Phase eines MBSE-Rollouts ist relativ gut verstanden. Lizenzen werden beschafft, ein Tool wird installiert, eine Gruppe von Ingenieurinnen und Ingenieuren nimmt an Schulungen teil, und ein Pilotprojekt wird ausgewählt. Diese Phase hat einen klaren Endpunkt: Modelle existieren, das Tool funktioniert, die Anwender wissen, wie sie es nutzen sollen. Das Management zeichnet den Meilenstein ab und geht davon aus, dass die Einführung läuft. Was danach passiert, ist der Punkt, an dem viele Deployments unbemerkt ins Stocken geraten.
Die Lücke zwischen Go-live und tatsächlicher Adoption
Sechs Monate nach dem Go-live zeigt sich in Unternehmen, die die strukturellen Voraussetzungen für MBSE nicht geschaffen haben, häufig ein wiederkehrendes Muster. Modelle existieren, werden aber von den Ingenieurinnen und Ingenieuren gepflegt, die an der ursprünglichen Schulung teilgenommen haben — nicht vom breiteren Team. Das Pilotprojekt hat gute Ergebnisse geliefert, doch diese Ergebnisse haben sich nicht in der Art und Weise niedergeschlagen, wie nachfolgende Projekte strukturiert werden. Anforderungen liegen weiterhin in Dokumenten. Architekturentscheidungen werden weiterhin in PowerPoint kommuniziert. Das Modell wird aktualisiert, wenn jemand daran denkt.
Das ist kein Schulungsproblem. Es ist ein Prozessproblem — und eine der häufigsten Formen von MBSE-Deployment-Herausforderungen, mit denen Engineering-Organisationen konfrontiert sind.
Die Ursache liegt darin, dass MBSE-Schulungen Ingenieurinnen und Ingenieuren zeigen, wie sie ein Tool bedienen. Sie zeigen einer Organisation jedoch nicht, wie sie dieses Tool zum Zentrum ihres Engineering-Prozesses macht. Das sind zwei unterschiedliche Aufgaben — und nur eine davon wird durch eine klassische Implementierung abgedeckt.
Das Problem der Doppelbelastung
Eines der schädlichsten Muster in frühen MBSE-Deployments ist die sogenannte Doppelbelastung: Unternehmen führen modellbasiertes Engineering ein, ohne die dokumentenbasierten Prozesse zu ersetzen, die dadurch eigentlich abgelöst werden sollten.
Ingenieurinnen und Ingenieure sollen nun das SysML-Modell pflegen und gleichzeitig die traditionelle Dokumentation erstellen, die Kunden, Auditoren oder interne Stakeholder weiterhin erwarten. Das Modell wird zu einem zusätzlichen Artefakt statt zum führenden Artefakt. Teams, die ohnehin unter Termindruck stehen, treffen eine rationale Entscheidung: Sie pflegen das Artefakt, bei dem Fehler die unmittelbarsten Konsequenzen haben. In den meisten Unternehmen ist das nach wie vor das Dokument.
Das Modell driftet ab. Innerhalb weniger Monate bildet es nicht mehr den aktuellen Systemstand ab. Wenn ein neuer Engineer dem Team beitritt und das Modell nutzt, findet er Informationen, denen er nicht vertrauen kann. Der Wert des Modells bricht ein — nicht, weil MBSE nicht funktioniert, sondern weil die Organisation nie die Voraussetzungen dafür geschaffen hat, dass das Modell zur Single Source of Truth wird.
Die Pilotfalle
Ein gut durchgeführter MBSE-Pilot ist paradoxerweise einer der zuverlässigsten Wege, um eine breitere Einführung ins Stocken zu bringen. Das klingt zunächst widersprüchlich, der Mechanismus dahinter ist jedoch einfach.
Pilotprojekte funktionieren, weil sie von besonders motivierten Engineers durchgeführt werden, in einem Projekt mit unterstützender Führung, mit dedizierter Zeit und Support, den normale Projekte nicht erhalten. Wenn der Pilot erfolgreich ist, zieht das Management den Schluss, dass MBSE funktioniert. Wird der Ansatz anschließend auf ein zweites Projekt unter normalen Bedingungen übertragen — mit Engineers, die nicht Teil des Piloten waren, unter einem Programmmanager, der nicht beteiligt war, und ohne denselben dedizierten Support — entstehen nicht dieselben Ergebnisse.
Die Lücke zwischen der Leistung des Piloten und der Leistung im breiteren Programm ist keine Lücke in der Tool-Funktionalität. Es ist eine Lücke in der organisatorischen Infrastruktur, die den Pilot erst erfolgreich gemacht hat: klare Modellierungskonventionen, ein definierter Traceability-Ansatz, Engineers, die wissen, wie ein gutes Modell aussieht, und Führungskräfte, die das Modell als Engineering-Deliverable behandeln — nicht als Nebenaktivität.
Ohne diese Infrastruktur beginnt jedes nachfolgende Projekt wieder von vorn.
Was MBSE-Deployments ausbremst — und was nicht
Unternehmen, die ihre MBSE-Deployment-Herausforderungen richtig diagnostizieren, hören auf, das Problem im Tool zu suchen. Das Tool ist selten die Ursache. Die eigentlichen Faktoren, die Deployments ausbremsen, sind organisatorisch und strukturell:
Modellierungskonventionen, die nie über das Pilotteam hinaus standardisiert wurden, sodass jedes Projekt seinen eigenen Ansatz entwickelt und Modelle über Programme hinweg inkompatibel werden. Eine Traceability-Strategie, die zwar für den Pilot definiert, aber nie in einen Prozess überführt wurde, der Teamwechsel übersteht. Eine Integration mit bestehenden ALM-Tools, die nie vollständig umgesetzt wurde, sodass Engineers Verknüpfungen manuell pflegen müssen — und damit genau der Aufwand zurückkehrt, den MBSE eigentlich reduzieren sollte. Keine klare Verantwortung für das Modell als Engineering-Artefakt, sodass niemand formal dafür zuständig ist, es aktuell zu halten.
Keines dieser Probleme wird durch zusätzliche Schulungen gelöst. Sie werden gelöst, indem MBSE-Deployment als eigenes Engineering-Programm behandelt wird — mit definierten Ergebnissen, Governance und Verantwortlichkeit — und nicht als reine Softwareeinführung.
Der Sechs-Monats-Test
Sechs Monate nach dem Go-live ist ein sinnvoller diagnostischer Zeitpunkt. Die entscheidenden Fragen drehen sich nicht um das Tool:
Wird das Modell als Teil des normalen Engineering-Workflows aktualisiert oder nur dann, wenn jemand explizit Zeit dafür einplant? Wissen Engineers, die nicht an der ursprünglichen Schulung teilgenommen haben, wie sie das Modell lesen und dazu beitragen können? Wenn sich eine Anforderung ändert, wird die Auswirkung auf die Architektur aus dem Modell sichtbar — oder rekonstruiert sie jemand manuell? Würde ein neues Teammitglied das Modell in der ersten Woche als hilfreich empfinden, oder würde es stattdessen zu den Dokumenten greifen?
Wenn die ehrliche Antwort auf die meisten dieser Fragen vom Modell wegführt, ist das Deployment ins Stocken geraten — unabhängig davon, was die Tool-Metriken anzeigen.
Vom Deployment zur Engineering-Fähigkeit
Unternehmen, die die Sechs-Monats-Stagnation überwinden, tun dies nicht, indem sie Schulungen wiederholen oder Tools wechseln. Sie tun es, indem sie die Bedingungen schaffen, unter denen Modelle tatsächlich nützlich werden: standardisierte Konventionen über Projekte hinweg, ein Traceability-Ansatz, der Architektur und Anforderungen ohne manuelle Rekonstruktion verbindet, und eine Integration mit der ALM-Umgebung, damit das Modell keine Insel bleibt.
Das sind keine Funktionen des MBSE-Tools. Es sind Entscheidungen darüber, wie die Organisation das Tool nutzt — und genau darin liegt der Unterschied zwischen einem Deployment, das Modelle erzeugt, und einem Deployment, das echte Engineering-Fähigkeit schafft.
Was passiert nach dem MBSE-Go-live?
Erfahren Sie, wie eine Modellierungsumgebung rund um Modellierungspraxis, Traceability und Engineering-Workflows strukturiert werden kann — nicht nur rund um das Tool-Setup.
FAQ
Ein sinnvoller Prüfpunkt liegt etwa sechs Monate nach dem Go-live. Zu diesem Zeitpunkt ist der anfängliche Schulungseffekt abgeklungen, und es wird sichtbar, ob das Modell Teil der normalen Engineering-Arbeit geworden ist oder weiterhin als separate Aktivität gepflegt wird.
Ja, aber nur, wenn Dokumente möglichst aus dem Modell generiert oder mit dem Modell abgestimmt werden. Wenn Engineers sowohl das Modell als auch Dokumente manuell pflegen müssen, wird das Modell mit hoher Wahrscheinlichkeit veralten.
Ein Pilot zeigt, dass MBSE unter kontrollierten Bedingungen funktionieren kann. Ein skalierbares Deployment erfordert gemeinsame Modellierungskonventionen, klare Verantwortung, Traceability-Praktiken und Workflows, die über das ursprüngliche Pilotteam hinaus Bestand haben.
