Die unbequeme Frage
~1.600 Stunden pro Jahr. Das ist, was ein 10-köpfiges Engineering-Team typischerweise mit Arbeit verbrennt, die niemand wirklich braucht: UML-Diagramme, die zwei Wochen nach ihrer Erstellung veraltet sind. SysML-Modelle, die als zweite Wahrheit neben den eigentlichen Spezifikationen leben. Tool-Synchronisation zwischen ALM-System, Issue-Tracker und Teamsinternem Wiki.
Die Frage ist nicht, ob man Systems Engineering macht. Die Frage ist: Wo ist der Aufwand gerechtfertigt — und wo ist er teurer Leerlauf?
Für mittelständische Unternehmen ohne eigene Systems-Engineering-Abteilung und ohne Pflicht zur ASIL-C/D-Zertifizierung ist das keine akademische Frage. Es ist eine Frage der Wettbewerbsfähigkeit.
Was wirklich hilft — und was Overhead ist
Eine ehrliche Bestandsaufnahme für den Mittelstand:
- Requirements Engineering bottom-up: ja. Wer Anforderungen strukturiert erfasst, bevor er baut, spart in der Fehlerkorrektur das Vierfache. Das gilt auch ohne ISO 26262.
- FMEA integriert statt Excel-Silo: ja. Eine FMEA, die direkt an Funktionen und Merkmalen hängt, ist kein Dokumentationsprojekt — sie ist ein Qualitätswerkzeug. Im Excel-Silo ist sie beides nicht.
- Traceability automatisch statt manuell: ja. Rückverfolgbarkeit von der Kundenanforderung bis zum Testfall ist dann wertvoll, wenn sie nicht 3 Stunden pro Woche manueller Pflege kostet.
- UML ohne Codegenerierung: der teuerste Zeichenblock der Welt. Klassendiagramme und Sequenzdiagramme, die niemand liest und die beim nächsten Refactoring falsch sind. Wenn kein Code generiert wird, ist UML dekoratives Engineering.
- SysML ohne ASIL-C/D-Pflicht: eine 100.000-Euro-Lösung für ein 10.000-Euro-Problem. SysML ist mächtig und komplex. Für Unternehmen ohne regulatorische Pflicht zur formalen Systemmodellierung ist die Lernkurve der größte Kostentreiber.
- System Context Diagram als Pflichtdokument: wird einmal erstellt und nie wieder angeschaut. In Audits gezeigt, im Alltag ignoriert. Ein Werkzeug, das nur für den Auditor existiert, kostet nur.
Die OTSM-Antwort
OTSM beantwortet die Frage nicht mit einer Checkliste, welche SE-Methoden man anwenden soll. Die Antwort ist struktureller Natur:
Eine einzige Datenkette — Merkmale → Funktionen → Anforderungen → Tests — ersetzt den Tool-Zoo. Jede Entität wird einmal erfasst. Keine manuelle Synchronisation. Keine zweite Wahrheit.
- Work Once, Use Many: Eine Funktion, die in der FMEA erfasst wird, ist dieselbe Funktion wie die in der Anforderungsliste. Keine manuelle Übertragung, kein Versionskonflikt.
- Kein Tool-Zoo: Anforderungs-Tool, FMEA-Tool, Architektur-Tool, Testmanagement-Tool — jedes mit eigener Datenstruktur und eigenen Begriffen. OTSM fasst alle vier Perspektiven in einer Datenstruktur zusammen.
- Overhead ist wählbar: Wer UML-Diagramme will, kann sie exportieren. Wer SysML-konforme Ausgaben für Audits braucht, bekommt sie. Aber die Arbeit entsteht in einer Struktur, nicht in einem Diagramm-Tool.
Die Frage ist nicht, ob man Systems Engineering macht. Die Frage ist, ob man es so macht, dass die Arbeit auch morgen noch stimmt — ohne sie zweimal zu erledigen.
OTSM GmbH · Thomas Arends · 2026 · CC BY 4.0