Management – Anregungen zum Nachdenken und Diskutieren
Management

Serie: Management – Anregungen zum Nachdenken und Diskutieren

Teil 16: Change-Management

Auch wenn alle Manager im Unternehmen den Forderungen des letzten Abschnitts über das rechtzeitige Wehtun entsprechend immer rechtzeitig weh getan haben, alle Korrekturen so früh wie möglich durchgeführt haben, wird immer wieder ein Zeitpunkt kommen, an dem größere Anpassungen für größere Teile des Unternehmens notwendig werden. Das können größere Erneuerungen bei Verwaltungssystemen sein, Änderungen an den Kundenschnittstellen, Integration neuer Geschäftsmodelle, die Erneuerung von Kernprozessen, neue Strukturen oder Wechsel von Produkten und Dienstleistungen. Dann ist die Befähigung des Managements zum möglichst glatten und stolperfreien Führen der Organisation durch diese Veränderung gefragt. Change-Management kann man mit Fug und Recht als eine der Königsdisziplinen des Managements bezeichnen.

Bei dem Begriff Change-Management sollte man sich erst einmal im Klaren sein, dass er je nach Betonung eine unterschiedliche Bedeutung hat. Im ersten Fall meint er das Management der Veränderung, im zweiten Fall hingegen den Wechsel des Managements. Letzteres kann bei manchen Veränderungen durchaus notwendig sein, denn gerade in den höheren Ebenen sitzen ja Kollegen, die in den alten Strukturen und Vorgehensweisen offensichtlich besonders gut funktioniert haben und in der Zielumgebung deshalb vielleicht weniger erfolgreich agieren werden. Wir wollen uns hier mehr um die erste Interpretation kümmern, dort aber nicht aus den Augen verlieren, dass gerade bei größeren organisatorischen Veränderungen Manager – und zwar gerade in den höheren Positionen – aktiv die Veränderung sabotieren, weil sie Macht, Prestige, Entscheidungsbefugnisse etc. verlieren.  

Ein großer Fehler bei Veränderungsprozessen geschieht nach meiner Beobachtung vor allem bei der Planung der Zielkonstellation, weil man die Fähigkeiten der eigenen Mannschaft zu optimistisch einschätzt oder sie vollkommen ignoriert. Erlauben Sie mir dazu ein Beispiel aus meiner alten IT-Welt. Ende des 20sten Jahrhunderts wurde die IT-Infrastruktur immer unverzichtbarer und musste rund um die Uhr (7×24) verfügbar sein. Dies war in den meisten Industrien mit den internen Strukturen nicht zu bewältigen bzw. schlicht viel zu teuer. Den Service konnte man finanziell nur darstellen, wenn man zu Spezialisten ging, die Dienstleistungen rund um die Uhr für viele Unternehmen gleichzeitig erbrachten und dadurch die nötige Effizienz erreichten. Um mit so einem Dienstleister zusammenarbeiten zu können, musste man aber zunächst die interne Prozess- und Steuerungskompetenz entwickeln, um einen solchen Dienstleister einbinden und kontrollieren zu können. Aber viele haben sich doch nicht – entweder aus echter Not, da man sich zu spät bewegt hatte, oder aus arroganter Selbstüberschätzung oder schlichter Fehleinschätzung eigener Fähigkeiten – auf diesen Weg begeben. Finanzielle Verluste, Verbrennen von Mitarbeitern, Pendeln zwischen Outsourcing und Insourcing etc. waren über Jahre hinweg die Folge. Die Gefahr solcher Fehleinschätzungen ist dann besonders groß, wenn Unternehmen die Entwicklung der Zielkonstellation externen Theoretikern überlassen.

