Zum Hauptinhalt springen

·19 min
Thomas Arends
Autor
Thomas Arends
Management Consulting, Interim-, Projekt-, Qualitätsmanagement
Inhaltsverzeichnis

Lebensfähigkeits-orientiertes Engineering und Organisation
#

Eine Methode für Firmen, Behörden und alles, was einen Zweck hat
#

Methodenbeschreibung — Fassung für alle, die mit der Methode arbeiten sollen. Geschäftsführer, Konstrukteure, HR-Leute, Politiker, Lehrer. Wo es genauer wird, gibt es eine Vertiefungs-Box für Methodiker.

Stand: Mai 2026 Autor: Thomas Arends, OTSM1 GmbH


Inhaltsverzeichnis
#

  1. Erst die Geschichten — zwei Beispiele, damit klar wird, worum es geht
  2. Worum es geht (in einem Satz)
  3. Lebensfähigkeit — was das heißt
  4. Die fünf Pflichten — was jeder einhalten muss
  5. Wie das Werkzeug dahinter aussieht
  6. Was sich verändert, wenn man so arbeitet
  7. Was die Methode nicht kann
  8. Wo die Idee herkommt
  9. Wer mitmachen kann

1. Erst die Geschichten
#

Bevor ich erkläre, was die Methode ist, zeige ich zwei Geschichten. An ihnen wird klar, was die Methode tut. Wir kommen später immer wieder auf sie zurück.

Geschichte 1 — Die Bremsen-Firma
#

Stell dir eine Mittelstandsfirma vor. Sie baut Bremsen für Autos. Sie hat 200 Mitarbeiter, gute Kunden, läuft seit 40 Jahren.

Eines Morgens kündigt der Chef-Bremsen-Entwickler. Er ist 58, will in Rente. Er hat als einziger das Wissen, wie das schwierigste Bauteil funktioniert. Niemand sonst kann es so gut.

Die Geschäftsführerin fragt:

  • Wer kann ihn ersetzen?
  • Wie gut sind die zwei Nachfolger wirklich?
  • Was wissen wir über sie — und was glauben wir nur?
  • Was ist, wenn beide auch noch kündigen?
  • Welche Funktion in unserer Bremse hängt eigentlich an diesem einen Mann?

Diese Fragen sind heute schwer zu beantworten. Die Antworten stehen in fünf verschiedenen Programmen: HR-System, Schulungs-Datenbank, Org- Plan, Kompetenz-Excel, Mitarbeiter-Gespräch-Akte. Jedes hat seinen Stand. Sie passen nicht zusammen.

Wir kommen nachher auf diese Geschichte zurück.

Geschichte 2 — Das Bremsen-Bauteil
#

In derselben Firma. Ein Konstrukteur entwickelt ein neues Bauteil für die Bremse. Er muss dafür:

  • Anforderungen aufschreiben (in einem Programm)
  • Eine Risikoanalyse machen (in einem zweiten)
  • Die Architektur zeichnen (in einem dritten)
  • Eine Spezifikation für die Hardware schreiben (in einem vierten)
  • Tests planen (in einem fünften)
  • Kundenwünsche bearbeiten, die per E-Mail kommen (in einem sechsten)

Wenn der Kunde sagt: „Können wir die Bremse auch ohne giftige Kabel- Beschichtung haben?" — wo trägt er das ein? Und wer merkt, dass diese neue Anforderung die Risikoanalyse, die Architektur und die Spezifikation gleichzeitig betrifft?

Die Antwort heute: niemand. Drei Wochen später entdeckt jemand zufällig, dass die Spezifikation noch die alte Beschichtung verlangt. Dann wird hektisch nachgepflegt.

Wir kommen auch auf diese Geschichte zurück.


2. Worum es geht (in einem Satz)
#

Beide Geschichten beschreiben dasselbe Problem. Die Methode löst es einmal — für beide.

Wer eine Firma führt, ein Bauteil entwickelt, eine Behörde leitet oder eine Stadt verwaltet, hat immer das gleiche Problem:

  • Es gibt einen Zweck — wofür mache ich das eigentlich?
  • Es gibt einen Soll-Zustand — wie müsste es sein, damit der Zweck erreicht wird?
  • Es gibt eine Realität — wie ist es tatsächlich?
  • Es gibt einen Unterschied zwischen Soll und Ist — wo ist die Lücke?
  • Und die Welt um mich herum verändert sich — wie schnell merke ich, wenn etwas wandert, und wie schnell reagiere ich?

