diagnostics

Stock and Flow Mapping

Die exakte, quantitative Landkarte der Systemtheorie. Visualisiert Architektur als ein Netzwerk von Badewannen (Bestände), in die Variablen hinein- und herausfließen (Raten).

technologyorganization·4 min Lesezeit

Was ist das?

Die exakte, quantitative Landkarte der Systemtheorie. Visualisiert Architektur als ein Netzwerk von Badewannen (Bestände), in die Variablen hinein- und herausfließen (Raten).

Warum relevant?

Diagnostik macht aus Vermutungen belastbare Strukturhypothesen fuer Architektur und Organisation.

Nächster Schritt

Leite im Anschluss Interventionen ab, die gezielt Regeln, Grenzen oder Feedback-Loops veraendern.

~4 Min. Lesezeit

Zweck

"Stock and Flow Mapping" (Bestands- und Fluss-Modellierung) ist die königliche Disziplin der System-Diagnostik von Jay Wright Forrester. Während *Causal Loop Diagrams* nur verschwommene Richtungen ("Mehr Features bedeuten mehr Bugs") aufzeichnen, übersetzt *Stock and Flow* die Architektur in knallharte physikalische Mengenlehre. Es legt die gnadenlose Wahrheit offfn, dass ein verstopftes System (Ein voller "Stock" an Jira-Tickets) nicht nur durch "mehr Entwickler" (Flow-Out) geleert werden kann, sondern dass es viel billiger ist, den Wasserhann (Flow-In vom Product Owner) zuzudrehen.

Einsatzkontext

Wenn das Management fragt: "Warum dauert alles so lange?" oder "Wo verschwindet unsere Server-Ressource?". Stock and Flow ist die Diagnostik für alles, was sich *akkumulieren* lässt: Tech-Debt-Berge, Backlogs voller Tickets, Server-RAM-Auslastung bei Memory Leaks, Entwickler, die wegen Überlastung kündigen.

Schritt für Schritt

1.Den Bestand (Stock) identifizieren: Das ist die Badewanne. Ein Status Quo, der sich beobachten lässt, selbst wenn die Zeit stillstünde. (z.B. "Anzahl der ungefixten Production-Bugs"). In Diagrammen ein Rechteck.

2.Den Zufluss (Inflow) zeichnen: Das Rohr, das Wasser in die Wanne kippt. Das ist eine *Rate*, sie wird über Zeit gemessen. (z.B. "20 neue Bugs pro Woche"). Dargestellt als dicker Pfeil mit einem Ventil.

3.Den Abfluss (Outflow) zeichnen: Das Rohr, das Wasser aus der Wanne ablässt. (z.B. "10 Bugfixes pro Woche").

4.Das Reservoir berechnen: Das Level im Stock ist das exakte Integral der Differenz über Zeit. Da Inflow (20) größer als Outflow (10) ist, füllt sich die Wanne um 10 Bugs pro Woche. Die Überforderung ist mathematisch sichergestellt.

Beispiel

Ein VP Engineering klagt: "Unsere Plattform-Dokumentation (Stock) ist immer veraltet!". Das *Stock and Flow* Diagramm wird gezeichnet. Der Zufluss (Neue Architekturänderungen pro Sprint) steht bei 50 Einheiten/Woche (Ventil steht weit offen). Der Abfluss (Zeit der Entwickler, die ins Schreiben der Doku gesteckt wird) steht bei 5 Einheiten/Woche (Ventil steht auf Tropf). Die Lücke zwischen der Realität und der Dokumentation (Stock of Technical Debt) füllt sich zwingend jede Woche um 45 Einheiten. Die Diagnose zeigt: Solange das Development-Tempo (Inflow) nicht hart gekappt wird, kann man das Documentation-Debt-Problem nicht lösen. Die reine Mathematik verbietet es.

Diagramm

Wie aus Diagnose Handlung wird

Der gewaltigste blinde Fleck des menschlichen Gehirns ist das Versagen, Akkumulation zu begreifen. Architekten argumentieren oft: "Wir fixen doch jetzt so viele Fehler wie noch nie!" (Sie schauen nur auf den Outflow). Aber solange der Inflow minimal größer ist als der Outflow, verschlechtert sich das System kontinuierlich weiter. Stock-and-Flow bringt das Konzept der "Grenzkapazität" (Carrying Capacity) in IT-Skalierungsgespräche. Dein Kubernetes Cluster ist ein Stock. Wenn der Inflow deiner Kunden-Logins wächst, entlädt sich die Wanne in einen Incident, es sei denn das Ventil "Auto-Scaling" greift exakt rechtzeitig.

Wann diese Methode die richtige ist

*Behaviour over Time Charts* zeigen die Vergangenheit. *Causal Loop Diagrams* zeigen Korrelationen. *Stock and Flow Mapping* ist die Voraussetzung, um lauffähige Computermodelle (Simulationen) deines Systems zu programmieren, um Krisen im Operations-Umfeld im Vorhinein zu errechnen (z.B. Queuing-Theorie, Little's Law).

Wie du die Diagnose im Alltag einsetzt

Zwinge Product Manager dazu, das Firmen-Backlog nicht als magisches Feenland ("Wir wollen einfach alles priorisieren"), sondern als eiskalten Stock aufzuzeichnen. Ein Product Backlog ist eine Badewanne. Wenn du mehr Features oben reinwirfst als unten implementiert werden, stirbt das System am psychologischen Overflow (Tickets verrotten). Lerne, das "Inflow" Ventil (Die Priorisierung) aktiv zuzudrehen, um das Flow-Ratio deines Kanban-Boards gesund und stabil zu halten. WIP-Limits (Work in Progress Limits) sind pure Stock-and-Flow-Architektur!

Erste Analyse-Schritte

Unterscheide klar zwischen "Physischen" Beständen (Anzahl der Container, Code-Lines) und "Informationellen/Immateriellen" Beständen (Erschöpfung des Teams, Architektonisches Wissen, Vertrauen). Die unsichtbaren Stocks verhalten sich physikalisch genauso wie Ram-Speicher. Wenn "Vertrauen ins Backend" 0 erreicht, stürzt das Release-System ab, weil niemand mehr traut, zu deployen.

Woran du eine brauchbare Diagnose erkennst

Arbeiten wir bei massiven Bottlenecks im Delivery-Prozess nur neurotisch daran, mehr "Entwicklergeschwindigkeit" (Outflow) herauszupressen, anstatt hart das "Requirement-Volume" (Inflow) strategisch abzuwürgen?