Change-Programme – von teuren Irrwegen und besseren Alternativen

Warum Change in der neuen Welt nicht mit alten Methoden funktioniert - und wie es besser geht

Kürzlich in einem Workshop auf einer kleinen, aber feinen Konferenz für KMU. Meine Frage ans Publikum: «Wer von Euch hat schon mal ein Change-Programm in einem Unternehmen erlebt?» Alle Hände gingen nach oben.

Eine Teilnehmerin erzählte daraufhin von einer zunächst gross angelegten Veränderungskampagne in ihrem Unternehmen, die letztendlich in eine Arbeitsgruppe zur Verbesserung der Luft im Büro mündete.

Vom anderen Extrem hatte eine Keynote am Morgen berichtet. Es ging um eine gescheiterte Holacracy-Einführung, die das betroffene Unternehmen über ein Jahr hinweg praktisch komplett gelähmt hatte – bevor die Übung abgebrochen wurde.

Die Denkweise ist falsch

Auch ich habe solche und ähnliche Geschichten bereits mehrfach erlebt. Warum genau aber Change-Projekte mit einem so hohen Risiko  des Scheiterns behaftet sind, ist mir vor einigen Jahren bei einem Grossunternehmen klar geworden. Hier ist die Geschichte:

Das Unternehmen hatte eine separate Abteilung, die IT-Entwicklungsprozesse definierte. Es gab damals einen Wasserfall- und einen iterativen Prozess. Die diversen IT-Abteilungen im Unternehmen, die mit Softwareentwicklung befasst waren, waren gehalten diese Prozesse in ihren Projekten zu verwenden.

Diese «Prozess-Definitions-Abteilung» war der sprichwörtliche Elfenbeinturm. Ich war dort in einem Projekt involviert, und gelegentlich zu Meetings eingeladen. Dabei fiel mir auf, dass in dieser Abteilung immer wieder von «Releases» gesprochen wurde.

Ich verstand das zunächst nicht. Natürlich kenne ich Software-Releases – aber was bitte soll ein «Prozess-Release» sein?

Mit der Zeit begriff ich es. Das «Release» eines Prozesses ist eine veröffentlichte Version seiner Dokumentation. Aha, also Papier.

Die Denkweise dahinter aber war folgende:

Wir (als Elfenbeinturm) definieren, wie die Arbeit zu tun ist. Ausgeführt wird sie draussen an der virtuellen Werkbank. Wenn wir ein «Prozess-Release» machen, dann werden sich die Leute danach richten, und die Hände an der Werkbank werden ihre Arbeit gemäss der neuen Prozessbeschreibung machen.

Nun will ich gar nicht darauf eingehen, wie realistisch diese Erwartung ist, wie gut das wohl funktioniert hat, und welche Qualität ein im Elfenbeinturm entwickelter Prozess hat.

Der Punkt, auf den ich hinweisen möchte, ist die Philosophie dahinter:

Wir teilen die Arbeit auf in solche, die wissen wie es geht, und solche, die sie ausführen. Diese Denkweise geht zurück auf Taylor’s «Scientific Management» von 1911, mit dem die erste Ford-Autofabrik organisiert wurde. Ausgebildete Manager hier, einfache Arbeitskräfte da.

Mittlerweile hat sich herumgesprochen, dass moderne Wissensarbeit anders funktioniert. Zum einen, weil innovative Arbeit etwas grundlegend anderes ist als eine Routine-Tätigkeit am Fliessband. Und zum anderen, weil die ehemals «einfachen Arbeitskräfte» heute auch ein Universitäts-Diplom mitbringen.

Damit sind wir aber wieder bei Change-Programmen. Bei genauerem Hinsehen funktionieren diese genau nach dem alten Muster: Jemand denkt sich einen Change aus (oder kauft ihn in Form einer Blaupause wie Holocracy ein), und «rollt» ihn dann aus.

Mit anderen Worten: Die Lösung wird an einem anderen Ort entwickelt, als sie letztendlich angewendet wird.

Die ungewollten Konsequenzen von Change

Nach dem (eher humorig gemeinten) «Gesetz der unbeabsichtigten Folgen» zieht jede zweckdienliche Handlung auch unbeabsichtigte Ergebnisse mit sich. Das ist auch bei Change-Programmen alter Schule der Fall.

a) Einmischung von aussen

Auch wenn Change-Gurus heutzutage sagen, man solle die Leute frühzeitig involvieren und Feedback-Loops einbauen – das Grundproblem bleibt das gleiche: Man geht auf Leute zu und sagt ihnen, dass sie ihre Arbeit bitteschön anders machen sollen als vorher. Man mag das gut begründen können. Man mag sich auch in Kommunikation versuchen, um den Kotter’schen «sense of urgency» zu erzeugen. Und so weiter…

Letztendes greift aber eine vermeintliche Elite in die Autonomie anderer Leute ein. Das muss zwangsläufig Verunsicherung und Abwehr hervorrufen.