Bisher hat jedes Fachgebiet — Anforderungs-Engineering2, HR, Politik, Strategie — sein eigenes Werkzeug, seine eigene Sprache, sein eigenes Programm. Obwohl das Problem dahinter dasselbe ist.

Die hier vorgestellte Methode geht das Problem einmal an. Sie funktioniert für Bremsen genauso wie für Bremsen-Entwickler. Für Bauteile genauso wie für ganze Behörden.

Für Methodiker — kurz und scharf

Diese Methode behandelt Engineering, Strategie-Management, Organisations-Pflege, Politik und Biologie als verschiedene Sichten auf ein gemeinsames Strukturproblem: zweckgerichtete Systeme in veränderlichen Umgebungen. Sie operationalisiert über ein gemeinsames Datenmodell (fünf Block-Klassen, ein Trace, Modus-Achse), ein gemeinsames Pflicht-System (fünf Pflichten) und ein gemeinsames Eingangs-Format (aggregierte Drift-Signale). Sie löst die methodische Trennung der genannten Disziplinen strukturell auf, ohne ihre fachlichen Eigenheiten zu verwerfen — diese werden zu Render-Sichten über dem gemeinsamen Modell.


3. Lebensfähigkeit — was das heißt
#

Lebensfähigkeit heißt: Etwas funktioniert weiter. Auch wenn sich die Welt drumherum ändert.

Ein Lebewesen ist lebensfähig, wenn es überlebt. Eine Firma ist lebensfähig, wenn sie ihre Kunden weiter glücklich macht. Eine Behörde ist lebensfähig, wenn sie ihre Bürger weiter versorgt.

Aber: Lebensfähigkeit hat immer einen Bezug. Es geht nicht um „lebensfähig irgendwie", sondern:

  • Für wen? Wer hat etwas davon, dass das System lebt? (Kunde, Patient, Bürger.)
  • Wofür? Was soll das System leisten?
  • In welcher Welt? Welche Umgebung soll es überleben? (Markt, Klima, Gesetze, Konkurrenz.)

Wer eines dieser drei vergisst, hat keine Lebensfähigkeit-Aussage. Er hat eine Behauptung.

Vital-Größen — die Lebenszeichen
#

Beim Arzt misst man Puls, Atmung, Blutdruck, Temperatur. Das sind die Vital-Größen eines Menschen. Vier Zahlen, jede einzeln messbar. Aus allen vier zusammen sieht der Arzt, ob es dem Menschen gut geht.

Bei einer Firma, einem Bauteil, einer Behörde ist das genauso. Es gibt Vital-Größen. Sie messen, ob das System lebensfähig ist.

Wichtig: Eine Vital-Größe ist nur dann eine Vital-Größe, wenn:

  1. Sie wirklich gemessen werden kann (nicht geschätzt).
  2. Sie zeigt, ob der Zweck erfüllt wird (nicht irgendwas anderes).
  3. Wer das System macht (Anbieter), misst das, was für den Adressaten wichtig ist — nicht das, was für ihn selbst wichtig ist.

Beispiel aus der Bremsen-Firma:

Sieht aus wie eine Vital-Größe — ist aber keineIst eine echte Vital-Größe
„Wir bauen 50.000 Bremsen pro Jahr"„Unsere Bremsen halten ein Autoleben lang — 95% sind nach 250.000 km noch sicher"
„Unser Umsatz ist 38 Millionen Euro"„Unsere Kunden bestellen wieder — Wiederbestell-Quote 87%"

Die ersten messen den Anbieter. Die zweiten messen den Nutzen für den Kunden. Der Unterschied ist riesig.

Für Methodiker

Lebensfähigkeit ist ein Beziehungs-Begriff über (System × Zweck × Adressaten × Umgebung). Eine Lebensfähigkeits-Aussage ohne alle vier Bezüge ist methodisch leer. Lebensfähigkeit ersetzt nicht CMMI-Reife (die misst Prozess-Vorhersagbarkeit); beide Begriffe sind unabhängig und können koexistieren.

Vital-Größen sind messmittelfähige Einzelmessungen mit Zweck-Verankerung am Adressaten. Anbieter-zentrierte Messungen (Umsatz, Stückzahl, Wahlerfolg) sind Pseudo-Vital-Größen. Sie können geführt werden, zählen aber nicht in die Lebensfähigkeits-Bewertung.


4. Die fünf Pflichten
#

Damit eine Aussage über die Lebensfähigkeit ehrlich ist, müssen fünf Bedingungen erfüllt sein. Wir nennen sie die fünf Pflichten.

