Organisationen sollte man refaktorieren, nicht transformieren

Wenn Entwickler auf eine über Jahre gewachsene Codebasis schauen, finden sie häufig einen Big Ball of Mud: Verantwortlichkeiten sind kaum noch getrennt, Änderungen ziehen unerwartete Folgen nach sich, und manche Teile versteht nur noch die eine Person, die schon sehr lange dabei ist.

Der verständliche Reflex lautet: Wir bauen das Ganze neu. Diesmal ordentlich. Mit sauberer Architektur, klaren Schnittstellen und einem Zielbild, das auf dem Diagramm ziemlich überzeugend aussieht.

Nur weiß man in der Softwareentwicklung inzwischen, wie riskant solche Big-Bang-Rewrites sind. Das alte System muss weiterlaufen, während das neue entsteht. Anforderungen verändern sich. Versteckte Abhängigkeiten werden erst sichtbar, wenn man sie berührt. Und während das neue System versucht, den Stand von gestern nachzubauen, entwickelt sich das alte weiter.

Deshalb gibt es Muster wie Strangler Fig oder Branch by Abstraction. Man sucht einen Teil des Systems, den man sinnvoll abgrenzen kann, zieht eine Schnittstelle ein und ersetzt dahinter Schritt für Schritt die alte Struktur.

Ein Bounded Context. Ein Modul. Eine Capability.

Nach jeder Änderung bleibt das System lauffähig und man sieht, was der Eingriff tatsächlich bewirkt. Das Ziel kann eine Microservice-Architektur sein. Manchmal ist ein gut strukturierter modularer Monolith die bessere Lösung. Entscheidend ist, ob Verantwortlichkeiten klarer werden und das System wieder beweglicher wird.

Bei großen Change- und Transformationsprogrammen handeln wir erstaunlich oft genau andersherum.

Der Big Ball of Mud im Organigramm

Auch Organisationen sind über Jahre gewachsene Systeme.

Neue Rollen kommen hinzu, alte Verantwortlichkeiten bleiben trotzdem bestehen. Ein offizieller Prozess bildet den Normalfall ab, daneben entstehen Excel-Listen und private Chats für die Ausnahmen. Entscheidungen wandern durch mehrere Gremien. Einzelne Menschen übersetzen zwischen Bereichen und halten mit persönlichem Einsatz zusammen, was strukturell längst nicht mehr zusammenpasst.

Sie funktionieren wie undokumentierte APIs. Verlässt einer dieser Menschen das Unternehmen, zeigt sich plötzlich, welche Funktion er die ganze Zeit für das Gesamtsystem erfüllt hat.

Irgendwann wird die Reibung zu groß. Dann startet die Transformation.

Neue Teams. Neue Rollen. Neue Prozesse. Neue Tools. Neue Governance. Möglichst gleichzeitig, weil die Dinge schließlich zusammenhängen.

Natürlich hängen sie zusammen. Genau deshalb ist es so riskant, sie gleichzeitig zu verändern.

Die Organisation muss während des Umbaus weiter Kunden bedienen, Produkte liefern, Menschen einarbeiten und auf Veränderungen im Markt reagieren. Trotzdem behandeln wir sie, als könnten wir das alte System kurz anhalten, ein neues installieren und anschließend wieder hochfahren.

Bis die Transformation dort angekommen ist, wo sie laut Plan sein sollte, existiert dieser Zielzustand häufig schon nicht mehr.

Menschen sind gegangen. Kundenbedürfnisse haben sich verschoben. Eine neue Technologie hat Möglichkeiten geöffnet, die bei der Planung noch niemand gesehen hat. Und die ersten Interventionen haben das System selbst verändert.

Der große Plan scheitert dann nicht unbedingt an schlechter Planung. Er scheitert daran, dass eine lebende Organisation kein statisches Bauprojekt ist.

Refactoring im laufenden Betrieb

Organisationale Refakturierung würde bei einem konkreten Ausschnitt beginnen: einem Wertstrom, einem Entscheidungsweg, einer Übergabe oder einer Stelle, an der mehrere Bereiche regelmäßig aneinandergeraten.

Wie ist der letzte reale Fall durch das System gelaufen? Wo hat Arbeit gewartet? Welche Information ging verloren? Wer musste zwischen den Beteiligten übersetzen? Welche Entscheidung hatte keinen klaren Ort? Welcher Workaround hat dafür gesorgt, dass es am Ende trotzdem funktioniert hat?

Dann verändert man einen begrenzten Teil.

Eine Verantwortung wird verschoben. Eine Grenze klarer gezogen. Eine Übergabe entfernt. Ein Gremium abgeschafft. Eine neue Routine für einen konkreten Fall erprobt.

Danach beobachtet man, was passiert.

Hat sich der Flow verbessert? Welche Nebenwirkung ist entstanden? Welche Abhängigkeit wird jetzt sichtbar? Was ist durch diesen Eingriff möglich geworden?

Der entscheidende Punkt ist die Größe des Eingriffs. Er muss relevant genug sein, um im System etwas sichtbar zu verändern, und begrenzt genug, damit Ursache und Wirkung noch erkennbar bleiben. Eine gemeinsame Richtung hält die einzelnen Schritte zusammen. Was danach kommt, ergibt sich aus dem, was die Organisation beim Umbau lernt.

Welcher Eingriff ist der richtige?

In einer gewachsenen Organisation gibt es Dutzende plausible Baustellen. Jeder Bereich kennt ein Problem. Jede Führungskraft hat eine bevorzugte Lösung. Aus jedem Workshop gehen genug Maßnahmen hervor, um die nächsten drei Jahre beschäftigt zu sein.

Die entscheidende Arbeit beginnt deshalb vor der Intervention.

Welche Beobachtung wiederholt sich? Welche Evidenz haben wir? Welcher Mechanismus könnte dahinterliegen? Was würde für wen wertvoll besser werden? Und wo liegt ein Eingriff, der relevant genug ist, um etwas zu bewegen, und begrenzt genug, um daraus zu lernen?

So entsteht kein vollständiger Transformationsplan. Es entsteht eine begründete Entscheidung über den nächsten sinnvollen Umbau.

Mit jeder dieser Entscheidungen entwickelt das Unternehmen seine eigene Arbeitsweise weiter. Methoden, Rollen, Rituale und Kadenzen bilden eine Komposition, die aus dem konkreten Kontext entsteht.

Ein Team arbeitet vielleicht in zweiwöchigen Zyklen, ein anderes liefert kontinuierlich. Strategische Entscheidungen fallen quartalsweise, Budgets jährlich, ein wichtiges Gremium trifft sich monatlich. Jeder dieser Rhythmen kann sinnvoll sein. Die Reibung entsteht dort, wo sie gegeneinander laufen.

Organisationale Refakturierung arbeitet genau an diesen Übergängen. Das Zielbild bleibt dabei wichtig – als Richtung, nicht als Bauanleitung für die nächsten drei Jahre.

Vielleicht wäre eine gelungene Transformation dann daran zu erkennen, dass das Unternehmen die nächste gar nicht mehr braucht. Weil es gelernt hat, sich im laufenden Betrieb selbst weiterzuentwickeln.