Drei Traces. Immer. — Ein Baum, den Sie pflegen, zwei Netze, die Sie verschweigen

Egal ob Sie ein Fahrzeug entwickeln, eine FMEA moderieren, ein SysML-Modell bauen, eine Organisation führen oder ein ISMS betreiben: Ihr System hat drei Traces. Die meisten Unternehmen dokumentieren genau einen — und wundern sich dann über den Rückruf, den Audit-Befund oder das Chaos nach der Reorganisation.

Trace 1 ist ein Baum, weil wir Bäume brauchen. Trace 2 und Trace 3 sind Netze, weil die Welt eines ist. Wer nur Trace 1 dokumentiert, dokumentiert seine Ablage — nicht sein System.

Trace 1 — Die Zerlegung: der Baum, den Sie pflegen

Der erste Trace ist der bekannteste, und er ist in jedem Werkzeug derselbe: Sie zerlegen. Ein System wird in Systemelemente geschnitten — Baugruppen und Module im Engineering, Abteilungen und Rollen in der Organisation, Kapitel und Controls in der Compliance. Jedes Element bekommt seine Funktionen, jede Funktion ihre Merkmale: Kennwerte, Toleranzen, Messgrößen. Decompose, bis unten Zahlen stehen.

Dieser Trace ist unverzichtbar — und er ist eine Verwaltungsentscheidung. Ein Mensch hat entschieden, wo geschnitten wird, und Menschen schneiden so, dass jeder Knoten genau einen Vater hat. Nur so bleibt das Ganze navigierbar, delegierbar, budgetierbar. Das Ergebnis ist zwangsläufig ein Baum. Die Stückliste ist ein Baum. Das Orgchart ist ein Baum. Das Normkapitel ist ein Baum. Das SysML-Blockdiagramm, so wie es meistens gepflegt wird: ein Baum.

Das Problem ist nicht der Baum. Das Problem ist der stille Wahrheitsanspruch, der sich an ihn heftet — die Annahme, die Abhängigkeiten des Systems verliefen entlang seiner Äste. Sie tun es nicht. Die Realität hat den Baum nie unterschrieben.

Trace 2 — Der Fehlertrace: das Netz, das die Realität zeichnet

Der zweite Trace läuft in die Gegenrichtung, und ihn zeichnet nicht der Mensch, sondern die Physik. Ein Fehler auf Ebene n — an einem Merkmal, an einer Funktion — erzeugt einen bis n Fehler auf der Ebene darüber. Diese Folgefehler können alle unter einer einzigen Funktion liegen. Sie können unter zehn Funktionen liegen. Und diese zehn Funktionen können in zehn verschiedenen Ästen des Zerlegungsbaums hängen.

Man nennt das Ergebnis traditionell Fehlerbaum. Das Wort ist eine Untertreibung mit Methode: Ein Baum verzweigt nach unten und bleibt sortiert. Der reale Fehlertrace fächert nach oben auf, kreuzt Astgrenzen und verbindet Knoten, zwischen denen im Zerlegungsbaum keinerlei Kante existiert. Es ist ein Netz — und dass es eines ist, ist keine Unsauberkeit der Analyse, sondern die zentrale Information. Dasselbe gilt für State Machines: Der Fehler eines Übergangs propagiert in Zustände und Übergänge, die im Zustandsdiagramm weit auseinanderliegen.

Der Fehlertrace ist der einzige der drei Traces, der empirisch ist. Er folgt keiner Ordnungsidee. Er folgt Wirkketten. Deshalb widerspricht er dem Zerlegungsbaum systematisch — und zwar genau an den Stellen, an denen die Zerlegung die Realität für die Verwaltbarkeit verbogen hat.

Trace 3 — Das Funktionsnetz: die tatsächliche Architektur

Und hier passiert das Entscheidende. Wenn ein Fehler einer untergeordneten Funktion Funktionen auf der Ebene darüber beeinträchtigt, dann hat er etwas bewiesen, was kein Workshop und kein Architekturdiagramm zuverlässig liefert: eine tatsächliche funktionale Abhängigkeit. Die obere Funktion hängt an der unteren — nachweislich, denn genau dort ist die Wirkkette entlanggelaufen.