Die erste Pflicht ist die wichtigste. Wenn sie nicht erfüllt ist, sind alle anderen wertlos. Sie ist wie der Schlüssel zur Haustür — ohne ihn nützen die anderen Schlüssel nichts.

Pflicht 1 — Sag klar, wofür und für wen
#

Wofür macht ihr das eigentlich? Und für wen?

Klingt einfach. Ist es nicht.

Das Problem mit der „Lösung statt Zweck"

Ein Beispiel, das jeder kennt: Kodak. Die Firma, die jahrzehntelang fotografische Filme verkauft hat. Was haben sie geglaubt, dass ihr Zweck ist?

  • „Wir entwickeln und verkaufen Filme."

Das war der Tod. Denn als die Digitalkameras kamen, wollte niemand mehr Filme. Kodak hatte den Zweck an die Lösung gebunden. Lösung weg — Firma weg.

Was wäre der richtige Zweck gewesen?

  • „Wir helfen Menschen, Bilder festzuhalten."

Mit diesem Zweck wäre Kodak zur Digitalkamera-Firma geworden. Oder zur Foto-App-Firma. Oder zur Cloud-Foto-Firma. Die Lösung darf wechseln. Der Zweck bleibt.

Das Problem „Wer ist der Kunde?"

Wer den Zweck nennt, muss auch sagen, für wen.

Ein Krankenhaus existiert nicht für die Ärzte. Es existiert für die Patienten. Wenn das Krankenhaus seine Erfolge an Behandlungs-Fällen pro Quartal misst (gut für den Anbieter), aber nicht an Heilungs-Quoten (gut für den Patienten), hat es seinen Zweck verloren.

Anwendung auf die Bremsen-Firma:

Wofür macht die Firma das?

  • ❌ „Wir bauen Bremsen." (Lösung statt Zweck. Was, wenn Autos mit Magnetschwebe bremsen werden?)
  • ✅ „Wir helfen Auto-Herstellern, dass ihre Autos sicher zum Stehen kommen — auf jeder Straße, bei jedem Wetter."

Für wen?

  • ❌ „Für unsere Auto-Hersteller-Kunden." (Halb richtig.)
  • ✅ „Für die Auto-Hersteller, weil ihre Endkunden — die Autofahrer und ihre Familien — sicher ankommen müssen."
Für Methodiker

Pflicht 1 ist Eintritts-Pflicht. Wenn sie nicht erfüllt ist, sind Pflichten 2–5 nicht prüfbar. Sie kommentieren nur das Symptom.

Lösungs-Bindung verletzt Pflicht 1, weil der Zweck mit der Lösung stirbt. Adressaten-Vergessen verletzt Pflicht 1, weil die Vital-Größen aus Anbieter-Sicht definiert werden und damit Pseudo werden.

Umfassende Zweck-Formulierung verlangt, dass scheinbare Konflikte (Patientennutzen vs. Rendite) als Hinweis auf zu enge Definition aufgelöst werden, nicht als echte Konflikte behandelt werden.

Pflicht 2 — Sag, wie es sein sollte, und schreib das Datum dazu
#

Wie sollte das System sein, damit es seinen Zweck erfüllt? Und wann hast du das zuletzt gegen die Realität geprüft?

Wer sagt „unsere Bremsen müssen sicher sein", hat noch nichts gesagt. Sicher ist kein Soll-Zustand. Das ist ein Wort.

Ein Soll-Zustand ist konkret:

  • Die Bremse muss bei trockener Straße einen Bremsweg von höchstens 40 Meter aus 100 km/h schaffen, mit voll beladenem Auto.
  • Die Bremse muss 10 Jahre und 250.000 Kilometer ohne sicherheits- relevanten Ausfall halten.
  • Die Bremse muss bei nasser Straße ABS-fähig sein.

Und — entscheidend — der Soll-Zustand bekommt ein Datum. „Geprüft am 15. März 2026." Warum? Weil sich die Welt ändert. Vielleicht kommt 2027 eine neue EU-Vorschrift, die einen kürzeren Bremsweg verlangt. Vielleicht kommt 2028 eine neue Bremsen-Technologie der Konkurrenz.

Der Soll-Zustand muss regelmäßig gegen die Welt geprüft werden. Sonst arbeitet man auf einen veralteten Plan hin.

Anwendung auf die Bremsen-Firma:

Der Chef-Bremsen-Entwickler kennt den Soll-Zustand auswendig. Aber er geht in Rente. Wo steht er aufgeschrieben? Hat ihn jemand 2026 gegen die EU-Vorschriften von 2026 geprüft, oder steht da noch der Stand von 2019?

Das ist Pflicht 2. Soll-Zustand aufschreiben, datieren, regelmäßig prüfen.

Pflicht 3 — Miss richtig
#

Was du misst, muss wirklich messbar sein. Und es muss zeigen, ob der Zweck erfüllt wird.

Klingt selbstverständlich. Ist es nicht.

Beispiel — eine Pseudo-Messung:

Eine Firma misst die „Kommunikationsstärke" ihrer Führungskräfte. Wert: 7,3 von 10.

Frage: Wie wurde das gemessen?

Antwort: Der Vorgesetzte hat eine Note vergeben.

Frage: Wie groß ist die Wahrscheinlichkeit, dass ein anderer Vorgesetzter dieselbe Note geben würde?

Antwort: Hmm. Kommt auf den Vorgesetzten an.

Das ist keine Messung. Das ist ein Eindruck mit einer Zahl daneben.

Die einfache Regel:

Wenn zwei Leute dasselbe prüfen sollen und unterschiedliche Ergebnisse herauskommen, ist es keine Messung. Es ist eine Meinung.

Methodiker3 nennen das Übereinstimmungsquote. Sie sagen: zwei Prüfer müssen in mindestens 70% der Fälle gleich urteilen, damit es als Messung gilt4. Sonst ist es zu unzuverlässig.

Bevorzugung der Maschinen-Messung:

Eine Maschine misst immer gleich. Zwei Menschen messen oft unterschiedlich. Deshalb: wo möglich, Maschinen-Messung statt Menschen-Bewertung.

  • Wieviele Bremsweg-Tests hat der Konstrukteur bestanden? → aus dem Test-System ablesbar. Maschinen-Messung. ✅
  • Wie kreativ ist der Konstrukteur? → Bauchgefühl. Kein zuverlässiges Maß. ❌

Anwendung auf die Bremsen-Firma:

Die Firma misst heute „Führungserfahrung in Jahren". Ja, das ist messbar. Aber misst es, dass die Person ein guter Bremsen-Entwickler ist? Nein. 12 Jahre Führungserfahrung sagen nichts darüber aus, ob jemand das schwierige Bauteil entwickeln kann.

Das ist eine Pseudo-Messung. Sie wird abgeschafft oder ersetzt durch:

  • Wieviele Bremsen-Entwicklungen hat die Person erfolgreich abgeschlossen (= Bremse ist im Markt, hält die Vorschriften, keine sicherheits- relevanten Rückrufe)? → echte Messung, am Zweck verankert.

Die Zahlen-ohne-Kontext-Falle:

Wenn jemand sagt „die Stromkosten sind um 20% gestiegen" — was sagt das? Nichts. Es fehlt:

  • Verglichen womit? (Vorjahr? Vor 5 Jahren?)
  • Wessen Kosten? (Privathaushalt? Industrie?)
  • Welche Region?
  • Welcher Stromtyp?

Eine Zahl ohne Bezug ist nicht messbar. Sie ist eine Behauptung mit Ziffern. Wir nennen das das Relativitäts-Problem: Zahlen ohne Kontext sind keine Information, sondern Propaganda-fähig.

Für Methodiker

Pflicht 3 verlangt drei Eigenschaften pro Vital-Größe:

  1. Messverfahren mit Inter-Rater-Reliabilität ≥ 0,7 (Cohen’s Kappa oder ICC) bei beobachtungs-basierten Messungen.
  2. Verankerung am Zweck-Block (vital_purpose_anchor) und Formulierung aus Adressaten-Sicht.
  3. Beleg der Messmittelfähigkeit (measurement_evidence_url).

Telemetrie-basierte Messungen (measurement_method = 'telemetry') sind per Definition messmittelfähig. Beobachtungs- und umfrage-basierte Messungen (observation, survey) brauchen den IRR-Nachweis. Calculation und Inspection sind messmittelfähig, wenn das Verfahren definiert ist.

Vital-Größen, die nicht alle drei Eigenschaften erfüllen, werden als Pseudo-Vital-Größen markiert (is_vital_metric = TRUE, aber mit Warn-Status). Sie erscheinen nicht im Lebensfähigkeits-Bericht.

Pflicht 4 — Zeig die Schwachstelle, nicht den Durchschnitt
#

Ein System ist nur so stark wie sein schwächstes wichtiges Teil. Durchschnittswerte verstecken die Schwachstelle.