Die darauf folgenden Beschwichtigungsmassnahmen machen eine klassisches Change-Programm aus. Sie sind aber nichts anderes als die Bekämpfung der Symptome, die aus dem Vorgehen selbst folgen.

b) Ziel-Konflikte

Ein weitere Punkt ist: Jedes Change-Programm steht in einem Zielkonflikt mit dem Tagesgeschäft.

Das primäre Ziel eines Mitarbeiters ist es, seine unmittelbaren Stakeholder zufrieden zu stellen. Das können interne oder externe Kunden sein. Daran wird er in der Regel auch gemessen.

Ein Change aus dem Elfenbeinturm erleichtert es allzu oft den Mitarbeitern nicht, ihrem Tagesgeschäft nachzugehen. Das heisst, er ist eine zusätzliche Belastung, und ein Spagat zwischen den auferlegten Zielen.

c) Teure Proxy-Lösungen

Der Zielkonflikt wird insbesondere dann dramatisch, wenn die angestrebte Veränderung eine Proxy-Lösung ist. Damit meine ich folgendes:

Natürlich soll jede Veränderung dem Unternehmen und seinen Kunden zu Gute kommen. Häufig versucht man dies aber über einen Umweg zu erreichen, indem man eine fertige, extern entwickelte Lösung implementiert.

Holacracy ist eine solche Lösung, SAFe eine andere. Wenn man sich für ein solches Modell entscheidet, dann verspricht man sich zwar davon eine Verbesserung der Arbeit im Unternehmen. Geschehen soll dies aber über den Umweg einer Methode.

Das Problem dabei:

Das unmittelbare Ziel für alle Beteiligten ist es nicht mehr, die Zusammenarbeit im Unternehmen zu verbessern, sondern die Methode zu benutzen. Das ist ein grosser Unterschied.

Es ergibt sich ein Stellvertreter-Ziel, das anfangs zwangsläufig im Konflikt mit dem Tagesgeschäft steht.

Und noch etwas: Aus Governance-Sicht misst man hierbei auch die falschen Erfolgskriterien – nämlich die Umsetzung der Methode, anstatt das eigentlich gewünschte Resultat.

Es herrscht damit effektiv das Prinzip Hoffnung, dass die Methode irgendwann später die Resultate herbeiführen wird, die man eigentlich wollte. So wird ein solcher Umweg schnell zu einem teuren Irrweg, und bringt unnötige Risiken mit sich.

Wie macht man’s besser?

Notwendig ist eine neue Philosophie. Die althergebrachte Idee, dass eine Veränderung erst definiert und dann implementiert wird, widerspricht dem modernen Verständnis von komplexen Systemen (und eine Organisation ist nichts anderes).

Tatsächlich optimiert man Systeme, in dem man a) das direkte Ziel definiert und b) mit kurzen Feedback-Zyklen die Wirksamkeit von Änderungen verifiziert.

Was heisst das konkret für ein Unternehmen, dass sich verändern will?

1. Ziele müssen einheitlich und relevant sein

Der erste Tipp ist, die erwähnten Proxy-Lösungen zu vermeiden. Eine Methode ist ein Werkzeug, das in einem bestimmten Kontext eingesetzt werden kann. Aber eine Methode darf niemals das Ziel eines Change-Programms sein.

Stattdessen muss man das Geschäftsziel messen, das man erreichen will – ganz gleich, ob das niedrigere Kosten, effizientere Abläufe oder zufriedenere Kunden sind. Aus diesen Zielen, sowie aus dem Tagesgeschäft, sind die Massnahmen abzuleiten und deren Wirksamkeit direkt zu messen.

2. Mehrwert schaffen

Am besten gewinnt man Mitarbeiter, wenn man ihnen hilft, ihre tägliche Arbeit einfacher oder besser zu erledigen. Erfolgreicher Change setzt daher auch unten an und schaut, wie mit einer Erleichterung der Arbeit die Ziele des Programms erreicht werden können. Die Mitarbeiter selbst können dazu den besten Input liefern.

3. Neue Strukturen schaffen

Ein generelles Problem in der heutigen Arbeitswelt sind die negativen Auswirkungen der Hierarchien.

Vorsicht: Das soll nicht heissen, dass es keine Hierarchien geben sollte. Die gibt es in jeder Gruppe von sozialen Wesen als ordnendes Prinzip.

Was es aber heisst: Die alten Formen von Hierarchie bedingen ein Machtgefälle, das die Menschen am unteren Ende einschüchtert und passiv macht. Genau das wirkt der Art von Change entgegen, die wir heute im Bereich der Digitalen Transformation brauchen.

Wir brauchen Strukturen, bei denen die Menschen nicht mehr ein Rädchen in einem anonymen Getriebe sind, sondern gemeinsam am Erfolg für den Kunden arbeiten. Dabei müssen sie wissen und fühlen können, welchen Beitrag sie konkret leisten.