Der dritte Trace ist also kein drittes Diagramm, das jemand zusätzlich zeichnen müsste. Er ist die Projektion des Fehlernetzes auf die Funktionsebene: Der Funktionslink entsteht durch den Fehlerlink — nicht umgekehrt. Fragt man Ingenieure oder Führungskräfte direkt nach den Abhängigkeiten ihrer Funktionen, zeichnen sie den Zerlegungsbaum noch einmal ab. Fragt man sie, was kaputtgeht, wenn dieses eine Merkmal kippt, zeichnen sie — ohne es zu merken — die echte Architektur.

Trace 1 behauptet Abhängigkeiten. Trace 2 beweist sie. Trace 3 ist das, was übrig bleibt, wenn man die Behauptung gegen den Beweis tauscht.

Severity fließt zurück — über dasselbe Netz

Die drei Traces bilden eine geschlossene Mechanik: Struktur fließt runter, Fehler fließen hoch — und die Bedeutung fließt über dasselbe Netz wieder herunter. Die Severity einer Fehlerfolge wird top-down vererbt (AIAG-VDA lässt hier keinen Spielraum): Nur wer die Fehlerkette vom Kundenerlebnis bis zum Merkmal durchgezogen hat, weiß, welcher Kennwert in der Fertigung wirklich kritisch ist — und welcher nur teuer überwacht wird, weil er im Baum weit oben hängt.

Das ist der praktische Grund, warum Trace 2 und 3 gepflegt werden müssen und nicht nur bekannt sein: Ohne das Netz gibt es keinen Pfad, über den Kritikalität bis zum Merkmal durchgereicht werden kann. Man priorisiert dann nach Bauchgefühl — oder nach Baumposition, was dasselbe ist.

Wo das Netz den Baum kreuzt, entsteht eine Schnittstelle — und jede Schnittstelle braucht einen Vertrag

Aus dem enthüllten Funktionsnetz fällt eine zweite Erkenntnis heraus, fast beiläufig: Überall dort, wo eine Netz-Kante eine Grenze des Zerlegungsbaums kreuzt — eine Baugruppengrenze, eine Abteilungsgrenze, eine Firmengrenze —, liegt eine Schnittstelle. Nicht, weil jemand sie definiert hätte, sondern weil zwei Verantwortungsbereiche nachweislich funktional aneinanderhängen.

Und Schnittstellen zwischen zwei Eigentümern brauchen Verträge — das ist Conway, konsequent zu Ende gedacht. Die Form des Vertrags wechselt mit der Domäne, die Mechanik nicht: Schließe ich mechanisch an einen Lieferanten an, heißt der Vertrag Zeichnung plus Toleranz- und Sauberkeitsvereinbarung. Schließe ich softwareseitig an ein Fremdsystem an, heißt er API-Kontrakt. Schließe ich organisatorisch an eine andere Abteilung an, heißt er Datenvertrag, Prozessvereinbarung, SLA. Wer sein Funktionsnetz nicht kennt, kennt seine Schnittstellen nicht — und wer seine Schnittstellen nicht kennt, hat Verträge, die niemand geschlossen hat, aber alle brauchen.

Beispiel Produkt: Ein Partikel, drei Äste