Beispiel — eine Kette mit 10 Gliedern. Neun davon halten 1000 kg, eines hält nur 100 kg.

  • Durchschnitt: 910 kg.
  • Wahrheit: die Kette reißt bei 100 kg.

Wer mit dem Durchschnitt arbeitet, baut auf den Boden, der nicht trägt.

Anwendung auf die Bremsen-Firma:

Die Firma hat 4 Bremsen-Entwickler. Drei sind sehr gut. Einer ist der Chef-Entwickler, der das schwierige Bauteil macht. Er geht in Rente.

  • Durchschnitt der Bremsen-Kompetenz: 80% (gut!)
  • Wahrheit: das schwierige Bauteil hängt an einem Mann. Sobald er weg ist, fehlt die Kompetenz.

Wer mit Durchschnitten arbeitet, sieht das Risiko nicht. Wer die Schwachstelle sichtbar macht, sieht es sofort: „Hier hängt die ganze Bremsen-Entwicklung an einer Person ohne Nachfolger."

Pflicht 4 verlangt: die Schwachstelle wird sichtbar, immer. Durchschnitte darf man rechnen — aber sie sind nicht die Lebensfähigkeits-Aussage.

Anwendung aufs Bremsen-Bauteil:

Der Konstrukteur misst zehn Eigenschaften der Bremse. Neun sind im grünen Bereich. Eine — die Drift unter Temperatur — ist kritisch.

Wenn der FMEA5-Bericht den Durchschnitt zeigt, sehen alle: alles gut. Wenn er die Schwachstelle zeigt, sieht jeder: hier muss gearbeitet werden. Pflicht 4.

Pflicht 5 — Miss, wie schnell ihr reagiert
#

Wenn sich etwas ändert — wie schnell merkt ihr das? Und wie schnell reagiert ihr?

Die Welt verändert sich ständig. Neue Vorschriften, neue Konkurrenten, neue Kundenwünsche, neue Technologien. Eine Firma, die einmal einen guten Plan macht und ihn dann 10 Jahre nicht anpasst, ist tot.

Lebensfähigkeit verlangt Beweglichkeit. Und Beweglichkeit kann man messen.

Wie?

Bei jeder Veränderung in der Welt zählt man zwei Zeitpunkte:

  • Wann wurde die Veränderung erkannt? (Tag X)
  • Wann wurde reagiert? (Tag Y)

Die Differenz Y − X ist die Reaktionszeit. Man kann sie als Zahl ausweisen. Man kann sehen, ob sie sich verbessert oder verschlechtert.

Anwendung auf die Bremsen-Firma:

Eine neue EU-Norm zur Bremswirkung bei nasser Fahrbahn wird im März veröffentlicht. Die Bremsen-Firma erfährt es Anfang April. Wann ist die Bremse angepasst?

  • Schlecht: in zwei Jahren. (Reaktionszeit: 24 Monate.)
  • Gut: in drei Monaten. (Reaktionszeit: 3 Monate.)

Wer die Reaktionszeit nicht misst, behauptet nur, beweglich zu sein. Wer sie misst, sieht die Wahrheit.

Die Aufmerksamkeits-Falle:

Vorsicht: Reaktionszeit auf aufsehenerregende Veränderungen ist oft schnell. Reaktionszeit auf schleichende Veränderungen ist oft langsam.

  • Beispiel: Ein dramatischer Unfall passiert. Innerhalb einer Woche reagiert die Politik. Schnell!
  • Beispiel: Die Kundenstruktur wandert über fünf Jahre langsam in eine andere Branche. Niemand merkt es. Schlecht!

Pflicht 5 verlangt: beide werden gleich behandelt. Wer nur auf laute Signale reagiert, sieht die wirklich gefährlichen, weil leisen, Veränderungen nicht.

Für Methodiker

Pflicht 5 verlangt drei Zeit-Größen als Vital-Größen:

  1. Heutige Lage (Status-Snapshot)
  2. Aktualität des Idealzustands (Tage seit letzter Prüfung gegen Umgebung)
  3. Reaktionszeit auf Drift-Signale (Differenz zwischen Eingang und Block-Anpassung, Median über rollierendes Zeitfenster)

Asymmetrie in der Reaktion auf spektakuläre vs. graduelle Drift-Signale ist Anti-Pattern. Das Erfassungs-System muss beide gleich behandeln; sonst entsteht systematische Blindheit für die wirklich gefährlichen, weil unauffälligen Verschiebungen.