Allerdings laufen wir genauso oft in Gefahr, die Veränderungsfähigkeit unserer Organisationen zu unterschätzen. Ein indischer Professor, der damals an der INSEAD in Fontainebleau unterrichtete – leider habe ich nur seine Geschichte behalten, aber nicht seinen Namen – erzählte mir einmal folgende Geschichte: Im Frühjahr ging er gerne im Park hinter der Business-School in Fontainebleau spazieren. Er war voller Energie, genoss den Duft der frischen Blüten und sprang hoch, um sich einen knospenden Zweig abzureißen und mit ins Büro zu nehmen. Im August reiste er dann nach Kalkutta, um seine Familie zu besuchen.  Den ganzen Tag verbrachte er dann erschöpft im abgedunkelten Raum, um sich abends in einer klimatisierten Limousine zu Familientreffen kutschieren zu lassen. Er war schlapp, lustlos und ohne jegliche Energie. War er nun seit dem Frühjahr ein anderer Mensch geworden? Musste man ein Change-Programm aufsetzen, um ihn wieder auf das alte Energielevel zu bringen? Nein, sagte er. In vielen Veränderungssituationen reicht es, einfach mal die Fenster aufzumachen und frische Luft hereinzulassen!

Und diese Geschichte enthält viel Wahrheit. In ganz vielen Veränderungsprozessen ist insbesondere den Mitarbeitern an der Basis sehr klar, dass etwas in der Organisation, in den Prozessen, in der Art der Zusammenarbeit nicht stimmt. Sie merken, dass es zu langsam und bürokratisch geht, dass sie oft den Kunden nicht zufrieden stellen können, dass Produkte nicht rechtzeitig kommen oder ihre Funktionalität nicht dem entspricht, was der Kunde braucht. Man wird also oft zahlreiche Unterstützer der Veränderung finden, zumindest dann, wenn es sich nicht um reine Kosten- und Stellensparprogramme handelt. Aber es empfiehlt sich doch immer, eine klare und vollständige Analyse zu machen, wo die Gewinner und wo die Verlierer dieser Veränderung sind, und zwar auch auf den Managementpositionen.

Wenn also ein neues IT-System verbunden mit veränderten Entscheidungsprozessen und Zuständigkeiten eingeführt wird, sollten Sie wissen, wer denn in den Abteilungen die Gurus waren, die ihren Status bei den Kollegen, ihr Ansehen dadurch erwarben, weil sie alle Tricks kannten und den anderen halfen, wenn sehr komplexe Fälle in das System eingegeben werden mussten. Entfällt deren Rolle komplett, kann man sie wenigstens teilweise auch im neuen System in eine ähnliche Rolle bringen? Werden sie nur auf dem Zaun sitzen und meckern oder kann ich sie aktiv zu Promotern der neuen Welt machen? Verlieren Einheiten ihre Macht, ihre hausweite Bedeutung, weil bestimmte Kontrollen, die früher durch diese Einheit durchgeführt wurden, jetzt durch das System selbst erledigt werden? Und Sie sollten diese Stakeholder-Analyse nicht abstrakt in Funktionen, sondern in Personen durchführen. Wenn Sie Projektverantwortlicher für die Umsetzung eines Veränderungsprojektes sind, empfehle ich Ihnen dringend, diese identifizierten Stakeholder im Auge zu behalten. Keinesfalls sollten Sie in den Fehler verfallen, all die vielen positiven Aussagen der Kollegen auf dem Kick-off Meeting zu glauben. Wenn mir in einem solchen Meeting mal wieder vermittelt wurde, man sei „fully comitted“, dann habe ich gerne erzählt, was der Unterschied zwischen „fully comitted to a project“ und „supporting a project“ ist. Beim amerikanischen Frühstück Bacon and Eggs unterstützt das Huhn das Projekt, aber das Schwein ist „fully comitted“! Danach wurde das Wort comitted deutlich weniger verwendet.

