Systemdenken

Ein System ist mehr als eine Ansammlung von Teilen. Es sind die Teile plus ihre Wechselwirkungen. Und oft sind die Wechselwirkungen wichtiger als die Teile selbst.

Betrachten wir ein Software-Team. Es gibt Entwickler, Designer, QA-Ingenieure, einen Product Manager. Jeder Einzelne mag hervorragend sein. Aber wenn sie nicht gut kommunizieren, wenn Übergaben holprig sind, wenn Anreize nicht aufeinander abgestimmt sind – dann bleibt das Team hinter seinen Möglichkeiten zurück, trotz des Talents.

Systemdenken bedeutet, das gesamte System zu verstehen, bevor man versucht, die Teile zu verbessern. Es bedeutet zu fragen: Wie interagieren die Teile? Welche Feedback-Schleifen existieren? Welche emergenten Verhaltensweisen entstehen?

Die meisten organisatorischen Dysfunktionen entstehen dadurch, dass Systemdenken ignoriert wird. Jede Abteilung optimiert ihre eigenen Kennzahlen, während das Gesamtergebnis leidet. Der Vertrieb schließt Deals ab, die das Produkt nicht liefern kann. Die Entwicklung baut Features, die das Marketing nicht verkaufen kann. Jeder erreicht seine KPIs, während das Unternehmen kämpft.

Hier ist ein häufiges Szenario: Das Entwicklungsteam ist der Engpass. Also beschließt das Management, die Entwickler effizienter zu machen. Sie tracken Story Points, messen Velocity, reduzieren Meetings. Die Produktivität der Entwickler steigt.

Aber die Lieferung verbessert sich nicht. Warum?

Weil der Engpass nie wirklich in der Entwicklung lag. Er lag im Deployment – einem manuellen, fehleranfälligen Prozess, den nur eine Person verstand. Indem man die Entwicklung beschleunigt hat, hat man nur einen größeren Stau beim Deployment erzeugt. Die Lead Time stieg, obwohl die Entwickler schneller arbeiteten.

Lokale Optimierung verbessert einen Teil des Systems. Globale Optimierung verbessert das gesamte System. Das ist nicht dasselbe – und lokale Optimierung schadet oft der globalen Leistung.

Das ist Goldratts Erkenntnis aus der Theory of Constraints: Alles zu verbessern, was nicht der Engpass ist, ist Verschwendung. Wenn Deployment Ihr Engpass ist, ist es Theater, die Entwicklung schneller zu machen. Beheben Sie zuerst das Deployment.

In Software-Organisationen sind häufige lokale Optimierungen, die global schaden:

• Maximierung der Entwicklerauslastung (zerstört Puffer, erhöht Wartezeiten)
• Messung individueller Velocity (schafft Anreize zum Gaming, schadet der Zusammenarbeit)
• Optimierung der Build-Zeit (irrelevant, wenn Deployments nur monatlich stattfinden)

Systeme enthalten Feedback-Schleifen – der Output eines Teils wird zum Input eines anderen. Manche Schleifen sind verstärkend (amplifizierend), andere sind ausgleichend (stabilisierend).

Beispiel für eine verstärkende Schleife: Entwickler nehmen Abkürzungen, um Deadlines einzuhalten. Das erzeugt technische Schulden. Technische Schulden verlangsamen die zukünftige Entwicklung. Teams nehmen mehr Abkürzungen, um die nächste Deadline einzuhalten. Die Todesspirale beschleunigt sich.

Beispiel für eine ausgleichende Schleife: Ein Team führt WIP-Limits ein. Arbeit staut sich auf. Leute schwärmen aus, um den Stau zu beseitigen. Das WIP sinkt. Das System stabilisiert sich selbst.

Emergentes Verhalten ist Verhalten auf Systemebene, das nicht aus den Teilen allein vorhergesagt werden kann. Ein Stau wird nicht von einem einzelnen Auto verursacht – er entsteht aus Tausenden kleiner Interaktionen. Ebenso kann eine dysfunktionale Organisation aus lauter hervorragenden Einzelpersonen bestehen, aber das System produziert Dysfunktion.

Lean-Denken erfordert einen Schritt zurück, um diese Muster zu sehen. Man kann eine verstärkende Todesspirale nicht durch Schulung von Einzelpersonen beheben. Man muss die Systemdynamik ändern – normalerweise durch Änderung von Anreizen, Einschränkungen oder Feedback-Mechanismen.