In zwei Sätzen. Klassische FMEA- und Anforderungs-Methodik produziert in komplexen Systemen Dokumentenmengen, die niemand mehr liest — bei einem Defense-Stromerzeuger mit 400 Bauteilen und 13 Sichten sind das 5.200 Analysepunkte. OTSM reduziert das auf rund 450 projektspezifische Einträge, ohne Verlust an Audit-Tauglichkeit, und macht die heute übersehenen Risiken sichtbar.
1. Wo der Schmerz sitzt — was in der Organisation heute schiefläuft#
Drei Beobachtungen, die in fast jedem komplexen Engineering-Bereich gelten:
| Heute beobachtet | Reale Konsequenz |
|---|---|
| FMEA wächst auf 10.000+ Einträge | Niemand liest mehr — Pflege bindet Engineering-Zeit ohne Erkenntniswert |
| Bottom-up-FMEA übersieht laut MIT-Studie 27 % der Hazards | In Safety-Anwendungen: reale Sicherheitsrisiken |
| Lieferspezifikationen werden ständig nachgearbeitet | Verzögerungen, Ausschuss, Streit mit Lieferanten |
| Bei jeder Anforderungsänderung weiß niemand, was sonst betroffen ist | Fehler in der Tiefe, spät entdeckt, teuer korrigiert |
Quelle: Leveson/Thomas, MIT 2018; eigene Analyse aus 25 Jahren Engineering-Praxis in regulierten Industrien (Automotive, Aviation, Medical, Finance).
Keiner dieser Punkte ist ein Tool-Problem. Sie sind methodische Konsequenzen aus Annahmen, die seit den 1990er Jahren wissenschaftlich falsifiziert sind, aber durch ISO-Normen und Tool-Hersteller weitergetragen werden — teilweise gegen die ausdrücklichen Warnungen ihrer eigenen Autoren.
2. Der Prozess heute — und wo er kippt#
Die klassische Engineering-Kette läuft in jedem mittelständischen Unternehmen ungefähr so:
Lastenheft → Anforderungen → Architektur → FMEA → Konstruktion → Verifikation → Audit
Auf dem Papier ist das sauber. In der Praxis kippt der Prozess an drei Stellen:
Erstens, beim Lastenheft. Es wird einmal geschrieben, dann eingefroren, dann ignoriert — weil das Projekt sich weiterentwickelt und das Lastenheft nicht mit. Der Auditor liest die alte Fassung; der Ingenieur arbeitet mit der neuen.
Zweitens, bei der FMEA. Sie wird gepflegt, weil der Auditor sie sehen will. Sie informiert keine Designentscheidung mehr. Das ist Audit-Theater, nicht Risikoarbeit.
Drittens, bei der Verifikation. Tests werden auf Anforderungen abgebildet, nicht umgekehrt. Was nicht in der Anforderung steht, wird auch nicht getestet — selbst wenn es offensichtlich kritisch ist.
Das ist nicht böse Absicht. Das ist die ehrliche Antwort eines Engineering-Teams auf eine Methodik, die mit der Komplexität der Aufgabe nicht skaliert. Menschen kompensieren strukturelle Schwächen mit Erfahrung und informeller Kommunikation. Solange es geht. Bis es nicht mehr geht.
3. Die Methode — was OTSM anders macht#
OTSM stellt die fünf Pflichten in den Mittelpunkt, die in der klassischen Methodik implizit oder lückenhaft sind:
| # | Pflicht | Bedeutet konkret |
|---|---|---|
| 1 | Zweck | Für jedes System und jede Komponente — solution-free, mit benannten Adressaten |
| 2 | Idealzustand | Beschrieben und datiert — nicht „wir verbessern uns ständig” |
| 3 | Messmittelfähigkeit | Pro vitaler Größe: ist sie messbar — und wie? Telemetrie bevorzugt |
| 4 | Schwachpunkt sichtbar | Nicht Durchschnitte. Die schwächste Stelle ist die, die das System hält oder kippen lässt |
| 5 | Beweglichkeit gemessen | Reaktionszeit auf Veränderung — aufnehmen, anpassen, abschließen, jede Richtung gemessen |
Diese fünf Pflichten sind nicht zusätzlich zur klassischen Methodik. Sie sind die Vollform, von der die klassische Methodik immer nur Teile umgesetzt hat.
Methodische Verankerung: Die fünf Pflichten ruhen auf Quellen, die jeder Auditor akzeptiert — Leveson (MIT), Nuseibeh (Lero), Suh (MIT), Conway (1968), Reuleaux (1875), ISO 33071. Keine Esoterik. Stand der Technik, konsequent angewendet.
Das Zahlenbeispiel: Ein Defense-Stromerzeuger mit 400 Bauteilen und 13 fachlichen Sichten (EMV, Safety, ABC-Schutz, Wartung, …) ergibt nach klassischer FMEA-Methodik 13 × 400 = 5.200 Analysepunkte. OTSM behandelt die 13 Sichten als orthogonale Aspekte und nutzt eine Komponentenbibliothek — Ergebnis: rund 450 projektspezifische Einträge. Den Rest übernimmt das System.
Faktor 12 weniger Pflegeaufwand bei höherer Audit-Qualität. Das ist keine Marketing-Aussage. Es ist die mathematische Konsequenz aus konsequenter Methodik.
4. Das Tool — OTSM als Umsetzung der Methode#
Die OTSM-Software setzt die fünf Pflichten in Engineering-Praxis um. Drei Eigenschaften, die in keinem heutigen RE- oder FMEA-Tool gemeinsam vorhanden sind:
1. Ein Datensatz, viele Sichten. Anforderung, FMEA, Safety, EMV, Wartung sind unterschiedliche Sichten auf dieselben Objekte — keine getrennten Datenbestände. Eine Änderung am Bauteil ist sofort in allen Sichten sichtbar. Manuelle Synchronisation entfällt.
2. Komponentenbibliothek mit Standard-Charakteristik. Bekannte Komponenten kommen mit ihren Vital-Größen, Toleranzen, typischen Failure-Modes vorgepflegt. Im Projekt arbeitet der Ingenieur nur an den Abweichungen vom Standard. Das ist der Hebel von 5.200 → 450.
3. Vorschlags-Status — Human-in-the-Loop als Datenmodell-Eigenschaft. Was das System (oder eine KI-Komponente) vorschlägt, ist als vorgeschlagen markiert und zählt erst nach Bestätigung des Eigentümers. Der Ingenieur behält volle Kontrolle. Nichts läuft unbemerkt durch.
Daneben bleibt — und das ist für den Pilotbetrieb der entscheidende Punkt — die gewohnte Engineering-Sicht erhalten: Anforderungslisten, FMEA-Tabellen, Strukturbäume. Der Ingenieur arbeitet zuerst so, wie er es kennt. Die OTSM-Erweiterungen treten in den Vordergrund, wenn er sie braucht.
5. Was ein Pilot konkret aussieht#
Vorschlag für ein Pilotprojekt — 3 bis 6 Monate, klar abgegrenzt:
| Element | Konkret |
|---|---|
| Gegenstand | 1 Subsystem oder 1 Produktfamilie aus laufender Entwicklung |
| Umfang | Anforderungen + FMEA des Gegenstands, parallel in OTSM und in der heutigen Werkzeugkette |
| Messpunkte | Pflegeaufwand (Stunden/Monat), Anzahl entdeckter Lücken, Reaktionszeit auf Änderungen |
| Ausstieg | Jederzeit. Was im Pilot entstanden ist, bleibt nutzbar — auch außerhalb von OTSM |
| Aufwand auf Pilotkundenseite | 1 Engineering-Lead (~4h/Woche), gelegentliche Verfügbarkeit Fachexperten |
| Aufwand auf OTSM-Seite | Onboarding, methodische Begleitung, technischer Support — durch OTSM getragen |
Erwartete Ergebnisse nach 3 Monaten:
- Vergleichbare Datensätze in OTSM und klassischer Werkzeugkette
- Belegte Reduktion des Pflegeaufwands
- Liste der Risiken, die OTSM gefunden hat und die klassisch übersehen wurden
- Belastbare Entscheidungsgrundlage über eine Skalierung in andere Bereiche
6. Referenzen, Quellen, Person#
Methodische Quellen (Auswahl): Leveson, Engineering a Safer World, MIT Press 2012, Open Access · Nuseibeh, Weaving Together Requirements and Architectures, IEEE Computer 2001 · Suh, The Principles of Design, Oxford 1990 · Conway, How Do Committees Invent?, 1968 · ISO 33071 / Enterprise SPICE · de Geus, The Living Company · Hermann Simon, Hidden Champions.
Eigene Person: Thomas Arends, Gründer OTSM GmbH. 25 Jahre Engineering-Praxis in regulierten Industrien (Automotive, Aviation, Medical, Finance). Schwerpunkte Requirements Engineering, FMEA, Systems Engineering, Quality Management. Methodische Forschung an OTSM seit 2024, Software-Entwicklung seit Herbst 2025.
OTSM GmbH: Organisations-, Technologie- und Service-Management GmbH. Sitz Wernau (Baden-Württemberg). Kontakt: info@otsm.work · thomasarends.de
Der nächste Schritt: Ein Termin, in dem wir das Pilotprojekt auf Ihre konkrete Situation zuschneiden. Wenn die fünf Pflichten dort tragen, wo sie heute lückenhaft sind, ist der Pilot in 3 Monaten ausgewertet — und Sie haben eine belastbare Entscheidungsgrundlage, ohne strategisches Risiko.