Viability Audit with VSM

Zweck

Das "Viability Audit" ist die operative Checkliste des *Viable System Model (VSM)* von Stafford Beer. In der Tech-Industrie skalieren Firmen von 10 auf 500 Entwickler, indem sie einfach "mehr Tribles" oder "mehr Microservices" hinzufügen. Das führt zu massivem Kontrollverlust. Das Viability Audit prüft, ob eine Organsiation oder ein Software-Service exakt die 5 cybernetischen Organe (Systeme 1-5) besitzt, die für ein autonomes "Überleben" in einer feindlichen Umwelt (Markt, Hacking, Outages) absolut genetisch zwingend erforderlich sind.

Einsatzkontext

Das Audit wird als Notbremse vor großen "Hyper-Growth" Phasen, Carve-Outs oder radikalen "Autonomie-Initiativen" (DevOps / You build it, you run it) genutzt. Wenn der CEO sagt "Die Squads sind jetzt komplett autonom, wir streichen das Mittelmanagement", zieht der Architekt das Audit, um zu prüfen, ob die Teams diese Autonomie überhaupt steuern *können*.

Schritt für Schritt (Das VSM Audit)

Der Auditor prüft unbarmherzig die Existenz der 5 Systeme auf jeder logischen Skalierungsebene:

1.System 1 (Operation): Erledigt die Einheit überhaupt Kernarbeit (z.B. Feature Coden)? Oder verwalten sie nur sich selbst (Overhead)?

2.System 2 (Koordination): Gibt es Mechanismen (Swagger-Docs, CI/CD-Pipelines), die verhindern, dass System-1-Einheiten sich gegenseitig zerstören (Oszillation/Merge-Konflikte)?

3.System 3 (Kontrolle): Gibt es ein Dashboard (APM, Datadog, Management), das in *Echtzeit* das "Hier und Jetzt" überwacht und Budgets gerecht zuteilt? Gibt es den "Sporadischen Audit" (System 3*), der ins System funkt, um die Wahrheit der Dashboards zu prüfen?

4.System 4 (Entwicklung): Schauen *ausreichend* viele Hirnzellen der Organisation nach Außen und in die Zukunft (Das "Da und Morgen")? (Z.B. Tech-Radar Forschung, R&D).

5.System 5 (Identität/Policy): Gibt es eine finale Entscheidungsinstanz (Architektur-Board), die bei unlösbaren Konflikten zwischen "Jetzt" (System 3) und "Zukunft" (System 4) die Firmenidentität ("Wir sind eine Quality-First Firma!") erzwingt?

Beispiel

Ein Audit wird auf ein Feature-Tribe (100 Personen) angewendet, das unfassbar viel Code in Produktion pumpt, aber die Fehlerquote explodiert. Das Audit diagnostiziert sofort: System 1 (Feature Coden) arbeitet auf 150%. Aber System 2 (Koordination) fehlt physisch komplett (Keine automatisierten End-to-End Tests zwischen den Services). Gleichzeitig dominiert System 3 (Tagesgeschäft-Druck aus dem Vertrieb) die Einheit komplett, während System 4 (Forschung, Architektur-Hygiene, Vorbereitung auf Kubernetes v2) zu 100% mit 0 FTE besetzt wurde. Das Audit-Ergebnis ist binär: Dieser Tribe ist *nicht viable* (nicht lebensfähig). Er wird sich in 6 Monaten selbst zerstören, weil er keine Zukunftssensorik besitzt.

Diagramm

Wie aus Diagnose Handlung wird

Einer der schmerzhaftesten Punkte in VSM-Audits ist der Kampf zwischen System 3 (Inside-and-Now) und System 4 (Outside-and-Then). Architekten sollten eigentlich in System 4 operieren, sind aber zu 90% gefangen in der Hölle der System 3 Micromanagement- und Fire-Fighting-Aufgaben. Wenn das VSM-Audit ergibt, dass System 4 ausgehungert wird, garantiert dir die Systemtheorie, dass dein Marktprodukt in naher Zukunft veralten oder von einer disruptiven Technologie der Konkurrenz zerstört wird.

Wann diese Methode die richtige ist

*Dependency Mapping* und *Stock and Flow* schauen, ob der Code fließt. Das *Viability Audit* hingegen schaut weitaus höher: Besitzt dieser Code, dieser Cloud-Service und dieses Team um den Code herum überhaupt die Kybernetik eines "Gehirns", um sich selbstständig ohne Eingriffe von oben am Leben zu erhalten?

Wie du die Diagnose im Alltag einsetzt

Zerstöre in Management-Vorlagen das Konzept "Lean = Gut" und "Management = Overhead". Nutze das Audit, um radikal klarzumachen: Die Autonomie deiner Amazon-Dev-Teams funktioniert *nur* deshalb, weil AWS Milliarden in System 2 (Perfekte APIs) und System 3 (Brutale Alarmsysteme) investiert hat. Du kannst nicht einfach Hierarchien abbauen (System 3/4 entfernen), ohne System 2 massiv mit Technologie auszustaffieren. Das Resultat ist kein "agiles Nirvana", sondern kybernetischer Selbstmord.

Erste Analyse-Schritte

Auditiere radikal die Kommunikationskanäle (Algedonische Kanäle). In einem *Viable System* muss ein katastrophaler Ausfall unten in System 1 direkt, roh und ungefiltert, an der mittleren Abteilungsleiter-Hierarchie vorbei, als Schmerz-Signal oben in System 5 (CIO Board) eintreffen. Existiert bei euch eine Fehler-Verwässerungs-Kultur im Mittelmanagement? Das Audit würde das Alarm schlagen.

Woran du eine brauchbare Diagnose erkennst

Wird ein einzelner, unabhängiger Bounded-Context (Microservice) nur dann als "fertig" abgenommen, wenn das betreuende Squad beweisen kann, dass der Service nicht nur logische Arbeit (System 1), sondern auch automatische Observability (System 3) und einen klaren Lifecycle-Plan (System 4) eingebaut hat?

Quellen

Stafford Beer — The Brain of the Firm (John Wiley, 1972)

Stafford Beer — Diagnosing the System for Organizations (John Wiley, 1985)

Wikipedia: Viable System Model