5. Wie das Werkzeug dahinter aussieht
#

Die fünf Pflichten sind die Regeln. Damit eine Firma sie einhalten kann, braucht sie ein Werkzeug.

Das Werkzeug ist im Kern erstaunlich einfach: Bausteine, Verbindungen, zwei Zustände.

Die Bausteine
#

Alles, was in einer Firma, einem Bauteil, einer Behörde wichtig ist, lässt sich in fünf Sorten von Bausteinen einordnen:

BausteinWas er beantwortetBeispiele
ZielWofür? Für wen?„Sichere Autos für Autofahrer"
FunktionWas tut es?„Bremsmoment erzeugen"
LösungWomit ist es gemacht?„Scheibenbremse aus Stahl" — oder „Bremsen-Abteilung mit 20 Leuten"
MerkmalWie wird es gemessen?„Bremsweg ≤ 40 m"
KontextWann gilt es?„bei trockener Straße, 100 km/h, volle Beladung"

Diese fünf Bausteine reichen. Mehr braucht es nicht. Egal ob man ein Bauteil beschreibt, eine Rolle in der Firma, eine Behörde, ein Gesetz.

Die Verbindungen
#

Die Bausteine sind nicht isoliert. Sie hängen zusammen.

Eine Funktion verfeinert ein Ziel. Eine Lösung realisiert eine Funktion. Ein Merkmal misst eine Funktion. Ein Kontext gilt für eine Funktion.

Diese Zusammenhänge werden über Verbindungen abgebildet. Eine Verbindung sagt: Baustein A hängt mit Baustein B zusammen, und so eng.

Die zwei Zustände
#

Jeder Baustein lebt in zwei Zuständen:

  • Lebendig: der aktuelle Stand. Er kann sich ändern. Hat ein Datum der letzten Anpassung.
  • Eingefroren: ein Schnappschuss zu einem bestimmten Zeitpunkt. Zum Beispiel: was im Vertrag mit dem Kunden steht. Was das EU-Gesetz vorschreibt. Was der Koalitionsvertrag festgelegt hat.

Beide Zustände sind gleichzeitig im Werkzeug. Der Unterschied zwischen beiden ist sichtbar — „hier ist die Welt heute, hier ist, was der Vertrag vor zwei Jahren verlangt hat, hier ist die Lücke."

Wie der Anwender das erlebt
#

Der Konstrukteur, der HR-Mitarbeiter, der Geschäftsführer arbeitet nicht mit den Bausteinen direkt. Er sieht das Werkzeug in seiner Sprache:

  • Der Konstrukteur sieht Anforderungen, Funktionen, Komponenten, Tests — wie er es gewohnt ist.
  • Der HR-Mitarbeiter sieht Standorte, Abteilungen, Rollen, Mitarbeiter, Kompetenzen — wie er es gewohnt ist.
  • Der Geschäftsführer sieht ein Lebensfähigkeits-Dashboard mit den fünf Pflichten — kompakt.

Im Hintergrund: alles dieselben fünf Bausteine. Aber jeder arbeitet in seiner Sprache.

Bild: das hier passiert in jeder OTSM-Sicht. Mockup-Bilder „otsm-ui-engineering.html" und „otsm-ui-organisation.html" zeigen, wie der Bildschirm aussieht.

Die Drift-Signale
#

Damit Pflicht 5 (Beweglichkeit) funktioniert, braucht das Werkzeug eine Inbox für Veränderungs-Hinweise. Wir nennen diese Hinweise Drift-Signale.

Drift-Signale kommen aus vier Quellen:

  1. Menschen. Jemand sieht etwas und meldet es per Ein-Klick. „Mir ist aufgefallen, dass die Bremsen bei der Variante A öfter reklamiert werden."
  2. Maschinen. Eine Maschine in der Produktion misst, dass etwas driftet. Eine IT-Anlage merkt Schwellwert-Überschreitungen.
  3. Markt. Ein Kunde schreibt eine E-Mail mit einem Wunsch. Eine neue EU-Vorschrift wird veröffentlicht. Die Konkurrenz bringt ein neues Produkt.
  4. Assistent. Ein KI-Assistent fasst Daten zusammen und schlägt vor, wo etwas getan werden müsste.

Die Inbox wird täglich oder wöchentlich vom Verantwortlichen geprüft. Er bestätigt, lehnt ab, oder ordnet anders zu. Daraus werden Anpassungen am Datenmodell. Reaktionszeit wird automatisch gemessen — vom Eingang des Drift-Signals bis zur Anpassung.

