Dies ist mein Beitrag zur Blogparade #Organisationsrebellen. Deren Ziel ist es “Rebellen” dabei zu unterstützen, Unternehmen von innen heraus zu verändern.
Digitale Transformation, ick hör dir trapsen
Viele Unternehmen haben auf Grund disruptiver Konkurrenz und kollabierender Geschäftsmodelle im ferneren oder näheren Umfeld erkannt, dass sie sich modernisieren müssen.
Ein gängiges Vorgehen ist es dafür ein großes Veränderungsprogramm aufzusetzen – in letzter Zeit besonders gerne unter dem Stichwort “Digitale Transformation” (Meiner schwachen Erinnerung nach hat die allerdings in den 1990er-Jahren stattgefunden). Dann werden externe Berater eingekauft und das Programm wie ein Jahrhundertereignis angekündigt. Die Initiative startet und alle Mitarbeiter halten den Atem an.
Im Rahmen solch einer Transformation werden dann typischerweise unterschiedliche Best Practices eingeführt, Prozesse agilisiert, Leitbilder ausgegeben und Rollen und Zuständigkeiten neu geschnitten.
Wenn dies alles unterschiedlich nachhaltig implementiert ist, ist das Ziel erreicht und das Programm beendet. Alle Mitarbeiter atmen wieder auf in der Erwartung, dass es das jetzt war. Auch das Management feiert den Erfolg die Unternehmung agilisiert/modernisiert/digitalisiert/kundenorientiert zu haben (bitte frei auswählen).
Alle Mitarbeiter atmen wieder auf in der Erwartung, dass es das jetzt war.
Damit einher geht dann die frohe Erwartung nun endlich wieder in die gewohnte organisatorische Schockstarre übergehen zu können. Man ist ja nun für die “Zukunft” gut vorbereitet und aufgestellt. Nach der Digitalisierung gab es auch nichts mehr, oder?
Immer anders
So weit, so falsch.
Solch einem Vorgehen liegen drei Denkfehler zu Grunde:
- Früher konnten sich Unternehmen durch einzelne kleine Optimierungen an veränderte Rahmenbedingungen anpassen. Heute sind wir oftmals gezwungen radikal anders zu arbeiten – mit anderen Methoden, Fähigkeiten, Rollen und Prozessen: sei es bei inkrementeller Produktentwicklung mit agilen Methoden, dem multidisziplinären Arbeiten bei Design Thinking oder dem Falsifizieren von unzähligen falschen Hypothesen bei Lean Startup. Dummerweise setzt das jedoch tiefgreifende Veränderungen im Mindset aller Beteiligter voraus, die nur nach und nach erfolgreich erreicht werden können. Allein ein agiles Vorgehen lässt sich meist nicht komplett, auf einmal und in der ganzen Organisation einführen. Mitarbeiter müssen sich an neue Denkmuster gewöhnen, mit einfachen Prozessen anfangen und dann mit steigendem Reifegrad immer weitere Aspekte von agilen Methoden adaptieren. Meist starten auch sogenannte “Leuchtturmprojekte” in einzelnen Abteilungen, bevor weitere Abteilungen das Modell übernehmen.
Wir führen heute Veränderungen in kleinen Schritten ein, aber in sehr vielen über eine längere Zeit aufeinanderfolgenden um vom Ist- zum angestrebten Zielzustand zu gelangen. - Wenn ich eben vom “Zielzustand” gesprochen habe, den ich erreichen will, ist das eigentlich Unsinn. Es gibt heute zwar unstrittig Unternehmen, die unterschiedlich gut auf ihre individuellen Umgebungen reagieren können. Google, Amazon oder Zalando liegen tendenziell an einem Ende des Spektrums, traditionelle Banken oder zum Beispiel VW eher an einem anderen Ende. Dennoch ist ebenfalls unstrittig, dass selbst von den sehr erfolgreichen Unternehmen keines perfekt ist in seiner Organisation. Wir kennen den goldenen Zielzustand nicht und höchstwahrscheinlich ist es morgen auch schon ein anderer als heute, da sich mit dem Umfeld auch Anforderungen an eine Unternehmung ändern.
- One size doesn’t fit all. Genau wie der Zielzustand sich im Zeitverlauf ständig ändert, variiert er auch zwischen verschiedenen Unternehmen. Es gibt keine allgemeingültigen Lösungen für alle Unternehmen. All die Best Practices sind schön – zum Beispiel die von dem hierarchiefreien, selbstorganisierten und vollständig transparenten Unternehmen – das jedoch nur aus 30 Freelancern besteht. Ich muss immer herausfinden, was passend ist in meinem Unternehmen mit der jeweiligen Historie, der jeweiligen Kultur, den jeweiligen Geschäftspartnern und den jeweiligen Führungskräften. Bei einer Unternehmung mit weltweit 15.000 Mitarbeitern ist die Hierarchiefreiheit eventuell nicht zielführend. Für jede Organisation ist eine differenzierte Betrachtung der aktuellen Schwachpunkte nötig.
Veränderung ist Teil des Geschäfts
Aus diesen drei Erkenntnissen lässt sich eine entscheidende Anforderung ableiten: Die Veränderung der (Ablauf- wie Aufbau-) Organisation in einem Unternehmen muss kontinuierlich passieren und immer auf die jeweilige Unternehmung ausgerichtet sein.
Dazu finde ich eine Analogie aus der Softwareentwicklung sehr passend, die einmal mein ehemaliger Chef, Andreas Hankel, formuliert hat: Wenn ich eine Software nicht fortlaufend pflege, aktualisiere und Refactoring betreibe, baue ich zwangsläufig Technical Debt (technische Schuld) auf, die mich dann langsamer macht durch unpassende Funktionalitäten, geringe Anpassbarkeit, hohe Betriebsaufwände etc. Ebenso verhält es sich mit der Unternehmung: Wenn ich die Organisation nicht fortlaufend anpasse und weiterentwickle, baue ich “Organisational Debt” (organisatorische Schuld) auf, die mich langsamer macht und verhindert, dass ich mich optimal auf die Markterfordernisse ausrichten kann.
Das bedeutet zwangsläufig, dass ich die Fähigkeit für die fortwährende Veränderung in meiner Unternehmung selbst haben muss. Die eigene Anpassung und Veränderung muss ein Kern meiner Geschäftstätigkeit sein!
Dafür brauche ich Führungskräfte, die dies als Teil ihrer Aufgabe verstehen und die Fähigkeit haben solche Impulse in die Unternehmung zu geben und umzusetzen. Sie müssen die Veränderung als Role Model vorleben und damit eine Kultur des “embrace change” schaffen.
Natürlich sind Best Practices, Impulse und Do’s und Don’ts von Externen dennoch wertvoll und notwendig. Aber ich muss sie immer dafür nutzen die Veränderungskompetenz in meiner eigenen Organisation zu stärken.
Die eigene Anpassung und Veränderung muss ein Kern meiner Geschäftstätigkeit sein!
Andreas Hankel hat nur den Gedanken von Robert C. Martin (uncle Bob) wiedergeben. Eine Software, was nicht ständig refactored wird und dem technischen Wachstum nicht angepasst wird gammelt und fängt an zu „riechen“. Somit wird technische Schuld aufgebaut, was den Business letzt endlich langsam macht.
Hallo Stan,
da habe ich mich missverständlich ausgedrückt: Ich meinte das Konzept von Organisational Debt habe ich das erste Mal von Andreas Hankel gehört. Technical Debt ist natürlich älter, da hast du Recht.