Ein Partikel im Inneren einer Batteriezelle ist, im Zerlegungsbaum betrachtet, ein winziger Merkmalsfehler: ein verletzter Partikelgrenzwert, irgendwo unten. Im Fehlernetz ist derselbe Partikel ein Großereignis. Er kann jede Kurzschlussart treffen — Anode gegen Kathode, Separatordurchdringung, Ableiter gegen Gegenelektrode, den Dendrit-Keim, der erst nach Monaten zündet. Das sind mehrere Fehler unter einer einzigen Funktion („internen Kurzschluss vermeiden"). Gleichzeitig schlägt er auf die Technische Sauberkeit der Fertigungsumgebung durch und auf den Fügeprozess der Montage — zwei weitere Funktionen, zwei andere Äste des Baums.

Ein Fehler, drei Äste, ein Netz. Wie real diese Mechanik ist, zeigt der Fall aus „Acht Kurzschlüsse, ein Rückruf, kein Zufall": Acht scheinbar unabhängige Kurzschluss-Ereignisse, die im Baum in verschiedenen Zweigen abgelegt worden wären — und im Netz eine gemeinsame Wurzel haben.

Beispiel Organisation: Ein Datensatz, vier Abteilungen

Dieselbe Mechanik, andere Domäne. Trace 1 ist hier das Orgchart: Geschäftsführung, darunter Einkauf, Logistik, Produktion, Finanzen, darunter Rollen, darunter deren Funktionen und Kennwerte. Sauber, einväterig, delegierbar.

Jetzt der Fehler auf Merkmalsebene: ein fehlerhafter Lieferanten-Stammdatensatz, verantwortet von einer Rolle im Einkauf. Im Orgchart ein lokales Problem einer Abteilung. Im Fehlernetz: Die Bestellung geht verzögert oder an die falsche Adresse (Einkauf). Der Wareneingang kann die Lieferung nicht zuordnen, die Ware landet im Sperrlager (Logistik). Der Fertigungsauftrag startet ohne Material (Produktion). Der Zahllauf blockiert, das Skonto verfällt (Finanzen). Ein Merkmalsfehler, vier Äste des Orgcharts — und keine einzige dieser Wirkketten steht im Organigramm.

Das enthüllte Funktionsnetz zeigt dann, was das Orgchart verschweigt: Die Funktionen dieser vier Abteilungen hängen in einer Kette. Jede Kante dieser Kette kreuzt eine Abteilungsgrenze — vier Schnittstellen, die je einen Vertrag brauchen: Wer liefert welche Daten in welcher Qualität bis wann an wen. Reorganisationen scheitern regelmäßig genau hier: Man verschiebt Kästen im Baum und zerschneidet dabei Kanten im Netz, von deren Existenz niemand wusste.

Dieselben drei Traces, egal welche Domäne

Engineering — Baum: Stückliste → Funktionen → Merkmale · Netz: Merkmalsfehler trifft mehrere Baugruppen · Enthüllt: Abhängigkeiten quer zur Stückliste, Schnittstellen zu Lieferanten
FMEA — Baum: Strukturbaum · Netz: 1→n Fan-out · Enthüllt: Funktionsnetz aus Fehlerverknüpfung, Severity fließt zurück
SysML — Baum: Blockhierarchie (bdd) · Netz: meist nicht modelliert · Enthüllt: die Abhängigkeiten, die im ibd fehlen, weil niemand sie kennt
State Machines — Baum: Zustands-/Übergangsstruktur · Netz: Übergangsfehler trifft entfernte Zustände · Enthüllt: reale Kopplung von Modi und Achsen
Organisation — Baum: Orgchart → Rollen → Funktionen → Kennwerte · Netz: Fehler kreuzt Abteilungsgrenzen · Enthüllt: reale Prozessketten, Datenverträge/SLAs
Compliance / GRC — Baum: Normkapitel → Controls · Netz: ein Control-Ausfall verletzt Pflichten in fünf Normen · Enthüllt: Cross-Standard-Mapping — welches Control trägt welche Pflicht wirklich
ISMS — Baum: Asset-Inventar · Netz: eine Schwachstelle trifft mehrere Schutzziele und Dienste · Enthüllt: reale Abhängigkeit der Dienste von Assets — die Basis jeder ehrlichen Risikoanalyse

Fazit: Der Baum bleibt — er verliert nur den Wahrheitsanspruch

Nichts an diesem Befund schafft die Zerlegung ab. Trace 1 bleibt das Navigations- und Delegationsinstrument, ohne das kein komplexes System führbar ist. Aber er ist genau das: ein Instrument der Verwaltung, nicht die Beschreibung des Systems. Die Beschreibung des Systems steht in Trace 2 und Trace 3 — im Fehlernetz, das die Realität zeichnet, und im Funktionsnetz, das dabei sichtbar wird, samt der Schnittstellen und Verträge, die daraus folgen.

Die unbequeme Pointe: Jedes Unternehmen hat alle drei Traces, immer. Die Frage ist nur, ob Trace 2 und 3 explizit im Modell stehen — oder implizit in den Köpfen einzelner Kollegen, von wo aus sie weder Severity vererben noch Verträge begründen noch eine Reorganisation überleben.