In einem früheren Beitrag haben wir uns einmal mit der Härte weicher Faktoren beschäftigt. Und dieses Thema spielt natürlich bei Veränderungsprozessen unter Umständen eine große Rolle. Es lohnt sich deshalb sehr, vor Beginn des Projektes einmal genau hinzuschauen, welches die eher rein rational betrachteten Veränderungen sind und wo überall Glaube, Emotion, Zu- und Abneigungen eine Rolle spielen. Seien Sie bei dieser Analyse nicht zu optimistisch! So können Sie in der IT-Abteilung durch den Vorschlag einer neuen Programmiersprache oder bestimmter Tools jahrelange Religionskriege entfachen. Wenn Sie einer Fachabteilung vorschlagen, deren Verwaltungsbedarfe mit einer Standardsoftware (vielleicht sogar noch SAP?) zu bedienen, werden Sie Abscheu ernten und Hohngelächter, ob ihrer Unkenntnis der so ganz besonderen Bedarfe dieser einzigartigen Fachabteilung. Aber trotzdem: Ein einigermaßen klares Bild, wie groß der Widerstand im nicht-rationalen Bereich ist, wird Ihnen helfen.

Zum Schluss noch ein paar konkrete Tipps für die erfolgreiche Umsetzung:

  1. Offene und ehrliche Kommunikation der Ursachen für diesen Veränderungsprozess und seine Ziele ist ein Schlüssel für den Erfolg. Es zahlt sich an dieser Stelle niemals aus, wenn man etwas schönredet, seien es die Fehler der Vergangenheit oder die Herausforderungen im anstehenden Änderungsprozess.
  2. Die Mitarbeiter schauen sehr genau darauf und haben ein sehr gutes Gespür dafür, ob mit allen Beteiligten gleichermaßen fair umgegangen wird. Sie wollen, dass ein Kollege, der immer versucht hat, allen zu helfen, anders behandelt wird als derjenige, der immer mehr Teil des Problems als der Lösung war – auch wenn dieser Kollege ein Manager ist!
  3. Nach der Entwicklung der Veränderung, ihrer Ankündigung und der formellen Umsetzung beginnt die Aufgabe des Change-Managements erst wirklich! Nun heißt es Tag für Tag nachzufassen und zu kontrollieren, dass wirklich das Neue gelebt wird und nicht versucht wird, schleichend zum Alten zurückzukehren. Wir wissen alle, dass das Leben in der Regel nicht schwarz oder weiß, sondern grau ist. Und die Verlierer der Veränderung werden solche grauen Fälle immer wieder heranziehen und dafür argumentieren, dass man hier doch wieder einmal nach dem alten Verfahren arbeiten müsse. Bleiben Sie hier in der ersten Zeit nach der Umsetzung unerschütterlich und fundamentalistisch bei der neuen Lehre. Es geht nicht anders. Sie verlaufen sich sonst im Urwald der Sonderregelungen und werden die Konzepte bis zur Unkenntlichkeit verwässern. Erst wenn die neuen Konzepte wirklich vollständig durchgesetzt sind, können Sie wieder Grauzonen zulassen.

Last, but not least. Passen Sie auf, dass Sie vor der Umsetzung der Veränderung den Altzustand wirklich vollständig erfassen. Wenn eine alte Organisation oder ein Prozess lange Zeit gelebt wird, dann stimmt die gelebte Arbeit nie mit der offiziellen Stellenbeschreibung überein. Bei jedem Mitarbeiter sammeln sich kleine Zusatzaufgaben an, die leicht vergessen werden, aber die schmerzhaft auffallen, wenn sie in der neuen Organisation vergessen wurden. Dies kann den Start des Neuen unnötig schwer belasten.

 

Fragen, Feedback und Kommentare zu diesem Beitrag senden Sie bitte an r.janssen@acent.de

Rainer Janßen | 24.02.2023

Ähnliche Beiträge

15.08.2024 | Rainer Janßen

Ohne Strategie kein Blitzschach!

Mehr laden
Mehr laden
Weniger anzeigen
This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.