Was nicht doppelt gepflegt wird
#

Das Werkzeug erzeugt aus dem gleichen Datenmodell alle nötigen Dokumente. Lastenheft, Pflichtenheft, FMEA-Formblatt, Architektur- Beschreibung, Org-Chart, Rollen-Profil, Schulungs-Übersicht, Audit- Bericht — alles gerenderte Sichten6 aus dem gleichen Modell.

Niemand pflegt eine Anforderung drei Mal in drei verschiedenen Programmen. Niemand erklärt einer Excel-Tabelle, dass sie veraltet ist. Niemand verzweifelt am Synchronisieren.

Bild: SVG „vergleich-engineering.svg" und „vergleich-organisation.svg" zeigen visuell, was heute getrennt geführt wird und was mit dieser Methode in einem Modell aufgeht.


6. Was sich verändert, wenn man so arbeitet
#

Drei Veränderungen, die der Anwender direkt merkt.

Veränderung 1 — Keine Doppelarbeit mehr
#

Heute schreibt der Konstrukteur eine Anforderung in DOORS7, überträgt sie nach APIS8 für die FMEA, kopiert sie in Word für das Pflichtenheft, und trägt das Ticket dazu in Jira9 ein. Vier Programme, vier Datenstände, alle bisschen anders.

Mit der Methode: er trägt es einmal ein. Alle vier Sichten generieren sich automatisch daraus.

Veränderung 2 — Echte Schwachstellen werden sichtbar
#

Heute verstecken Durchschnitts-Werte die echten Probleme. Der Bremsen- Bauplan-Bericht zeigt 95% Fertigstellung — und übersieht, dass Brandschutz nur zu 40% fertig ist.

Mit der Methode: die Schwachstellen stehen oben in der Liste. Was nicht funktioniert, ist sichtbar. Das ist unbequem, aber ehrlich.

Veränderung 3 — Beweglichkeit wird messbar
#

Heute behauptet jede Firma, beweglich zu sein. „Wir reagieren schnell auf Marktveränderungen." Niemand kann es belegen.

Mit der Methode: Reaktionszeit pro Veränderung in Tagen. Trend pro Quartal. Vergleich Abteilung zu Abteilung. Wer schnell ist, sieht es — wer langsam ist, auch.

Eine ehrliche Warnung
#

Diese Klarheit ist nicht für jeden willkommen. Wer in seiner heutigen Rolle davon profitiert, dass Doppelpflege Arbeitsplätze sichert, dass Durchschnitte Schwachstellen verstecken, dass „wir sind beweglich" eine ungeprüfte Behauptung bleibt — der wird die Methode unangenehm finden.

Das ist ein Merkmal, kein Fehler. Ehrlichkeit ist das, was die Methode liefert. Wer sie nicht will, soll bei alten Werkzeugen bleiben.


7. Was die Methode nicht kann
#

Damit niemand sich falsche Hoffnungen macht:

  • Sie ersetzt keine Fachkenntnis. Wer keinen guten Bremsen-Ingenieur hat, baut auch mit dieser Methode keine gute Bremse.
  • Sie verhindert keine schlechten Entscheidungen. Wer einen falschen Zweck definiert, bekommt nur schneller schöne Zahlen für den falschen Zweck.
  • Sie nimmt keine Entscheidungen ab. Sie macht Lücken sichtbar. Ob die Lücke geschlossen wird, entscheidet der Mensch.
  • Sie braucht Mess-Disziplin. Wer nicht ehrlich misst, sondern sich selbst belügt, kommt mit der Methode auch nicht weiter.
  • Sie braucht ein gutes Erfassungs-System. Drift-Signale müssen aggregiert ankommen — nicht roh und überwältigend.
  • Sie kann niemanden zwingen. Wer die Information ignoriert, die die Methode liefert, hat eine bewusste Entscheidung gegen die eigene Lebensfähigkeit getroffen. Das ist sein Recht.

8. Wo die Idee herkommt
#

Die Methode ist keine Neuerfindung. Sie ist eine Synthese aus vielen publizierten Arbeiten:

  • Royce (1970): beschrieb in einem berühmten Aufsatz nicht das Wasserfall-Modell, sondern dessen Gegenteil — die ständige Rückkopplung. Wurde von der Industrie falsch zitiert.
  • Beer (1972): beschrieb das Viable System Model — eine Strukturtheorie lebensfähiger Organisationen. Sehr klug, nie als Werkzeug umgesetzt.
  • Senge (1990): beschrieb die Lernende Organisation als Haltung.
  • Conway (1968): stellte fest, dass Firmen ihre Produkte so bauen, wie sie selbst organisiert sind. Conway’s Law. Heute noch wahr.
  • Nuseibeh (2001): beschrieb die Twin-Peaks-Erkenntnis10.
  • Leveson (2012): entwickelte STAMP/STPA11 als systemtheoretischen Sicherheits-Ansatz.

