Organizational Change Management: Hoffnung ist keine Methode
Diesen Sommer habe ich etwas getan, das ich jedem empfehle, der seit Jahren «Transformation» sagt: Ich habe mich prüfen lassen. Drei APMG-Prüfungen im Change Management – Foundation, Practitioner, dazu das Trainer-Assessment – und dazwischen viele Abende mit dem Study Guide. Nicht weil mir langweilig war, sondern weil mir in zwanzig Jahren Beratung ein Muster keine Ruhe lässt: Wir scheitern fast nie an der Technik. Wir scheitern an den Menschen, die mit der Technik arbeiten sollen.
Und das Unangenehme daran: Für die Technik haben wir Frameworks, Pipelines und Zertifikate im Überfluss. Für die Menschen haben wir – Hoffnung. Ein Kick-off, ein Newsletter, ein Foliensatz «Warum wir uns verändern». Hoffnung ist aber keine Methode.
Warum das Thema auf devops.ch gehört
Wer meine Kulturrevolution-Serie kennt, weiss: Kultur ist der Kern jeder Transformation. Und im Readiness-Artikel habe ich beschrieben, wie man mit den drei Lücken – Wissen, Methode, Erlebnis – herausfindet, wo es klemmt. Was dann noch fehlt, ist das Handwerk, die Lücken systematisch zu schliessen. Genau das ist Organizational Change Management (OCM): kein weiches Beiwerk, sondern die Disziplin, die aus «wir führen DevOps ein» ein «wir arbeiten wirklich anders» macht.
Das APMG-Zertifizierungsschema, entwickelt mit dem Change Management Institute, bündelt dazu, was die Forschung seit Jahrzehnten weiss – von der individuellen Veränderung über Teams bis zur Organisation. Nichts davon ist Zauberei. Aber es ist eben ein Wissensgebiet, kein Bauchgefühl.
Veränderung passiert pro Kopf, nicht pro Rollout
Die erste Einsicht, die jede DevOps-Initiative ernst nehmen sollte: Organisationen ändern sich nicht – Menschen ändern sich, einer nach dem anderen, und jeder durchläuft dabei seine eigene Kurve. Zwischen «ich habe davon gehört» und «ich kann das» liegt ein Tal, das die Lernforschung präzise kennt: der Moment der bewussten Inkompetenz, in dem die neue Arbeitsweise noch holpert und die alte plötzlich sehr attraktiv aussieht. Wer in diesem Tal keine Unterstützung bekommt – Zeit, Coaching, Fehlertoleranz –, kehrt um. Und zwar völlig rational.
Deshalb ist «Widerstand» in den allermeisten Fällen auch kein Charakterfehler der Belegschaft, sondern Information: Da signalisiert jemand, dass eine der drei Lücken offen ist. Wer Widerstand wegmoderieren will statt ihn zu lesen, verschenkt die beste Diagnostik, die eine Transformation hat.
Die kritische Masse statt der grossen Ansage
Die zweite Einsicht: Veränderung skaliert nicht über Ansagen, sondern über Netzwerke. John Kotter – ja, der mit den acht Schritten – hat sein eigenes Modell weiterentwickelt: weg vom einmaligen Programm, hin zu einer «Volunteer Army», einem freiwilligen Netzwerk von Menschen, die die Veränderung tragen, quer zur Hierarchie. Das ist übrigens exakt das, was in DevOps-Transformationen funktioniert, wenn es funktioniert: nicht das Operating-Model-Poster, sondern die fünfzehn Leute aus verschiedenen Teams, die es unbedingt wollen – und denen man Raum gibt.
Dazu gehört die ehrliche Unterscheidung, wie viel Mitgestaltung wirklich drin liegt: Verkünde ich (Tell), werbe ich (Sell), beteilige ich (Include) oder gestalten wir gemeinsam (Co-Design)? Jede Stufe ist manchmal richtig. Verlogen wird es nur, wenn Co-Design draufsteht und Tell drin ist – das merken Menschen sofort, und das Vertrauen ist schwerer zurückzuholen als jede Deployment-Pipeline.
Was das für DevOps-Initiativen konkret heisst
Wenn ich heute eine DevOps- oder Plattform-Initiative begleite, gehören für mich drei Dinge von Anfang an ins Setup – gleichberechtigt neben Toolchain und Betriebsmodell: ein echtes Bild der Betroffenheit (wer verliert was, wer gewinnt was – Rollen, Status, Gewohnheiten), eine Change-Architektur, die pro Zielgruppe die passende Intervention wählt statt «ein Training für alle», und Sponsoren, die sichtbar vorangehen statt nur zu genehmigen. Nichts davon ist teuer. Alles davon ist billiger als eine Transformation, die im dritten Anlauf wieder beim Kick-off steht.
Mein Fazit
DevOps hat uns gelehrt, Deployment-Schmerz nicht als Naturgesetz zu akzeptieren, sondern als lösbares Problem zu behandeln. Es ist Zeit, den Veränderungs-Schmerz genauso zu behandeln: mit Handwerk statt Hoffnung. Organizational Change Management ist dieses Handwerk – erlernbar, prüfbar, anwendbar. Ich habe die Prüfungen hinter mir; die eigentliche Prüfung findet aber jeden Tag in den Organisationen statt. Packen wir es an.
In eigener Sache: Wer das Handwerk lernen will – bei Glenfis gibt es die APMG-zertifizierte Organizational-Change-Management-Ausbildung jetzt aus erster Hand. Und für alle anderen: Mehr zu diesem Thema bald an dieser Stelle.
Quellen und weiterführende Links
- APMG International: Change Management Certification – das Zertifizierungsschema (Foundation/Practitioner)
- Change Management Institute – die Fachorganisation hinter dem Body of Knowledge
- Kotter: 8 Steps for Leading Change – die acht Schritte und ihre Weiterentwicklung zum Netzwerk-Modell
- Die Kulturrevolution – Serie auf devops.ch und Agile Readiness – die Vorarbeiten zu diesem Artikel