Das bedeutet auch, dass jene Trennung zwischen einer Elite und ihren Arbeitskräften aufgeweicht werden muss.

Es mag weiterhin einen Chef geben, der – wenn alle anderen Mittel versagen – auch disziplinarisch aktiv werden kann.

Aber im normalen Arbeitsalltag sollte der Chef inhaltlich arbeiten und durch Seniorität einen Mehrwert für die Arbeit des Teams leisten. Team und Chef arbeiten also gemeinsam und an den gleichen Zielen – das schafft Vertrauen. Und wenn dann eine Veränderung ansteht, dann ist der Chef genauso betroffen wie das Team.

4. Warum, statt Wie

Change-Programme alter Schule beschäftigen sich mit dem Wie, und bemühen das Warum lediglich als Begründung in der Kommunikation.

Moderner Change beginnt mit dem Warum – und lässt das Wie erstmal offen. Das hat drei Vorteile:

  1. Das exakte Wie, das später zu den gewünschten Resultaten führt, kann ohnehin nicht vorab im Elfenbeinturm definiert werden. Vielmehr muss es, ähnlich wie in der agilen Software-Entwicklung, schrittweise und mit vielen Feedback-Schleifen entwickelt werden.
  2. Ist das Warum der Aufhänger, dann schafft man den für Motivation so wichtigen «Purpose». Es gibt damit einen Zweck, für den man sich engagiert. Es versteht sich von selbst, dass dieses Warum etwas reichhaltiger sein muss, als nur «Wir drücken die Kosten um 10 %». Purpose in der digitalisierten Welt fängt immer beim Kunden an.
  3. Dadurch, dass das Wie offen gelassen wird, werden die Mitarbeiter in ihrer Autonomie nicht angegriffen. Sie können selbst die Wege mitentwickeln, mit denen die gewünschten Resultate erreicht werden können. Das kommt auch der Tatsache entgegen, dass die Leute an der «Front» häufig sehr viel besser wissen, wo die Probleme liegen.

All das heisst nicht, dass ein besseres «Wie» nicht auch mit externer Unterstützung entwickelt werden kann. Es gibt durchaus Erkenntnisse und Impulse, die intern schwierig zu bekommen sind. Wichtig ist allerdings, dass diese Unterstützung sich an den Zielen und dem für die Mitarbeiter relevanten Tagesgeschäft orientiert, und nicht an einer unternehmensfremden, abstrakten Methodik.

5. Change on the job

Wirksame Veränderung funktioniert ähnlich, wie Milch tröpfchenweise in den Kaffee zu giessen (danke Niels Pfläging für die Metapher). Jeder Tropfen verändert das Gesamtergebnis. Ein schrittweises Vorgehen schafft viel mehr Sicherheit, und reduziert das Risiko.

Damit ändert sich auch das Verständnis von Change. Es geht nicht mehr darum, eine konkrete Lösung „auszurollen“. Es geht darum, sich schrittweise an einen Zielzustand heranzutasten.

Eine zukünftige Lösung wird immer umstritten sein. Ein Zielzustand sollte dagegen konsensfähig sein.

Fazit

Selbstverständlich stehen manchmal Veränderungen an, die unternehmensweiten Einfluss haben. Und natürlich braucht es dafür sowohl Vorarbeiten als auch Koordination und inhaltliche Führung. Nicht alles kann rein auf Arbeitsebene geschehen.

Die wichtigsten Faktoren eines modernen Change-Programmes aber sind:

1. Die richtigen Ziele definieren

An der Arbeit für den Kunden ausgerichtete Ziele definieren und messen – Proxies sind ebenso zu vermeiden wie abstrakte Ziele oder finanzielle Kennzahlen. Die Mitarbeiter müssen erkennen können, wie ihre Arbeit Einfluss auf das Resultat hat.

2. Die richtigen Strukturen schaffen

Die Verbindung zwischen Top-Down (strategische Veränderungen) und Bottom-Up (Verbesserungen auf der Arbeitsebene) gezielt herstellen, und so das Potential und die Motivation der Mitarbeiter nutzen und bessere Lösungen erreichen.

3. Das richtige Vorgehen wählen

Das Motto lautet: Kontrollierte Evolution statt sturem Rollout.

Der Weg ist das Ziel – und das ist zugleich auch das Mindset für die digitalisierte Welt.

Passend dazu: Organisation der digitalen Transformation – Firmen neu aufbauen

Steffen kennt die Digitalisierung von beiden Seiten - als IT-Executive bei etablierten Unternehmen, und als CTO bei verschiedenen Fintech-Startups. Er hat gelernt, wie man luftige Ideen konkretisiert, komplexe Vorhaben umsetzt und hoch performante Teams kreiert. Heute berät er Unternehmen als Sparring Partner für Strategie, Technologie und Organisation beim Verkürzen der digitalen Lernkurve.

Kommentare sind geschlossen, aber trackbacks und Pingbacks sind offen.