BLOGS
Die versteckten Kosten manueller MBSE-ALM-Traceability
Die meisten Engineering-Organisationen wissen, dass manuelle MBSE-ALM-Traceability ineffizient ist. Was jedoch selten gemessen wird, ist die Tiefe dieser Ineffizienz – und wo sich die tatsächlichen Kosten aufbauen.
Die sichtbaren Kosten liegen in der Zeit: Ingenieure wechseln zwischen Tools, rekonstruieren Zusammenhänge manuell und dokumentieren ihre Ergebnisse. Die unsichtbaren Kosten sind schwerer zu erkennen, aber deutlich höher: Entscheidungen auf Basis unvollständiger Daten, Wissen, das in Köpfen statt in Systemen lebt, und hochqualifizierte Engineering-Kapazität, die durch Aufgaben gebunden wird, die kein Senior-Level erfordern sollten.
Arbeit, die niemand erfasst
In Organisationen, in denen MBSE- und ALM-Tools nur lose integriert sind, wird die Pflege der Traceability selten als eigene Aufgabe definiert. Stattdessen erledigen Ingenieure sie nebenbei – integriert in ihre tägliche Arbeit, ohne Zeiterfassung und ohne sie als Overhead zu erkennen.
Ein Architekt aktualisiert einen Block im MBSE-Modell. Bevor er fortfährt, öffnet er das ALM-Tool, prüft die verknüpften Anforderungen, bewertet die Auswirkungen der Änderung und aktualisiert die entsprechenden Artefakte manuell. Das dauert zwanzig Minuten. Es passiert dutzende Male pro Woche in einem Team von zehn Ingenieuren. Niemand erfasst dies als „Traceability-Pflege“. Es verschwindet im Projektaufwand.
Dieser unsichtbare Overhead ist die erste versteckte Kostenkomponente manueller MBSE-ALM-Traceability – und erscheint nahezu nie im Projekt-Reporting.
Das Problem der Senior Engineers
Die Navigation in manueller Traceability verteilt sich nicht gleichmäßig im Team. Sie konzentriert sich auf jene Ingenieure, die Architektur und Anforderungen gut genug verstehen, um Zusammenhänge ohne automatisierte Unterstützung zu rekonstruieren.
In den meisten Organisationen sind das die erfahrensten Mitarbeiter – Architekten und Senior Systems Engineers mit dem tiefsten Verständnis für das Gesamtsystem. Gleichzeitig sind sie die teuersten und am schwierigsten zu ersetzenden Ressourcen.
Wenn Senior Engineers einen erheblichen Teil ihrer Arbeitszeit damit verbringen, zwischen MBSE- und ALM-Tools zu wechseln, Auswirkungen manuell zu rekonstruieren und Traceability zu validieren, die eigentlich automatisch durch eine Integrationsschicht gepflegt werden sollte, entstehen kumulierte Kosten. Die Organisation bezahlt ihre Zeit direkt – und verliert zugleich die Entwurfs- und Verifikationsarbeit, die sie stattdessen leisten könnten.
Das ist die Opportunitätskosten-Komponente manueller MBSE-ALM-Traceability – und sie steigt mit dem Erfahrungsniveau. Je komplexer das System, desto stärker verlagert sich die Arbeit auf diejenigen, die am wenigsten Kapazität dafür haben.
Implizites Wissen als Traceability-Abhängigkeit
Manuelle Traceability-Navigation erfordert, dass Ingenieure ein mentales Modell des Systems aufrechterhalten – sie müssen wissen, welche Architekturelemente mit welchen Anforderungen verbunden sind, wie sich Änderungen auswirken und welche Verknüpfungen verlässlich oder veraltet sind.
Mit der Zeit wird dieses mentale Modell zu einem zentralen organisatorischen Asset – und zugleich zu einem erheblichen Risiko.
Wenn der Ingenieur, der dieses Modell trägt, das Team verlässt – sei es durch Kündigung, Versetzung oder Ruhestand –, verschwindet auch das Traceability-Wissen. Zurück bleiben Verknüpfungen, die niemand vollständig versteht, eine Änderungshistorie, die sich nicht mehr rekonstruieren lässt, und ein Impact-Analyse-Prozess, der davon abhängt, dass jemand das mentale Modell neu aufbaut.
Organisationen bezeichnen das selten als Traceability-Problem. Sie sprechen von Wissensverlust, Onboarding-Herausforderungen oder Dokumentationsdefiziten. Die Ursache bleibt jedoch dieselbe: Manuelle MBSE-ALM-Traceability speichert kritisches Engineering-Wissen in Menschen statt in Systemen.
Die Kosten von Entscheidungen auf Basis unvollständiger Daten
Die bisher beschriebenen Kosten – Zeit, Senior-Kapazität und Wissensrisiken – sind grundsätzlich messbar, auch wenn sie selten erfasst werden. Die nächste Kostenkategorie ist schwieriger zu quantifizieren, aber potenziell die gravierendste.
Wenn manuelle Traceability zu unvollständigen Impact-Analysen führt, treffen Ingenieure Entscheidungen auf Basis von Informationen, die korrekt erscheinen, es aber nicht sind. Änderungen werden freigegeben, ohne alle betroffenen Anforderungen zu identifizieren. Impact-Bewertungen werden abgeschlossen, obwohl nachgelagerte Effekte fehlen. In einigen Fällen werden Releases auf Grundlage von Traceability-Nachweisen zertifiziert, die nicht den tatsächlichen Systemzustand widerspiegeln.
Diese Entscheidungen wirken zum Zeitpunkt ihrer Entstehung plausibel. Die Traceability scheint sie zu stützen. Die Analyse wirkt vollständig. Das Problem zeigt sich später – bei der Verifikation, im Audit oder nach dem Release –, wenn Korrekturen deutlich teurer sind als zum Zeitpunkt der ursprünglichen Entscheidung.
Das ist die gefährlichste versteckte Kostenkomponente manueller MBSE-ALM-Traceability: nicht die verschwendete Zeit, sondern die erzeugte Scheinsicherheit. Unvollständige Traceability, die vollständig wirkt, führt zu schlechteren Ergebnissen als offensichtlich fehlerhafte Traceability – weil auf ihr basierend gehandelt wird.
Wie Komplexität die Kosten multipliziert
In einfachen Systemen mit stabiler Architektur und wenigen Anforderungen ist manuelle Traceability zwar aufwendig, aber beherrschbar. Die Kosten sind real, aber begrenzbar.
Mit zunehmender Systemkomplexität steigen die Kosten nicht linear – sie multiplizieren sich. Zusätzliche Varianten schaffen neue Konfigurationskontexte, in denen jede Verknüpfung gültig bleiben muss. Release-Baselines fügen weitere Ebenen hinzu, die manuell gepflegt werden müssen. Architekturelle Refaktorierungen erhöhen wiederum die Anzahl der Verknüpfungen, die Ingenieure prüfen, validieren und aktualisieren müssen.
Am stärksten betroffen sind Organisationen mit variantenreichen Produktfamilien, langen Entwicklungszyklen und regulatorischen Zertifizierungsanforderungen. In solchen Umgebungen erzeugt manuelle MBSE-ALM-Traceability nicht nur Overhead – sie wird zum Engpass, der bestimmt, wie schnell Änderungen umgesetzt, zertifiziert und ausgeliefert werden können.
Was Organisationen messen – und was tatsächlich kostet
Engineering-Organisationen messen zuverlässig das, was ihre Tools liefern. Sie verfolgen Kennzahlen wie Requirement Coverage, Anzahl der Links und Vollständigkeit von Traceability-Matrizen. Diese Werte wirken beruhigend und suggerieren Kontrolle.
Was sie nicht messen, ist schwerer zu erfassen – aber wesentlich entscheidender:
1. Engineering-Zeit, die in die manuelle Pflege dieser Kennzahlen fließt und unsichtbar in Projektplänen verschwindet
2. Entscheidungen, die auf Traceability-Daten basieren, die zum Zeitpunkt der Entscheidung unvollständig waren
3. Wissen, das mit ausscheidenden Mitarbeitern verloren geht und Verknüpfungen hinterlässt, die niemand vollständig versteht
4. Verzögerungen in der Zertifizierung durch spät erkannte Traceability-Lücken – zu einem Zeitpunkt, an dem Korrekturen am teuersten sind
Die Differenz zwischen dem, was Organisationen messen, und dem, was sie tatsächlich kostet, ist der Raum, in dem die versteckten Kosten manueller MBSE-ALM-Traceability entstehen. Und sie bleiben bestehen, weil sie in keinem Reporting sichtbar werden.
Vom Overhead zur Engineering-Fähigkeit
Organisationen, die ihre Abhängigkeit von manueller MBSE-ALM-Traceability reduzieren, sparen nicht nur Zeit – sie verändern die Art der Arbeit grundlegend.
Wenn eine Integrationsschicht Traceability automatisch pflegt, verändert sich die Arbeitsweise im gesamten Team:
1. Änderungen im MBSE-Modell lösen automatisch Impact-Analysen aus – Ingenieure bewerten Ergebnisse, statt sie zu rekonstruieren
2. Impact-Analysen decken den gesamten Architekturgraphen ab, nicht nur die im ALM sichtbaren Verknüpfungen
3. Verknüpfungen bleiben konfigurations- und baseline-spezifisch gültig – veraltete Traceability wird sichtbar, statt unbemerkt zu bleiben
4. Traceability-Wissen wird von Personen in Systeme verlagert, bleibt erhalten und skaliert mit der Systemkomplexität
Es geht nicht darum, Engineering-Urteilsvermögen zu ersetzen. Es geht darum sicherzustellen, dass dieses Urteilsvermögen auf korrekten, vollständigen und aktuellen Informationen basiert – und nicht auf einer manuell rekonstruierten Annäherung.
Traceability, die funktioniert
Reduzieren Sie manuelle MBSE-ALM-Traceability durch eine gesteuerte Integration:
FAQ
Weil Ingenieure die Lücke zwischen zwei Tools manuell überbrücken müssen, die Engineering-Wissen unterschiedlich abbilden. Ein MBSE-Tool verwaltet Architektur als vernetzten Graphen, ein ALM-Tool als flache Liste von Artefakten. Ohne eine gesteuerte Integrationsschicht müssen Menschen die Beziehungen rekonstruieren – und der Zeitaufwand verteilt sich unsichtbar im gesamten Team.
Neben der reinen Engineering-Zeit entstehen versteckte Kosten durch die Bindung erfahrener Ingenieure an administrative Tätigkeiten, durch Wissen, das in Personen statt in Systemen gespeichert wird, sowie durch Entscheidungen auf Basis scheinbar vollständiger, tatsächlich aber unvollständiger Daten. Organisationen messen Link-Anzahlen und Coverage – aber selten die Kosten ihrer Pflege.
Auditoren verlangen den Nachweis, dass jede Anforderungsänderung bewertet und jede architektonische Auswirkung analysiert wurde. Bei manueller Traceability müssen Teams diese Nachweise aus Erinnerungen und Meeting-Notizen rekonstruieren – was den Audit-Aufwand erhöht und das Risiko von Abweichungen steigert.
Dann, wenn Systemkomplexität und Release-Druck zusammenkommen. In einfachen Systemen bleibt sie beherrschbar. Mit wachsender Variantenvielfalt und steigenden Zertifizierungsanforderungen steigen die Kosten überproportional – und entweder wächst das Team mit oder die Release-Geschwindigkeit sinkt.