Was diese Methode hinzufügt: ein gemeinsames Datenmodell, ein Pflicht- System, eine operative Umsetzung. Die alten Arbeiten waren richtig. Aber sie wurden nie in ein Werkzeug überführt, das ein Mittelständler kaufen und benutzen kann. Genau das ändert sich jetzt.


9. Wer mitmachen kann
#

Die Methode ist frei verfügbar. Wer sie nutzen will, darf das. Was wir uns wünschen: Rückmeldung. Kritik. Wo trägt sie? Wo bricht sie? Wo muss sie geschärft werden?

Das Werkzeug (OTSM) ist ein kommerzielles Produkt. Wer es einsetzen will, kann ein Pilot-Gespräch anfragen.

Was wir nicht wollen: schweigende Adaption. Wenn die Methode dir hilft, sag es. Wenn sie nicht funktioniert, sag das auch — gerade das hilft.

Kontakt: info@otsm.work


Schluss
#

Die zwei Geschichten vom Anfang — die kündigende Bremsen-Entwicklerin und der Konstrukteur mit den sechs Programmen — sind keine Sondertheorien. Sie beschreiben das normale Arbeitsleben in vielen Firmen. Sie sind unangenehm, weil sie zeigen, dass viel Energie an der falschen Stelle verbrannt wird.

Die Methode löst das Problem. Nicht in einem Aufwasch — aber Schritt für Schritt. Wer anfängt, merkt nach wenigen Wochen, dass etwas anders ist. Wer dranbleibt, merkt nach einem Jahr, dass die Firma anders funktioniert.

Wir sind gerade dabei. Es lohnt sich.


Autor: Thomas Arends, Wernau

Lizenz: Methode frei verwendbar unter Namensnennung. Werkzeug- Implementierung kommerziell. Kritik und Beiträge willkommen.

Stand: Mai 2026


  1. OTSM = Organisations-, Technologie- und Service-Management. Die Firma, die diese Methode entwickelt und das passende Werkzeug dazu baut. ↩︎

  2. Anforderungs-Engineering = die Disziplin, die in Firmen aufschreibt, was ein Produkt können soll. Heißt im Englischen „Requirements Engineering". Wird meist mit eigenen Programmen wie DOORS oder Polarion gemacht. ↩︎

  3. Methodiker = Menschen, die sich beruflich damit beschäftigen, wie man Dinge richtig misst und bewertet. Statistiker, Wissenschaftler, Qualitätsmanager. ↩︎

  4. Der Fachbegriff dafür ist „Inter-Rater-Reliabilität", gemessen mit Verfahren wie Cohen’s Kappa oder dem Intraclass-Correlation-Coefficient (ICC). Schwellwert ≥ 0,7 ist Standard. ↩︎

  5. FMEA = Failure Mode and Effects Analysis. Eine standardisierte Methode in der Industrie, um Risiken in Produkten zu erkennen und zu bewerten. Wird oft mit Excel oder Spezial-Software wie APIS gemacht. ↩︎

  6. Render-Sicht = ein Dokument, das aus den Daten generiert wird, wenn man es braucht. Nicht selbst gespeichert. Wenn die Daten sich ändern, ändert sich auch das Dokument automatisch. ↩︎

  7. DOORS = ein Programm für Anforderungs-Management, sehr verbreitet in der Automobil- und Luftfahrt-Industrie. ↩︎

  8. APIS IQ-FMEA = ein Spezial-Programm zum Erstellen von FMEA-Tabellen. ↩︎

  9. Jira = ein Programm zur Bug- und Aufgaben-Verwaltung in Software-Entwicklung. ↩︎

  10. Twin Peaks = die Erkenntnis, dass Anforderungen und Architektur in Wahrheit zusammen entwickelt werden, nicht nacheinander. Das klassische Wasserfall-Modell verleugnet das. ↩︎

  11. STAMP = Systems-Theoretic Accident Model and Processes. Ein neueres Modell, um Unfälle und Sicherheits-Probleme aus systemischer Sicht zu betrachten. ↩︎