Mensch – Der zentrale Teil des Change Managements

Im Allgemeinen mögen Menschen keine Veränderungen oder auch: Menschen wehren sich nicht gegen Veränderung, sondern dagegen, verändert zu werden. Interessant ist jedoch: hat man eine Veränderung erst einmal eingeführt und die erste Zeit der Ablehnung ausgehalten, so wollen die wenigsten Menschen den alten Zustand zurück.

Für den Einstieg zum Thema Veränderung gibt es eine gute Übung welche aufzeigt, dass der Mensch lieber Veränderungen hat welche er selber machen will, als wenn man ihm eine Veränderung vorgibt:

Quelle: Unterlagen aus dem Unterricht

Wir haben diese Übung im Unterricht durchgeführt und das Resultat hat eindeutig ergeben, dass der oben erwähnte Satz voll und ganz zutrifft. Ich werde diese Übung auf jeden Fall im Arbeitsalltag anwenden.

Nach Erzählungen von anderen Teilnehmern des CAS bedingt eine Veränderung auch eine Veränderung der Mitarbeitenden in ihrem Verhalten. Daher ist eine erfolgreiche Veränderung auch abhängig davon, ob die Mitarbeitenden bereit sind ihr Verhalten zu ändern. Im Unterricht haben wir das SATIR MODEL von Steven M Smith kennengelernt. Es gibt jedoch noch andere Modelle wie beispielsweise das Transtheoretische Modell von James O. Prochaska, Carlo DiClemente und John Norcross. Dieses Modell hat sechs Stadien:

  1. Sorglosigkeit: Es gibt kein Problembewusstsein und damit wird kein Anlass für eine Verhaltensveränderung gesehen. Es wird noch nicht wahrgenommen oder auch verdrängt, dass möglicherweise ein Problem besteht
  2. Bewusstwerdung: Es wird anerkannt und akzeptiert, dass es ein Problem gibt. Es gibt jedoch noch keine konkreten Pläne zur Verhaltensänderung. Die Vor- und Nachteile einer möglichen Veränderung werden abgewogen und es wird sich oft intensiv mit dem Problem auseinandergesetzt
  3. Vorbereiten: Konkrete Ziele und Pläne über die Möglichkeit einer Veränderung werden gefasst
  4. Handeln: Das Verhalten wird aktiv verändert
  5. Dranbleiben: Das neue Verhalten muss aufrechterhalten werden. Ziel ist es, nicht in alte Routinen zu verfallen
  6. Stabilisieren: Die alten Gewohnheiten sind überwunden. Eine neue Routine wurde erlernt

Wichtig sind daher folgende Punkte:

  • IST – Transformation – SOLL: Den Mitarbeitenden nicht vermitteln wir wollen agil werden, sondern einen Grund nennen: sichere Arbeitsplätze in der Zukunft, Entwicklungsmöglichkeiten, etc.
  • Gute Vorbereitung: Der Veränderungsprozess muss gut durchdacht und vorbereitet sein
  • Integration der Mitarbeitenden: so kann die Haltung der Mitarbeitenden gegenüber dem Veränderungsprozess bereits beeinflusst werden
  • Motivation: Dadurch können sie angeregt werden, sich ebenfalls mit neuen Zielen zu beschäftigen, alte Gewohnheiten abzulegen und neue Verhaltensweisen auszuprobieren
  • Kommunikation: Regelmässig und offen über den aktuellen Stand, Fortschritt, Probleme, etc. kommunizieren
  • Befürworter identifizieren: Mitarbeitende identifizieren und diese als Sender einsetzen
  • Sorgen und Ängste: Es muss Anlaufstellen geben wo sich die Mitarbeitenden hinwenden können

 

Gemeinsames Verständis – Change Manifest – ein Navigationsinstrument im Change

Das Manifesto für agile Softwareentwicklung (https://agilemanifesto.org/iso/de/manifesto.html) hat folgende vier Werte definiert:

  1. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  2. Funktionierende Software ist wichtiger als umfassende Dokumentation
  3. Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen
  4. Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan

Das heisst, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Auf diesem Wertesystem wurden die 12 Prinzipien der agilen Bewegung formuliert. Sie sind eine Präzisierung der obigen Werte aus dem Manifest und eine Entscheidungshilfe bei tagtäglichen Aktivitäten im Projektgeschäft. Diese Prinzipien sind jedoch nicht Gegenstand dieser Arbeit.

Das Manifesto der Softwareentwicklung kann ins Lean Change Management adaptiert werden. Dazu haben wir den Auftrag erhalten, in kleinen Gruppen selber ein Change Manifesto zu erarbeiten. Wir haben uns die Frage gestellt: Was ist im Change wichtig, welches sind unsere wichtigsten Werte im Change und auf was können wir uns verlassen.

Das Change Manifesto unserer Gruppe:

  1. Leute mitnehmen vor Weisungen und Richtlinien
  2. Wertschätzen vor Fordern
  3. Zweckdienlich vor definierte Massnahmen umsetzen (der Weg kann ändern)
  4. Sinnstiftend und Motivation vor Zwang
  5. Ziele vor detaillierte Planung

Dieses Manifesto wurde geprüft, indem der «Sponsor» zu uns kam und nicht zufrieden war mit dem Fortschritt des Changes. Er wollte eine detaillierte Planung für die nächsten 6 Monate. Mit Hilfe des Manifestos mussten wir dann argumentieren warum wir das nicht als sinnvoll erachten.

Welche Erkenntnisse haben wir daraus gewonnen? Das Manifesto…

  • muss sichtbar geschrieben sein -> Argumentationsspielraum
  • dient als Orientierungshilfe
  • hilft innerhalb des Teams
  • dient als Fundament
  • gibt Leitplanken vor
  • und das Bedürfnis des «Sponsors» muss trotzdem herausgeschält und bedient werden

Ich finde die Erarbeitung eines Change Manifestos sehr wichtig und wir haben hier ein gutes Instrument kennengelernt welches für alle Beteiligten im Change Prozess als Hilfsmittel dient.

 

Lean Change Cycle – The Hot Seat- Strukturiertes Brainstorming um Optionen zu generieren

Der Hot Seat ist ein gutes Werkzeug um Optionen zu einem bestimmten Thema zu generieren. Der Ablauf dazu ist wie folgt:

Quelle: Unterlagen aus dem Unterricht

Diese Methode haben wir im Unterricht ebenfalls angewendet. In unserer Gruppe hat jemand vorgängig ein Problem geschildert (Thema). Anschliessend haben wir der Person auf dem Hot Seat Fragen gestellt und eine Person aus unserem Team hat die Antworten auf einem Flipchart zusammengefasst. Im nächsten Schritt hat sich die Person welche das Problem geschildert hat von unserer Gruppe weggedreht. Danach haben wir verschiedene Lösungsansätze genannt welche auf Post-ITs notiert wurden. Wichtig dabei war, dass die Person auf dem Hot Seat nichts sagen durfte. Zum Schluss mussten die Lösungsideen gewichtet werden. Das haben wir nach folgendem Vorgehen gemacht:

Quelle: Unterlagen aus dem Unterricht

Dabei ist folgendes zu beachten:

Die Lösungsvorschläge müssen RELATIV gewichtet werden! Was heisst das genau? Ich kann beispielsweise sagen, dass ein Handy schwerer ist als ein Kugelschreiber, aber ich kann nicht sagen wie schwer ein Kugelschreiber ist. Deshalb muss relativ gewichtet werden. Aus diesem Grund haben wir eine Lösung platziert und die anderen Lösungsvorschläge relativ zu diesem Vorschlag gewichtet und anschliessend platziert.

Bei dieser Methode habe ich verschiedene Erkenntnisse gewonnen:

  • ich erhalte neue Ideen
  • ich erhalte neue Sichtweisen
  • man muss genau nachfragen
  • die Person welche auf dem Hot Seat sitzt möchte gerne mitreden

Die Methode eignet sich bestens um im Arbeitsalltag eingesetzt zu werden und ich werde diese bestimmt anwenden.

Mein beruflicher Hintergrund liegt weniger in der Softwareentwicklung denn mehr im Business Consulting bzw. Business Process Engineering und darum habe ich dieses letzte Modul “Agile Transformation” am interessantesten gefunden. Bei meiner Arbeit dreht sich viel um Veränderung und der im Unterricht vermittelte Ansatz mit “Lean Change Management” finde ich äusserst interessant. Zwar transformiere ich weniger ganze Unternehmungen, doch immer wieder einzelne Teams, welche durch neue Rahmenbedingungen, neue Aufgaben übernehmen müssen und dabei stosse ich im besten Fall auf konstruktive Kritik, häufiger aber auf äusserst schwer auszuräumenden Widerstand der Betroffenen.

Mit Lean Change Management werden diese Widerstände an der Wurzel gepackt indem man den Menschen von Beginn weg stark im Change involviert und die Veränderung schrittweise angeht.

Betroffene zu Beteiligten machen
Für mich eine der wichtigsten Erkenntnisse aus dem Modul. Denn aufgezwungene Veränderung liebt keiner. Dies konnten wir sehr gut mit der Übung “Selbst-angestossene Veränderung vs. von aussen angestossene Veränderung” visualisieren.
Somit ist es sehr hilfreich, wenn die Menschen, welche von einem Change betroffen sind möglichst früh zu Beteiligten werden und so schon sehr früh Einfluss auf die Veränderung ausüben können.

Überhaupt ist es hilfreich, wenn die Betroffenen ein gemeinsames Verständnis zum Change haben. Eine gute Möglichkeit wie das gemeinsame Verständnis gefördert werden kann, ist ein Change Manifest. Angelehnt an das agile Manifesto werden auch bei einem Change Manifest die verschiedenen Werte eines Changes festgehalten und untereinander relativiert. Dies schafft Transparenz, senkt den Argumentationsspielraum und kann immer wieder als Fundament herbeigezogen werden.

Ebenfalls eine wichtige Erkenntnis für mich war die Einteilung der Betroffenen in “Movers, Movables und Immovables“. Weniger, dass es diese drei Arten von Menschen gibt, sondern viel mehr, dass alle drei Typen ihre Daseinsberechtigung haben.

  • Movers sind wichtig um einen Change zu starten. Sie sehen in der Veränderung immer einen Vorteil und nehmen diese als Chance wahr.
    Doch können sie ein Change Vorhaben auch gefährden, z.B. wenn das Vorhaben komplex bzw. langwierig ist und sie vor vollständiger Umsetzung schon wieder abspringen und neue Veränderung suchen.
  • Movables nehmen den Change an, sobald sie den Sinn und Nutzen aus den Erfahrungen mit den Movers erkennen können. Mit den Movables wird der Change etabliert.
    Falls aber der Sinn und Nutzen nicht erkennbar ist oder stark schwankt, können auch die Movables schwanken und den Change zum Kippen bringen.
  • Immovables sind die Bewahrer der Kostbarkeiten. Sie bewegen sich erst, wenn der Change etabliert ist und der Nutzen gross ist. Dieser Typ stellt sicher, dass bisherige Kostbarkeiten nicht unbedacht über Bord geworfen werden, sondern wenn sinnvoll auch in die “neue Welt” gerettet werden können.
    Wenn ein Change aber nur kleinen Nutzen bringt, besteht die Gefahr, dass die Immovables dem Change keine Chance geben und sich verweigern.

 

Nun haben wir die Betroffenen typisiert und zu Beteiligten gemacht. Jetzt sind wir bereit mit ihnen den Change mittels dem Lean Change Cycle umzusetzen.

Lean Change Cycle
Der Lean Change Cycle bietet eine agile Methode um iterativ mit jedem Durchlauf eine kleine Veränderung umzusetzen und so dem grossen Ziel schrittweise näher zu kommen. Dabei ist es nicht relevant, wo man mit dem Change startet, wenn ein gemeinsames Verständnis über alle Beteiligten vorhanden ist und genügend viele Iterationen durchlaufen werden, erreicht man die beste und von allen getragene Veränderung.

Der Lean Change Cycle durchläuft nachstehende Schritte:

  • Über Insights werden zunächst Einsichten gewonnen, was das eigentliche Problem ist, wer vom Problem betroffen ist, wer darunter leidet oder auch wer aus dem Problem Nutzen ziehen kann. Diese Einsichten sind aber nur subjektive Einschätzungen bzw. Vermutungen und müssen im Lean Change Cycle validiert werden.
  • Darum werden zu den vorgängig erhaltenen Einsichten nun Options ausgearbeitet, was, wie verändert werden kann, damit ein möglicher Nutzen entsteht. Hier werden mit geeigneten Methoden möglichst viele Ideen gesammelt und diese dann nach Kosten/Aufwand oder Wert/Nutzen klassifiziert.
  • Nun werden die erfolgversprechendsten Optionen über Experiments ausgewählt und umgesetzt.

Experimente werden in einem separaten Sub-Cycle durchgeführt:

  • Prepare: Zu einer gewählten Option werden Hypothesen über Ausgangs- und Zielzustand erstellt und Messgrössen festgelegt, wie das Experiment gemessen werden kann
  • Introduce: Die eigentliche Umsetzung der Veränderungsmassnahme.
  • Review: Aufgrund der eingangs festgelegten Messgrössen wird der Fortschritt und Erfolg der Veränderung geprüft.

Bei Lean Change Cycle ist wichtig zu verstehen, dass wir mit Hypothesen experimentieren und keine Garantie haben, dass das Gewünschte auch erreicht wird. Doch egal ob das Resultat des Experiments die Erwartungen erfüllt oder nicht, das Ergebnis ist immer hilfreich und kann als neue Einsicht in den nächsten Lean Change Cycle einfliessen.

Canvas
Zur Visualisierung des Changes ist es hilfreich den ganzen Change Prozess über geeignete Canvases allen Beteiligten zugänglich zu machen. Wir haben im Unterricht viele verschiedene Canvases kennengelernt, welche je nachdem, ob ein Change auf eine ganze Organisation oder ein Team wirken soll. Inhaltlich decken alle Canvases mehr oder weniger folgende Punkte ab:

  • Wozu dient die Veränderung
  • Wie soll der Zielzustand aussehen?
  • Was soll erreicht werden?
  • Wer ist von der Veränderung betroffen?
  • Wann wir was gemacht?

https://www.lean-change.de/prinzip/lean-change/

Die Visualisierung hilft allen Beteiligten den Überblick über den Change zu bewahren. Auch hilft ein Canvas den Change lebendig zu halten.

 

Fazit:
Einmal mehr nehme ich mit: Kurze Zyklen und erhaltene Erkenntnisse umgehend in die nächsten Schritte einfliessen lassen. Wichtig aber auch, dies nicht im stillen Kämmerchen zu tun, sondern alle Betroffenen einbinden und sie zu Beteiligten machen. So ist es ein Gemeinschaftswerk, das von allen getragen wird. Die Schwierigkeit sehe ich darin, dass Menschen unterschiedlich auf Veränderungen reagieren. Nichtsdestotrotz umso wichtiger, dass auch Movables und Immovables früh abgeholt werden bzw. auch Movers im Verlauf des Changes nicht fallen gelassen werden.

Dank des CAS Lehrgangs “Agile Organisation” habe ich gutes Rüstzeugs mit auf den Weg erhalten um als agiler Fahnenträger mit gutem Beispiel vorauszugehen. Vielleicht bin ich ja schon in der agilen Welt angekommen, habe ich doch die letzte Nacht den gleichen Traum in verschiedenen Iterationen durchlaufen! 😊

Was bisher geschah

Ich habe mich schon oft gefragt, wie eine Reorganisation besser ablaufen könnte? Bis vor kurzem sah ich vor allem zwei Möglichkeiten wie eine Reorganisation ablaufen kann. Die eine, zuerst Strukturen verändern und dann die Leute mit ins Boot nehmen. Die andere, zuerst die Leute mit ins Boot nehmen und erst dann an den Strukturen arbeiten. Beide Varianten machten mir mehr Kummer als Freude. Es war so wie das Huhn Ei Problem, eigentlich braucht man beides und beides gleichzeitig ist aber kaum möglich.

Beide Ansätze habe ich erlebt und beiden waren nicht besonders befriedigend. Die meisten Reorganisationen welche ich erlebte, waren von oben getrieben und bis ins Letzte durchdacht. Die Führungsriege hatte ganz viel Energie investiert um möglichst eine gute, optimale neue Struktur zu schaffen. Erst nach Einsetzung dieser, wurden die Nachteile erkannt. Zum einen weil sich Theorie und Praxis meist unterschieden, zum anderen sich viele Personen verändern mussten oder sich ihr Umfeld veränderte und dies auch Auswirkungen auf sie selber hatte. Viele haben nach Unzulänglichkeiten in der Lösung gesucht und diese in den Vordergrund gestellt, dies wohl weil die Lösung ihnen aufgedrückt wurde und die wenigsten das zu lösende Problem verstanden oder kannten. All diese Reorganisationen waren relativ gross und für die Mitarbeiter kaum verdaubar. Meist war auch nicht Klar weshalb es diese Reorganisation brauchte und welchen Sinn sie hatte. Selbst die Agilisierung von 150 Personen habe ich TopDown und auf einen Schlag umgesetzt erlebt. Das Requirementsengineering und das Testmanagement wurden in die Entwicklungsteams integriert, welche dann Scrum Teams hiessen. Meist wurde der Teamleiter zum Scrum Master und die Abteilungsleiter zu Tech POs und sie blieben weiterhin Linienvorgesetzte. Des Weiteren wurden aus den Fachabteilungen POs eingefordert und so die Produkte geformt. Man hat zwar ein Pilotprojekt-/produkt als POC laufen gelassen und so im Kleinen geübt. Der Pilot war jedoch noch nicht abgeschlossen als die Reorganisation per Datum durchgezogen wurde. (Dies in Kurzform) Ich habe mich im Modul Transformation öfters gefragt, was anderst hätte ablaufen können.

Ein kurze Beleuchtung des beschriebenen Changes mit dem Feedback Driven Ansatz und den zugehörigen Fünf Säulen:

Co-Created Change: Der Miteinbezug der Mitarbeiter beschränkte sich auf die oberste Führungsebene, also kein Einbezug zur Lösungserarbeitung. Vielleicht ein kleiner bei der Mitwirkung im POC. Im Grunde aber sehr stark von oben getrieben und umgesetzt.

People First: Auch der Ansatz von People First, also die Wichtigkeit der Mitarbeiter, ging meines Erachtens unter. Natürlich wurde der Change durch das HR unterstützt und begleitet. Dennoch blieben Mitarbeiter auf der Strecke und es hat viel Energie gebraucht um den Change durchzuziehen.

Adaptable: Die Lösung brauchte dies gar nicht, von oben getrieben und deshalb so umgesetzt.

Continous Planning & Execute: Kein Kontinuierliches umsetzen und planen. Zuerst lange geplant und danach in einem Changeprojekt per Datum umgesetzt.

Cause & Purpos Driven: Man hat zuvor die Kundenzufriedenheit zur Softwareentwicklung eingeholt und diese dann auch für den Change zugezogen. Ziel war es eine bessere Kundenzufriedenheit mit dem Change zu erreichen, was auch ausgewiesen werden konnte. Somit hatte man also ein Ursache und auch ein Wirkung des Changes zeigen könnten. Der Change steigerte die Kundenzufriedenheit klar.

Feedback Driven: Über das Ganze gesehen eher nicht. Mit dem POC wurde zwar ein Experiment mit einem einzelnen Team durchgeführt, das Feedback aus dem POC floss jedoch nicht erkennbar auf die über die gesamte Organisation gerollte Lösung ein.

Nun tönt das ganze sehr negativ, kaum Einbezug der Mitarbeiter, Wasserfall getrieben, Feedback getrieben auch nicht erkennbar. Dennoch behaupte ich, war das Ganze ein Erfolg. Dies mache ich vor allem daran fest wie wir heute Organisationprobleme versuchen zu lösen.

Heute versuchen wir das zu lösende Problem in den Mittelpunkt zu stellen. Dabei ist es wichtig bei den Leuten soweit ein Verständnis zu schaffen, dass sie das Problem auch als Problem erkennen und verstehen. Denn nicht jedes Problem einer Organisation ist auch direkt ein Problem für einen betroffenen Mitarbeiter. Danach versuchen wir mit den Mitarbeiter Lösungen für das Problem zu finden. Zum Beispiel haben wir vor kurzem in einem Self Designing Workshop, mit 50 Mitarbeitern, eine neue Struktur für ihre Organisation erarbeitet. Dabei haben die Mitarbeiter selber Lösungen erarbeitet und auch hart ausgefochten. Am Schluss stand eine neue Organisation, mit neuen Teams in total neuer Zusammensetzung da. Die neue Struktur wurde durch die Mitarbeiter selber entworfen und ausgearbeitet. Aus den Erfahrungen, versuchen wir nun WS für andere Organisationsteile zu gestalten. Wobei immer zu beachten ist, dass immer andere Probleme gelöst werden müssen. Dennoch können gemachte Erfahrungen genutzt und möchten wir Fehler nicht zweimal machen. Wir leben dabei stark den Ansatz aus der Soziokratie 3.0 “Good enough for now, Safe enough to try”. Wir machen also Expiremente und versuchen aus diesen zu lernen.

Dieses andere Vorgehen führe ich auf die Veränderung des Verhaltens zurück, welches sich in den letzten fünf Jahren stark verändert hat. Eine Veränderung welche durch andere Verhältnisse geschaffen wurde. Ein mehr oder minder “gewaltsames” Verändern von Verhältnissen durch den agilen Change, hat bei vielen Mitarbeitern im Laufe der Zeit nun das Verhalten und zum Teil auch die Haltung verändert. Diese Veränderung ist jedoch sehr Individuell und auch nicht überall gleich stark wahrzunehmen. Dennoch ist sie stark zu spüren. Vor gut einem Jahr wurde eine Kulturinitiative von Mitarbeitern angestossen und in einem Team von 5 Mitarbeitern durchgeführt und über die ganze Softwarentwicklung ausgerollt, das wäre früher nicht denkbar gewesen. Den Einschub im Modul, dass es eine Veränderung in den Verhältnissen braucht um ein Verhalten zu beeinflussen, fand ich einleuchtend und konnte ich bei uns gut erkennen. Ich denke aber auch, dass dies auch missbraucht werden kann und es ein schmaler Grat hin zur Manipulation ist.

Soweit meine Analyse mit den gewonnen Erkenntnissen auf die Vergangenheit, hier ein Versuch was ich aus dem Modul anwenden möchte.

Ausblick

Folgende Punkte aus dem Modul möchte ich in meinem Berufsalltag einfliessen lassen.

Change Canvas

Ich erhoffe mir durch die Nutzung von Change Canvas eine bessere Fokussierung auf die Problemstellung, da diese immer ersichtlich bleibt. So glaube ich ist es einfacher das Problem welches gelöst werden soll immer vor Augen zu haben. Ausserdem finde ich hilft es bei der Schaffung von Transparenz im Change. Das Canvas bleibt im Fokus und kann jederzeit ohne Suche in einem Tool wieder angeschaut werden. Es hilft dabei sich Beschlüsse, Experimente wieder in Erinnerung zu rufen. Aktuell sind wir an einem Change, welcher über mehrere WS erarbeitet wurde, und in welchen wir nun ein Experiment starten, dort wäre ein Canvas ideal. Die Zeit im Januar erlaubt es mir hoffentlich dieses zu erstellen

Lean Change Cycle

Insights: Ich möchte noch bewusster die Ausgangslage beleuchten und so den Problemen wirklich auf den Grund gehen. Also zuerst das Warum beleuchten und erst dann das Wie.

Options: Ich möchte in Zukunft noch klarer machen, was nicht verändert werden soll und warum dies nicht verändert werden soll. Dies war für mich eine wichtige Erkenntnis der ich in der Vergangenheit zu wenig Beachtung geschenkt hatte. Ich finde in unseren Teams fokussieren wir uns zu stark nur auf die Veränderung.

Expirements: Hier möchte ich der Hypothese mehr Beachtung schenken. Klarer machen, was wir mit dem Experiment zu erreichen gedenken und wie wir feststellen ob wir die Hypothese bestätigen können oder verwerfen müssen. Die daraus gewonnenen Erkenntnisse sollen dann auch in die nächsten Experimente einfliessen.

Ausserdem versuche ich die Veränderung noch mehr als ständigen Prozess zu sehen und auch so zu gestalten.

Movers/Movables/Immovables

Auch wenn die Mitarbeiter die Lösung selber gestalten können, so muss sich die Gruppe am Schluss doch für eine Lösung entscheiden und dies ist nicht die präferierte Lösung von allen. Deshalb gibt es auch bei einer selbstgestalteten Lösung alle drei Gruppen von Mitarbeitern und dessen muss man sich immer bewusst sein. Man muss sich im Klaren sein, dass man alle drei Gruppen betrachten muss und auch wieviel Energie man in die einzelnen Gruppen investiert. Es bringt nichts, alle Energie in die Immovables zu stecken und am Schluss die Movers zu verlieren, weil sie sich vernachlässigt fühlen. Es braucht also hier eine Ausgewogenheit an Berücksichtigung der einzelnen Gruppen um einen Erfolgreichen Change realisieren zu können. Am besten ist es natürlich, wenn die Movers selber die Movables überzeugen können und so die Immovables auch immer mehr zu Movables werden.

Change Manifest

Fand ich sehr spannend. Wir haben uns bis anhin Grundsätze kreiert und versucht diese umzusetzen. Grundsätze beschreiben aber meist einen Idealzustand und Idealzustände gibt es meist nur in der Theorie. Gerade beim aktuellen Change habe ich mir gedacht, warum haben wir nicht “A ist uns wichtiger als B” definiert statt nur das A zu beschreiben. Denn den Idealzustand konnten wir schon nicht umsetzen …

Ich glaube wenn ich diese vier Vorgehen im Alltag verankert habe, so werde ich mir überlegen, was ich des Weiteren brauchen. Ganz getreu dem Motto, in kleinen Schritte zum Ziel.

Nebst all den Vorgehen und Werkzeugen glaube ich aber ist der Umgang untereinander der wichtigste Nährboden um erfolgreiche Changes zu bewältigen. Die Soziale Sicherheit die einem eine Organisation vermittelt denke ich ist der Grundstein um überhaupt einen stetigen Change erfolgreich vorantreiben zu können.

Mit diesem Modul schliesst sich für mich der Kreis. Ich habe vor allem mit dem Agile Organisation und dem Agile Transformation Modul Werkzeuge gekriegt, die mir meinen Horizont erweitert haben. Sie erlauben es mir hoffentlich in Zukunft, meine Teams noch besser unterstützen zu können. Ich denke ich kann in Zukunft auch mehr Inputs in unsere Organisation geben und so eine Weiterentwicklung nicht nur begleiten sondern auch mitgestalten.

Ausgangslage

Das letzte Modul im CAS agile Organisation, agile Transformationen, startet in einem grossen Raum mit vielen leeren Pinwänden und Flipcharts. Zugegeben, das gab mir – einem bekennenden Methodenskeptiker – ein bisschen ein mulmiges Gefühl im Sinne von «was kommt den da alles auf uns zu». Denn ich bekenne ich mich offen und ehrlich zum Motto «warum nid eifach mache» anstatt die Themen in allen bunten Farben und Formen «zu Tode» zu malen.

Zum Schluss war ich äusserst positiv überrascht, aber dazu später mehr. Nachfolgend ein paar ausgewählte, persönliche Highlights des Moduls: – sie bestechen alle durch dem Umstand äusserst «lean» zu sein.

 

 

 

 

 

 

 

 

 

Changes, resp. Veränderungen

Das Leben besteht – egal ob beruflich oder privat – zu einem grossen Teil aus Veränderungen. Gewisse sind aktiv gesucht, andere kommen von aussen auf uns zu. In einer ersten Trainingseinheit machten wir uns Gedanken, wie wir emotional a) zu selbst gesuchten Changes b) zu von aussen an uns herangebrachten Veränderungen stehen. Eine – auf den ersten Blick – triviale Übung, welche transparent macht wie ungern wir in der Tendenz Veränderungen haben, welche wir nicht selber angestrebt haben. Eine Tatsache, die zwar allgemein bekannt ist, aber nicht genug in Erinnerung gerufen werden kann. Besonders für Führungskräfte, die sich fragen, warum «Change auf Befehl» nicht zum Ziel führt.

 

 

 

 

 

 

 

 

 

 

Change Manifest

Angelehnt am agilen Manifest haben wir ein Change Manifest erstellt. Bei einem Change Manifest geht es darum, die wichtigen Werte innerhalb eines Change vorhaben gemeinsam zu definieren und transparent zu machen. Auch hier gilt es, dies nicht im stillen Kämmerlein zu machen, sondern das Team INKLUSIVE der wichtigsten Stakeholder einzubeziehen. Das Manifest dient dazu, gerade sich gerade in turbulenten Zeiten auf die gemeinsamen Abmachungen zu besinnen. Die beindruckend simple Form eignet sich aber nicht nur für Changes sondern eigentlich für jede Lebenslage. Egal ob beruflich oder privat. So habe ich gerade mein persönliches 2019 Manifest erstellt

 

 

 

 

 

SCARF Modell

In diesem Modell geht es um Übertragung von Neurowissenschaften in bekannte Managementtheorien. Das Wort SCARF setzt sich aus den Anfangsbuchstaben folgender Worte zusammen. Diese fünf Gebiete sozialer Erfahrungen hält unser Gehirn nach Rock für überlebenswichtig

  • Status
  • Autonomy
  • Relatedness
  • Fairness

Wirklich gute Führungskräfte scheinen dieses Modell unbewusst anzuwenden. Indem sie ihren Mitarbeitern vor Augen führen, was sie an ihrer Arbeit gut finden, steigern sie beispielswese deren Status. Sie haben eine klare Vorstellung, wie die Arbeit „inszeniert“ werden muss und kommunizieren diese, bis sie das gewünschte Ergebnis haben. Dabei wissen die Mitarbeiter, dass sie jeweils die beste Leistung einfordern. Damit vermitteln sie Sicherheit. Dabei achten Sie aber auch darauf, dass sich jeder persönlich einbringen kann und wahren dadurch Autonomie. Sie wissen jederzeit, wie sich die Mitarbeiter fühlen, nehmen Rücksicht auf deren Belange und achten so auf eine Verbundenheit mit ihnen. Und sie behandeln ihre Mitarbeiter jederzeit fair.

Im Rahmen des Unterrichts haben wir diese Werte für uns selber und im Team priorisiert und transparent gemacht. Eine sehr gute, einfache Methode um sich selber zu reflektieren und am System zu arbeiten. Das Modelle kann beliebig adaptiert werden und sollte nicht erst eingesetzt werden, wenn bereits Konfliktsituationen vorliegenl

 

Vgl. https://lead-conduct.de/2015/05/03/scarf-modell-vermeidet-teamkonflikte/

 

 

 

 

 

 

 

 

Hot Seat

Wenn man vor lauter Bäumen den Wald nicht mehr sehen kann, eignet sich der Hot Seat. Der Issue Owner sitzt mit dem Rücken zum Team und erklärt das Problem. Anschliessend sammelt die Gruppe Ideen, wie dieses gelöst werden könnte: Die Lösungen werden anschliessend nach Kosten / Nutzen eingeordnet und dem Issueowner übergeben

 

 

 

 

 

Vgl. https://leanchange.org/resources/hotseat/

Canvas

Das Business Model ein Mittel um beliebige komplexe Zusammenhänge auf einem Stück Papier abzubilden.  Es gibt eine Vielzahl von Vorlagen zu den gängigsten Themenblöcken, welche nur darauf warten, befüllt zu werden. Es gilt nur die Vorlage auszudrucken und bereits kann diese mit ersten Gedanken befüllt werden. Im Unterricht haben wir nach der initialen Interation mit vier Feedbackschlaufen gearbeitet. Dabei war es sehr interessant zu sehen, wie viele zusätzliche Ideen durch die eingeholten Feedbacks generiert werden konnten. Auch hier ist es somit elementar, nicht im «stillen Kämmerlein» zu arbeiten sondern möglichst früh die Gedanken mit Dritten zu teilen und wenn möglich Experimente zu wagen.

 

 

 

 

 

Vgl https://www.startplatz.de/startup-wiki/business-model-canvas/

Fazit

Ich bin äusserst positiv überrascht. Ein ganzer Koffer voller Werkzeuge, welche nicht nur «das System» sondern auch den Faktor «Mensch» berücksichtigen. Und erst noch schlank und flexibel in der Anwendung. Massgeschneidert und prädestiniert für Macher. Ich freue mich die praktische Anwendung. Weil: es gibt nichts Gutes, ausser man tut es.

Die Zeit verging im Flug und schon schreibe ich meinen letzten Blog. Diesmal zum Thema Agile Transformation von Pit Zurkirchen.

Das Fazit vorgezogen kann ich sagen, dass ich dieses Modul am Spannendsten erlebt habe. Lean Change, dachte ich mir. Die Aspekte von Change ändern sich kaum, nur weil ein Projekt agil umgesetzt wird. Doch Pit Zurkirchen holte früher aus, d.h. was Menschen zu Veränderungen bewegt, was es auslöst bzw. was es mit ihnen macht. Erst dann brachte er die mir bekannten Aspekte aus Change. Und ich lernte über das SCARF Modell, Veränderungsmodelle wie das 3-Phasen Modell (Lewin), die emotionale Veränderungskurve (Kübler-Ross) oder das psychologische Satir-Modell (Satir). Diese zahlreichen Inhalte und Themen aus der Kommunikations-, Psychologie-, Qualitätsmanagement-Toolbox wurden nun kombiniert. Die Kombination machte es letztlich lehrreich für mich und ich freue mich, in einem meiner nächsten Projekte das Erlernte anzuwenden.

 

Um meine nachstehenden Überlegungen und Interpretationen zum in diesem Modul neu Erlernten zu begründen, möchte ich die Arbeitswelt umschreiben, denen ich in Changeprojekten nach wie vor begegne. Dies gilt selbstverständlich nicht als Pauschalisierung, doch weitestgehend so oder ähnlich verlaufende Gegebenheiten. Mit Pit Zurkirchen vermittelten Inhalte jedoch lernte ich, dass meine Erwartung nach mehr Sinnhaftig-, Handhabbar- und Verstehbarkeit in einem Changeprojekt offenbar doch mit Systematik existiert, einen Namen hat und der Aspekt «Lean» nicht nur ein Märchen von morgen ist. Doch nun zu meinem Arbeitsalltag als Unternehmungsberaterin:

 

Wie oft in meinem Arbeitsalltag bezüglich Change-Projekten denke ich mir «schon wieder wird eine Organisation nach dem «budgetierten» oder «politisch verträglichen» Fahrplan umgesetzt. So werden nicht selten – und abhängig von den Erfahrungen des Projektleiters – die 8 Stufen (Kotter) des Changes mehr oder weniger gleichmässig und linear in den Projektplan eingebettet. D.h. wieviel Zeit, welche Phase in der Organisation benötigen «darf» wird im Voraus phasenweise verteilt. Zwar spricht man von Wirksamkeit der Massnahmen, erfolgskritische Faktoren wie die Beteiligung der Mitarbeitenden. Doch blicke ich auf meine Statussitzungen mit Auftraggebenden, bzw. sog. Steering Committee Meetings, so wird wenig Zeit für die Überprüfung und Anpassung der Insights oder Changezustand besprochen. Meist geht es um schnelle Meilensteinerreichung – um möglichst schlank «durch zu kommen». Die Projektnamen besiegeln förmlich die Projektpriorität mit Bezeichnungen wie «Fast Track», «Speed-Up» oder «RC», das für «Reduce Complexity» stand und statt Komplexität als Rahmenbedingung zu nehmen und damit zu arbeiten, versucht wurde, in der Organisation zu glätten bis hin aufzuheben. Die Besiegelung all dieser weniger optimalen Vorgehensweisen erfolgt dann noch mit Erfolgsboni sowie Halteprämien. Damit wird den Entscheidungsträgern und Projektleiter der Anreiz für die Einhaltung des Projektplanes und quantitative Projektziele geschaffen oder für sog. Key-Player-Mitarbeitende Prämien angeboten, damit sie das Unternehmen währendes Changes «trotzdem» nicht verlassen.

 

 

Der Lean Change Management Cycle (LCM)

Summary

Betrachte ich den obigen Zyklus von LCM, so sind sie mir nicht ganz fremd. Ob RADAR aus EFQM, DMAIC aus SixSigma oder PDCA (Deming/QM), es geht hauptsächlich um die konsequente Einhaltung der Systematik. Hier sehe ich auch den wesentlichen Unterschied zwischen LCM und meinen (plangetriebenen/klassischen) Vorgehensweisen. Die hohe Gewichtung von Zusammenarbeit, Qualität, Werte, die Erlaubnis von einer «fail fast and better»-Kultur sind bei LCM handlungsleitender und verankern viel stärker die Changemassnahmen. Auf einzelne möchte ich nachstehend vertiefter eingehen.

 

Der Hauptunterschied besteht also in der Fähigkeit, das Projekt einerseits voranzutreiben, das Spektrum jedoch auf die Entwicklungen, Feedback, Bedarf und Ideen zu erweitern. Erst auf dieser Grundlage können Changeprojekte das volle Potenzial entfalten. Die Erkenntnisse pro Iteration dienen demnach als Wegbeschreibung, von der aus stimmig und erfolgreicher gehandelt werden kann.

Aus meiner Sicht ein deutlich anspruchsvolleres Vorgehen. Raum, Zeit und Individualität zuzulassen und trotzdem das Projektziel zu «beherrschen», erfordert sehr viel mehr Empathie und Kompetenzen von allen Beteiligten. Sicherlich ist dieses agile Vorgehen kein Garant für das Gelingen eines Changes, doch die typischen Widerstände werden sicherlich gemindert, gemildert und Akzeptanz durch Beteiligung über alle acht Phasen des Changes, gekürzt.

 

 

Iteratives Vorgehen

Anders als beim oben beschriebenen Fall, wird in LCM schrittweise und teilweise iterativ vorgegangen. Ziel ist pro Schritt möglichst viel richtungsweisende Erkenntnisse und Feedback aus der Organisation zu erhalten, um den Change bedarfsgerechter weiter zu steuern und entwickeln. Der Change-Verlauf wird demnach kontinuierlich geprüft und darauf basierend die Planung der nächsten Massnahmen angepasst.

 

Insights

Zu Beginn ist es erforderlich, das zu lösende Problem zu verstehen, um daraus die richtigen Massnahmen und Hypothesen aufzustellen. Eine Aufgabe, mit der sich meine Auftraggebenden kaum aufhalten (möchten). Viel eher liegt ihr Fokus auf dem Ziel und dem Massnahmenplan dahin. Doch zurück zum Erlernten. Eine systematische Ursachenanalyse mit beispielsweise Ishikawa oder 5W hilft nicht nur die Vielschichtigkeit der zu verändernden Thematik zu erkennen und verstehen. Darauf basierend werden Hypothesen gebildet, was zur Folge hat, dass in einer so frühen Phase schon entscheidende Weichen richtig oder falsch gestellt werden können.

 

Options

Anders als in meiner Praxis, wo der Weg vorgängig weitestgehend statisch geplant und höchstens Pufferzeiten für Unvorhergesehenes eingebaut werden, werden hier basierend auf die identifizierten Ursachen mehrere Hypothesen beziehungsweise Lösungsoptionen gebildet. Das bedeutet, mehrere Massnahmen und Szenarien werden so formuliert, dass dabei die Frage beantwortet werden kann, wie eine zu verändernde Situation oder das Problem möglicherweise (auch) gelöst werden kann. Diese Optionen können verschiedenen Rahmenbedingungen Rechnung tragen und sich deshalb auch voneinander unterscheiden.

 

Experiments

Hier werden zu den Hypothesen Experimente gefahren, die nun die Hypothese bestätigen oder widerlegen. Der Unterschied zur eingangs erwähnter Vorgehensweise ist, dass durch das Ziel, möglichst viele Erkenntnisse zu sammeln, diejenigen, die sich als falsche Hypothese ergeben, mindestens so wichtig sind, wie diejenigen, die sich bestätigen lassen. Und selbstverständlich experimentiert man nicht ins Blaue hinaus. Diese Optionen werden wie in allen Investitionsthemen und das Aufwand-/Nutzenverhältnis gegenseitig erwogen. Je nach Firmenkultur sehe ich hier dieselben Hürden, wie in jedem anderen Projekt mit Investitionen. Die Wozu-Frage leidet nicht selten unter der Wieviel- oder Wie-Lange-Frage.

Umso wichtiger ist die Wozu-Frage gegenwärtig zu halten, welches Problem lösen wir damit und was benötigt es nun dafür? Die vorgängige Festlegung von Kennzahlen und Indikatoren, die eine Hypothese Zahlen-Daten-Fakten basiert bestätigen oder widerlegen sind eine weitere Massnahme zur Zielorientierung und Qualitätssicherung. Und auch hier sehe ich eine weitere Herausforderung. In der Praxis stelle ich fest, dass das Verständnis für Kennzahlen und Indikatoren sehr unterschiedlich ist und je nach Ergebnis (u/o Politik) sie einfach weggelassen werden.

Diese Experimente werden so lange durchgeführt bis alle Hypothesen bzw. Massnahmen abgearbeitet sind – vergleichbar mit dem PDCA-Regelkreis (Deming) nur mit einer zusätzlichen Iteration in der Iteration. Vergleichbar mit der Scrum-Iteration, bestehen die Experimente aus einer eigenen Sub-Iteration mit folgenden Teilleistungen:

  • Prepare– Vorbereitung der Option zur Umsetzung inkl. Bestimmung Messgrössen, KPIs, Indikatoren.
  • Introduce– Umsetzung der Optionen und Gewinnung der Erkenntnisse und Feedbacks.
  • Review– Validierung der Ergebnisse, Erkenntnisse auf das zu lösende Problem bezogen und diesbezüglich vorgängig geplanten KPIs/Indikatoren. Insbesondere dieser Punkt wird in meiner Praxis zu wenig konsequent bis gar nicht durchgeführt, zumindest was die Erfahrungen betrifft, wie auch die Qualität der Zusammenarbeit ist.

 

Der LCM-Cycle ist eingebettet in einen Kontext und Rahmenbedingungen und prägen massgeblich die oben beschriebenen Hypothesen in ihrer diesbezüglichen Ursache. Teile davon werden nachstehend mit Vergleichen zu meinen Projekt-Rahmenbedingungen in Changeprojekten zusammengefasst. Ausserdem werde auf den ebenfalls in der Grafik abgebildete Canvas eingehen.

 

People

Auch Beteiligte werden stark eingebunden und in ihrem Standpunkt sozusagen typisiert. Diese Typisierung nach Movers, Movables, Immovables klingt zunächst missverständlich. Doch basiert die Kategorisierung auf Aspekte, wie sie einleitend mit SCARF etc. beschrieben, bzw. systematisch identifiziert wurden. Ausserdem wird nicht nur anfänglich, sondern kontinuierlich der Entwicklungsstand der Beteiligten und ihrem Mind-Set erwogen und ermöglicht auch bedürfnis- und bedarfsgerechtere Massnahmen. Zumal die Betroffenen sich auch selbst einschätzen können. Dies verschafft die Möglichkeit, dass der Stand der Veränderung realistischer eingeschätzt werden kann.

Auch die Dauer der Change-Phasen relativiert und individualisiert sich bezüglich Handlungsbedarfes und auf Basis der gewonnen Einschätzung. Zwar besagt Kotters Modell, dass Beteiligte in unterschiedlichen Phasen des Changes abzuholen sind. Von LCM erfuhr ich nun jedoch, wie weiter damit umgegangen werden soll.

 

Selbstverständlich sehe ich auch die Gefahren dieser Typisierung. Zu schnell können voreilige Schlüsse darüber gezogen werden, wie sich jemand verhält und wie mit ihm umgegangen oder gar ignoriert wird. Doch diese Gefahr besteht in jeder Form der Vorgehensweise. Diese Gefahr mache ich auch vom Reifegrad und Kultur der Organisation abhängig, wobei ich mir gut vorstellen kann, dass auch hier agilere Vorgehensweisen diese Gefahr weniger bieten, weil der Mindset schon eine ganz andere ist.

 

Lean Change Canvas

Der Canvas ist eine einfachste Form der Planung, Umsetzung und Transparenz und stellt die Aufgaben und ihren aktuellen Stand dar. Der Fortschritt kann dann durch Heftnotizen-Umplatzierungen verwaltet werden und visualisiert den Projektstatus at a Glace. Auf dieser Grundlage können Diskussionen einfacher geführt werden, wenn die Konversion nicht im gewünschten Masse vorangeht oder Anpassungen im Vorgehen erforderlich werden.

 

Unter den zahlreichen Canvas arbeitete ich bisher mit dem Business Canvas Modell von Osterwalder/Pigneur. Je nach Detaillierungsstufe des Abzubildenden, können die Inhalte von strategischer bis Einzeltätigkeitsstufe kaskadiert werden und unterscheiden sich dementsprechend in den Feldbezeichnungen. Beim Lean Canvas geht es um die Umsetzung des Projektes, weswegen folgende Inhalte grundsätzlich thematisiert werden sollten:

  • Wozu: Ziel-/Sinnfrage
  • Was: Experimente
  • Wie: Umsetzung
  • Wer: Beteiligte/Bereich
  • Wann: Friste, Termine

 

Die Sichtbarmachung der Aufgaben und ihre Stati ist in agilen Projekten deutlich wichtiger, als in meinen bisherigen Changeprojekten. Die Visualisierung ist allerdings sehr einfach und kreativ gehalten. D.h. während für meine bisherigen Status-Meetings zeitintensive Folien für die Führung erstellt werden, die den Stand des Fortschrittes in Management-Folien wiedergeben, wird hier wahrscheinlich ein Foto des Canvas-Boards gemacht und diese in einer Managementpräsentation abgebildet. Ich würde – nach all dem Gelernten- sogar einen Schritt weitergehen und bei einfacheren Fällen die oberste Führung dazu einladen, den Projektstatus direkt vor dem Board durchzuführen. Zum einen, weil es Teamergebnisse zum Projekt nichts Vertrauliches sind, und zum anderen, um den Bezug und Committment hoch zu halten.

 

Zu Praxistipp LCM: «Are failed experiments really failing, or is the organization not ready for change?»

Nebst den oben aufgeführten Insights nehme ich diese Aussage mit.

 

Sie erinnerte mich unweigerlich an einen vor langen Jahren gelernten Ansatz: «Können – Wollen – Dürfen». Dieser besagt, dass eine gute Leistung – im vorliegenden Fall ist die Leistung der Change – nur möglich ist, wenn die drei Komponenten im Gleichgewicht sind. Ist dem nicht so, werden Ziele nicht oder nur teilweise erreicht, die Motivation sinkt und das fach- und firmenspezifische Wissen geht verloren. Die Konsequenz in Changeprojekten daraus sind schlechte Ergebnisse, Frustration der Beteiligten bis hin zu Abbruch u/o Neustart von Change-Rollouts.

 

Beispiel:

  • Nur weil eine Organisation den Change will
    (weil z.B. Markt Anpassung und damit Change erfordert) und
  • die Führung den Change als Massnahme erkennt und genehmigt (Dürfen),
  • ist die Organisation für die Transformation und Change nicht zwingend bereit und fähig (Können);

 

Denn oft dachte ich mir, dass der Kern mancher meiner Projekte der ist, dass die Organisation für den Change gar nicht bereit ist. Ein Dilemma für jede Unternehmungsberaterin. Da einerseits eine Optimierung und Wertschöpfung durch mich angestrebt wird, und andererseits diesbezüglich bei der Führung (Auftraggeber) diesbezüglich auf taube Ohren stosse wird.

 

Hilfreich wäre hier ein Tipp gewesen, wie mit solchen Organisationen umgegangen werden kann. Selber versuche ich diese Herausforderung mit der Wozu-Frage in Erinnerung zu rufen und lasse die Führung ausarbeiten, welche Voraussetzungen für das Projekt wichtig bis hin zu kritische Erfolgsfaktoren sind.

 

Canvas Model

Die Zitate „Ich schreibe Dir einen langen Brief, weil ich für einen kurzen keine Zeit habe.“ [Unbekannt: Goethe; von Kleist, Blaise u.a. sind denkbar] und “Nicht zu Ende Gedachtes beansprucht viele Wörter” [Axel Haitzer] beschreiben Vieles, was in Zusammenhang mit der Nutzung von Übersichten nach Canvas wichtig erscheint. Das Business Model Canvas wurde ursprünglich durch A. Osterwald entwickelt. Es sollte vor allem Start-Ups dazu dienen, auf eine effiziente Art und Weise ihre Business Modelle zu erarbeiten und darzustellen. Wobei A. Osterwald betont, damit nicht etwas komplett Neues erfunden zu haben, sondern ein Werkzeug, das einfach verständlich ist und rasch genutzt werden kann.[1] Das Business Model Canvas besticht durch seine Übersichtlichkeit. Gegenüber einem “Management Summary” in Prosa oder gar einem viele Seiten umfassenden Konzept, sind dank seiner Struktur die wesentliche Punkte rasch ersichtlich. Es ist daher nicht verwunderlich, dass Übersichten nach Canvas auch in der «Lean Welt», insbesondere im Bereich “Lean Change Management” ihren Platz gefunden haben. Selbstverständlich sind die Themenblöcke anders und müssen je nach Bedarf individuell angepasst werden. Dennoch erfüllen sie auch hier ihren Zweck: Neben der Übersicht, zwingt sie die Autoren, sich kurz zu fassen und sich auf Kernaussagen zu beschränken.

Change Prozess

Die Einfachheit einer Canvas-Übersicht, kann zum Gedanken verleiten, dass das Erstellen kaum mit Aufwand verbunden ist. Die Übersicht stellt jedoch lediglich das Ergebnis oder Zwischenergebnis eines unter Umständen langen, aufwändigen und insbesondere in Zusammenhang mit Change, anstrengenden Prozesses dar. Wie der Prozess für das Entwickeln der Ergebnisse angegangen wird, ist von verschiedenen Faktoren abhängig. Insbesondere wichtig sind:

1. Changebedarf

In einem ersten Schritt sollte abgeschätzt werden, wie tiefgreifend oder umfassend ein Change sein wird. Wie ist das zu lösende Problem einzustufen? Ein Umzug ist dabei anders einzuordnen, als eine Veränderung des Vorgehens zur Produktentwicklung. Für die Einordnung kann das durch W. Häfele entwickelte Organisationsmodell dienen.

Abbildung 1:Abbildung 5: MCV-Organisationsmodell nach W. Häfele

2. Firmenkultur

Neben des Change Bedarfs wird vor allem auch die bestehende Firmenkultur den Prozess und dessen Dauer beeinflussen. Sowohl Lean Change Management als auch die Systemische Organisationsberatung legen Wert darauf, dass Mitarbeitende in den Prozess einbezogen werden. Je nach Kultur muss hierfür aber erst die Basis aufgebaut werden um den Change Prozess erfolgreich zu gestalten. Dazu gehört vor allem auch der Aufbau von Vertrauen und Mut um aktiv am Prozess mitzuarbeiten.

3. Mitarbeitende

Mitarbeitende reagieren unterschiedlich auf Veränderungen. Neben Befürwortern gibt es die unterschiedlichsten Abstufungen, bis hin zu Personen die eine Veränderung komplett ablehnen. Jedoch müssen alle durch die verschiedenen Stufen der Veränderung gehen, lediglich die dafür beanspruchte Zeit ist unterschiedlich.[2] Sich bei der Realisierung eines Changes nur auf die Befürworter zu konzentrieren, ist so falsch wie dessen Gegenteil. Die Kunst wird es sein, hier den für das konkrete Unternehmen und den geplanten Change die richtige Dosierung von Beidem zu finden.

Gleichzeitig ist zu berücksichtigen, dass ein früher Einbezug aller Mitarbeitenden nicht immer sinnvoll ist. Veränderungen sind immer mit Verunsicherungen verbunden. Je länger die Unsicherheit andauert und von welchem Ausmass des Change die Mitarbeiterinnen und Mitarbeiter ausgehen (z.B. welchen Einfluss ein Change auf einzelne Mitarbeiterinnen und Mitarbeiter hat), desto höher ist das Risiko, dass auch Schlüsselpersonen das Unternehmen während des Change Prozesses verlassen.

Kein Plan ist auch ein Plan

Sowohl Lean Change Management als auch die Systemische Organisationsberatung gehen von der Haltung aus, dass die Lösung eines Problems zu Beginn eines Change Prozesses nicht bekannt ist. Es kann daher zu Beginn des Prozesses nicht festgelegt werden, wann welche Teile des Changes abgeschlossen sein werden. Davon abzuleiten, dass gar keine Planung erforderlich ist, wäre jedoch zu kurz gegriffen. Dies nicht nur, weil das Management eine solche verlangt. Ein Plan gibt Orientierung und kann helfen, den Change Prozess so effizient wie möglich zu gestalten. Eine klassische Projektplanung mit zielorientierten Meilensteinen ist dabei wenig hilfreich und nicht realistisch. Hingegen kann eine Planung zeigen, wie der Prozess gestaltet wird. Beispielsweise kann eine Change-Planung enthalten, welche Prozessschritte wann und in welcher Form angegangen werden (z.B. Workshops, Umfragen oder Interviews). Dies wiederum kann viel dazu beitragen, dass die einzelnen Massnahmen auch realisiert werden können. Involvierte Personen haben so die Möglichkeit, die erforderlichen Zeitfenster einzuplanen und stehen bei Bedarf auch tatsächlich zur Verfügung. Selbstverständlich muss es zulässig sein, die ursprüngliche Planung an neue Gegebenheiten anzupassen.

[1] Vgl. Startwerk 2012

[2] Vgl. Leistungsnachweis Agile Basic «4-Zimmermodell»

In unserem letzten Modul in unserem CAS Agile Organisation haben wir uns zusammen mit Peter Zurkirchen mit dem Thema Lean Change Management beschäftigt.

Im Vorfeld zu diesem Modul wurde uns mehrmals angekündigt, dass all die Basisgrundlagen, welche wir uns im letzten halben Jahr erarbeitet haben, hier zu einem schlüssigen Ganzen zusammengefügt werden.

In der Tat waren diese vier Tage für das Hauptthema “Agile Organisation” dann auch sehr lehrreich und interessant. Interessanterweise haben gab mir dieser Inhalt die Bestätigung für eine Erkenntnis, welche mir während unserer Projektarbeit richtig bewusst wurde: Mir bekannte agile Vorgehensweisen und Techniken können in einem beliebigen Kontext bei der Lösung von Problemstellungen und Aufgaben gewinnbringend eingesetzt werden.

Alles Lean oder was?

So habe ich in der Lehre von “Lean Change Management” sehr viele Parallelen zu den mir bekannten Vorgehensweisen von “Lean Innovation” gefunden.

Es war mir anfangs nicht bewusst, aber ich habe eine solche Adaption bereits in meiner bisherigen Arbeit unterbewusst getan. Nachdem ich das Buch “Running Lean: Iterate from Plan A to a Plan That Works” von Ash Maurya gelesen und einen entsprechenden Workshop besucht habe, wollte ich dieses Vorgehen auch für meine Projekte adaptieren. Ash Maurya hat bei seinem Inhalt vor allem junge Startup-Unternehmen im Visier. Jedoch war es mir möglich, die Grundideen auch für meine Projekte in einem mittelgrossen KMU zu adaptieren. Aus ersten Kundeninterviews entstand eine Grundidee für ein neues Produkt, Hypothesen wurden aufgestellt, diese Hypothesen wurden mit  Experimenten bestätigt oder verworfen und im darauf folgenden Analyseprozess wurden neue Erkenntnisse in die nächste Entwicklungsiteration gebracht. Erste Pretotypes und Teilfunktionen wurden iterativ mit unseren Early Adopters getestet und verifiziert, ganz nach dem bei Lean allgegenwärtigen Motto: “build – measure – learn”.

Wie bereits erwähnt habe ich während unserer Projektarbeit eine vergleichbare Erfahrung gemacht. Nachdem unsere Zusammenarbeitsform anfänglich nicht funktioniert hat, haben wir unsere Vorgehensweise in einem Experiment auf eine Scrum-basierte Form angepasst. Unsere Hypothese war, dass wir mit einer agilen Vorgehensweise iterativ bei unserer Projektarbeit zu einem Ziel kommen könnten.  Wir wählten Scrum, weil wir alle damit bereits mehrjährige Erfahrung damit aufweisen. Wir hatten folglich einwöchige Sprints, unsere Dailys haben wir per WhatsApp-Nachrichten durchgeführt. Jeweils am Samstag nach den Kursen hielten wir ein Review, ein Planning und teilweise auch eine Retro. Ab diesem Moment hat das Erarbeiten der gemeinsamen Projektarbeit sehr gut geklappt. Mir wurde klar, dass gewisse agile Methodiken durchaus für eine beliebige Aufgabe des Lebens angewendet werden kann.

“Lean Change Management” tut nichts anderes. Bekannte Methodiken aus den diversen “Lean”-Vorgehensweisen werden hier aufgegriffen und auf ein neues Feld, nämlich das des Change-Managements adaptiert. Dass es trügerisch ist, einen Change-Prozess mit einer Wasserfall-Vorgehensweise zu planen und durchzuführen ist jedem klar, welcher schon einmal an einem solchen Vorhaben beteiligt war. Obwohl man fixe Pläne durchdrücken kann, so wird das daraus entstandene Resultat nicht funktionieren. Denn Vorhersagen und Prognosen können nie so genau sein wie dies Resultate und der Einbezug der betroffenen Menschen sind. Die bekannten Agilen Grundsätze gelten auch hier: Experimentieren mit einem daraus resultierenden “fail fast” ist viel effizienter und wertvoller als das sture festhalten an eingefahrenen und bekannten Lösungswegen.

Insights

Daraus entsteht die Grundlage von Lean Change Management. Zuerst ist es nötig das Problem zu verstehen. Was ist genau das Problem, welches man lösen möchte? Dies erscheint auf den ersten Blick sehr einfach und logisch. Bei genauer Betrachtung zeigt sich in vielen Fällen, dass man sich der eigentlich Problematik nur oberflächlich bewusst ist und die Ursache für ein Problem oft viel tiefer liegt oder vielschichtiger ist. Aus meiner Sicht entscheidet sich der Erfolg oder Misserfolg eines Change-Prozesses ganz oft bei diesem ersten Schritt.

Options

Hat man das eigentliche Problem eruiert, geht es darum Optionen zu bilden. Welches wären mögliche Ansätze um eine Verhalten zu verändern oder ein Problem zu lösen? Hier geht es darum Hypothesen zu bilden und zu beurteilen, welche dieser Optionen am Erfolg versprechendsten ist. Wir durften eine ganze Reihe solcher Beurteilungsmethoden kennen lernen.

Experiments

Aus den ausgewählten Hypothesen können anschliessend Experimente abgeleitet werden. Sie sollen die Richtigkeit einer Hypothese bestätigen oder widerlegen. Ob die Hypothese richtig oder falsch war spielt dabei nur eine untergeordnete Rolle. Jedes Resultat bringt eine Erkenntnis um die Problemstellung oder ein Sachverhalt besser zu verstehen. Deshalb ist es von zentraler Bedeutung, dass Experimente eindeutig messbar sind. Nur mit einem klar beurteilbaren Resultat können beim Review des Experiments die richtigen Schlüsse als Grundlage für eine nächste Verbesserungs-Iteration gezogen werden. Das Festlegen der richtigen KPI’s oder Messartefakte ist für mich neben der genauen Analyse der Problemstellung die grösste Schwierigkeit bei der Beurteilung eines Experimentes oder Hypothese.

Das Beste kommt zum Schluss

Genau hier sind wir bei dem für mich zentralen Punkt angelangt. Dies ist das Thema, welches mich sehr interessiert und mich dazu bewogen hat den “CAS Agile Organisation” zu besuchen. Ich weiss nun ganz genau, dass es kein geheimes Wundermittel gibt um unsere Organisationen zu renovieren und zu revolutionieren. Es gibt wunderbare Tools und Methodiken, welche einem dabei sehr gut unterstützen und gute Hilfestellungen bieten, das Verhalten einer Organisation, Teams und Menschen zu verändern. Manche Methodiken sind gehyped oder ähneln einem Evangelium. Manchmal ist es einfach nur modern eine Technik zu verwenden, ohne den tieferen Sinn des Ganzen verstanden zu haben. Man wird all dies einsetzen können und man wird keine Garantie auf Erfolg haben.

Denn am Schluss muss man die Lösung für seine spezifische Aufgabenstellung selber finden und erarbeiten müssen.

Denn hier ist es wie im richtigen Leben – es gibt keine Abkürzungen.

Nachtrag

Es war für mich sehr spannend, lehrreich und sehr bereichernd mich regelmässig mit einer Gruppe von anfangs fremden Menschen während mehrerer Monate mit den verschiedensten agilen Themen auseinander gesetzt zu haben. Ich habe von diesen Menschen ganz viel gelernt. Manchmal ist der Weg das Ziel ( und nicht irgendwelche fancy Organisationsformen). Ich komme zurück auf meinen ersten Blogeintrag, wo der Mensch im Zentrum stand. Und ja, ich habe meine Antwort gefunden auf die Frage, ob sich eigentlich alles um den Menschen dreht.

Meine Antwort heisst: Ja, glücklicherweise.

Wie heisst deine Antwort?

Das letzte Modul des CAS Agile Organisation. Jetzt soll alles zusammenlaufen und ich bin gespannt, ob sich alle Teile wie in einem Spinnennetz zusammenfügen.
Insgesamt war für mich dieses Modul der beste Teil. Nicht nur weil ich für meinen Arbeitsalltag am meisten mitnehmen kann, sondern auch, weil es Peter Zurkirchen als Dozent sehr gut gelungen ist das Wissen zu diesem Thema zu vermitteln. Die Tage waren kurzweilig, spannend, bunt und es gab viel Interaktion. Ich habe gespürt, dass dieses Thema ganz Peters Welt ist. Super!
Aber haben sich nun alle Teile zu einem Puzzle zusammengefügt? Nach einigem Nachdenken möchte ich diese Frage für mich nicht mit einem einfachen ja oder nein beantworten.
Der Fokus der Tage dieses Moduls lag weniger auf dem Zusammenfügen. Zumindest war das mein Eindruck. Natürlich steckten die anderen Themen in unseren Köpfen, also in den Köpfen der Teilnehmer des Kurses. Natürlich haben wir in der Praxisarbeit Beispiele aus unserem Arbeitsalltag gewählt und dies waren natürlich immer Beispiele mit einem agilen Hintergrund. Doch glaube ich, dass dieses Modul nicht wirklich die anderen CAS-Module als Basis benötigt hat.
Auf der anderen Seite glaube ich, dass wir während der Dauer des CAS auch an unserem Mindset und agilen Verständnis gearbeitet haben. Dies hilft natürlich den Ansatz des Lean Change Management besser und schneller zu verstehen. Immerhin ist der Ansatz für sich agil und unterscheidet sich daher vom klassischen Change Management.
Wer etwas auf sich hält kann Canvas…
Canvases spriessen ja wie Pilze aus dem Boden. Nicht immer leicht das richtige Canvas für die aktuelle Situation zu finden. Es gibt unzählige und auch wir haben drei, oder waren es vier…nein fünft…kennengelernt. Der Einsatz ist nicht immer einfach umzusetzen. Oft sind Begrifflichkeiten und Kategorien generalisiert und deshalb in der Praxis schwer zu verstehen. Mit anderen Worten: Es braucht etwas Übung für den effizienten Einsatz in einem Workshop. Trotzdem helfen diese „One-Pager“ zu strukturieren und am Ende eines Workshops ein Resultat vorzuweisen, welches dann auch noch dokumentiert ist.
Ich kann der Sammlung auch noch eines hinzufügen. Ausgehend von einem Canvas von Ast Maurya, dem Customer Forces Canvas (https://blog.leanstack.com/the-updated-problem-interview-script-and-a-new-canvas-1e43ff267a5d) habe ich folgende genutzt: Team Forces Change Canvas
Zwei Produktteams, welche technisch auf einer Plattform arbeiten aber ganz unterschiedliche Kunden bedienen, haben den Wunsch geäussert, sich in der Zusammenarbeit zu verbessern. Historisch wurden die Teams einmal zusammengestellt durch damalige Vorgesetzte und es war über einen längeren Zeitraum Unzufriedenheit spürbar bzgl. dieses Setups. Ziel war es also grundsätzlich herauszufinden, wie man den Setup oder die Zusammenarbeit der Teams verbessern kann. Treiber sollten nicht Vorgesetzte sein, sondern die Teams selber. Ganz im Sinne selbstorganisierter Teams!
In einem ersten Workshop habe ich mit Vertretern der Teams das Ziel verfolgt zu verstehen, was den Willen zur Veränderung treibt. Was schürt die Unzufriedenheit?
Im Rahmen dieses ersten Workshops haben wir Insights gesammelt. Wir haben uns also auf den ersten Teil (1-3) der Team Forces Change Canvas konzentriert. Zu diesem Zweck habe ich ein einfaches Canvas erstellt.
Diese haben Aufschluss darüber gegeben, welches die eigentlichen Treiber sind. Zudem waren wir mit diesen Insights in der Lage ein gemeinsames Verständnis in der Gruppe zu bilden und eine Priorisierung vorzunehmen. Beides hat uns in der späteren Lösungssuche stark unterstützt. Diese einmal gefundenen Insights konnten wir in Folge-Workshops immer wieder aufhängen, um beispielsweise erarbeitete Lösungsansätze diesen Findings entgegen zu setzten.
Allen war klar, dass es nicht „die“ ideale Lösung gibt. Vielmehr ist die Situation komplexer und bedarf mehrer Schritte, die aufeinander aufbauen.
So war klar, dass sich die unterschiedlichen Lösungsansätze in mehreren Experimenten widerspiegelten. Zur Zeit werden diese Experimente – wenn nicht schon in der Durchführung – ins Leben gerufen. Die Scrum Master der beteiligten Teams unterstützen dieses Experimentieren. Bleibt die Aufgabe diesen bzw. einen übergreifenden Verbesserungsprozess noch als kontinuierliche Retrospektive zu etablieren.
Das war nun der letzte Blog von meiner Seite. Nun hoffe ich, dass diese 20 x 5 Einträge final auch einen Nutzen stiften für zukünftige Leser. Bedeutet also, dass eine Lebenszeit des Blog gibt, die dies zulässt.
Allen Lesern wünsche ich somit:
Viel Spass und gutes Gelingen beim Experimentieren

Nun sind wir beim letzten Modul des CAS Agile Organisation… Im Rahmen von Agile Transformation haben wir uns mit Lean Change Management beschäftigt.

Wie alles andere bisher – das Konfliktmanagement, die Selbstreflexion oder die Selbstorganisation, auch Change Management ist nicht erst mit der Agilität der Organisationen entstanden. Nur beim klassischen Change Management ist man anders vorgegangen. Es wurde im Voraus ganz genau bestimmt wie die Veränderung ablaufen soll, was verändert werden sollte und der Zeitplan war auch so genau bestimmt. Die grösste Unterschied zum Vorgang in Agilen Organisationen ist, dass es im Verlauf von Veränderungsprozess der Zustand nie überprüft oder angepasst wurde. Unabhängig von Reaktionen auf die Veränderung, man hatte die Massnahmen oder die Planung nicht geändert. Weiterhin wurden die Betroffenen nie in das Change Prozess einbezogen, ob mit ihrer Ideen oder ihrem Feedback. Das führte oft dazu, dass die Veränderung scheitert und man auf starken Widerstand bei den Mitarbeitern stosst.

Mit der „Ära der Agilität“ hat man eingesehen, dass es die Meinung jeder Einzelnen wichtiger als je ist und, dass man nicht blind den Plan verfolgen kann, sondern muss fähig sein auf die Veränderungen zu reagieren. Hier sind wir beim Lean Change Management – einer iterativen und inkrementellen Vorgehensweise für Change Management. Ein schnelles Feedback und die Reaktion darauf sind das Kern dieses agilen Change Managements. Grundsätzlich geht es darum die Organisation bei den Veränderungen zu ‚spüren’. Mit laufenden Experimenten wird die Organisation verändert. Es ist essenziell, dass auch jeder einzelnen verstanden wird und, dass alle Betroffenen berücksichtigt sind.

Lean Startup

Lean Change Management basiert auf dem Lean Start-up Prinzip:

„Die Beteiligten verändern iterativ und inkrementell und testen die Veränderungen noch auf dem Papier, bevor sie diese selbst umsetzen.“

Also steuern die Beteiligten selbst den Inhalt, Umfang und Geschwindigkeit der Veränderung. Bei den Startups besteht oft die Unsicherheit über den Weg zur Zielerreichung. Selbst die Ziele können sich laufend verändern. Das führt dazu, dass sich die Planung immer mehr relativiert und die Unsicherheiten auf eine andere Weise beseitigt werden müssen als mit dem Folgen eines starren Plans. Der Fokus ist gesetzt auf Hypothesen, Ideen, Experimente und natürlich schnelle Feedbacks. Es geht um den Umgang mit der Unsicherheit bei der Produktentwicklung.

Lean Startup Cycle:

Die drei Schlüsselprinzipien der Lean Startup-Methode sind:

  • Ausgangspunkt sind immer Hypothesen
  • „Get out of the building!“ – es ist essenziel „das Gebäude zu verlassen“, um die Nutzer, Kunden und Partner zu treffen und mit ihnen die Hypothesen des Business Modells zu überprüfen
  • iterative und inkrementelle Entwicklung des Produktes – um Verschwendung von Zeit und Geld zu vermeiden, wird im Gegensatz zur herkömmlichen Vorgehensweise das Produkt iterativ und inkrementell entwickelt

Lean Change Management

Lean Startup-Prinzip wendet man im Change Management an. Die Idee von Lean Change ist – es gibt keine Planung, die Veränderung wird iterativ und inkrementell entwickelt und umgesetzt. Die Erkenntnisse werden bei nächster Umsetzung implementiert. Die Feedbacks und die Resultate von nicht gewünschten Ergebnissen werden ebenfalls im nächsten Schritt berücksichtigt. Betroffenen werden Beteiligten. Sie sind involviert bei der Entwicklung, Gestaltung des Inhalts und der Umsetzung. Dadurch, dass die Beteiligten die Grösse der einzelnen Schritten der Veränderung bestimmten, können sie direkt den Einfluss auf die Geschwindigkeit der Veränderung nehmen.

Lean Change folgt folgende Leitsätze:

  • Betroffene werden zu Beteiligten, indem sie die Veränderung selbst erstellen und durchführen
  • Die Beteiligten verändern iterativ und inkrementell in für sie passenden Teilen
  • Die Beteiligten validieren diese Teile gemeinsam – bevor sie diese selbständig durchführen

Der Lean Change Cycle

Das Vorgehen im Lean Change Management kann analog zum Lean Startup Cycle in einem Kreislauf – dem Lean Change Cycle – abgebildet werden. Dieser umfasst Insights – Options – Experiments. In jedem Durchlauf des Lean Change Cycles wird eine (kleine) Veränderung umgesetzt.

  • Insights– die Einsichten darüber gewinnen, was das Problem ist, was das Problem hinter dem Problem sein könnte, wer möglicherweise Nutzen aus dem Problem zieht, etc.
  • Options– aufbauend auf den Einsichten werden die Optionen generiert, was wie verändert werden könnte. Hier geht es noch nicht um Realisierbarkeit, sondern darum, möglichst viele Ideen zu sammeln.
  • Experiments– eine der Optionen wird ausgewählt und umgesetzt. Weil es sich hier um die Hypothesen handelt, werden diese Optionen als Experimente

Zu den Experimenten gibt es einen eigenen Sub-Cycle:

  • Prepare– hier wird die Umsetzung der gewählten Option vorbereitet.
  • Introduce– die aus der Option entwickelte Veränderungsmassnahme werden umgesetzt.
  • Review– anhand der in Prepare definierten Messgrössen werden Fortschritt und Erfolg der Veränderung gemessen und aus den Ergebnissen neue Einsichten gewonnen. Diese werden in Insights eingebracht und der Kreislauf beginnt von neuem.

Der Sub-Cycle wird solange wiederholt, bis die Veränderung komplett umgesetzt ist.

Lean Change Canvas

Bei der Lean Change Canvas geht es um die Visualisierung des ganzen Change Prozesses. Die Visualisierung spielt im agilen Umfeld eine grosse Rolle. Das Change Canvas ist ein visuelles Werkzeug für das Change Management. Damit wird die Veränderung und den Transformationsprozess in einer Organisation unterstützt und die Kommunikation und die Transparenz gefördert. Unabhängig welche Formen der Canvas man wählt, das wichtigste ist es, dass sie zu den individuellen Besonderheiten der Organisation passen. Ein Canvas soll folgende Aspekte der Veränderung darstellen:

  • WOZU/WARUM
  • WIE
  • WAS
  • WER
  • WANN

Fazit

Mein Fazit zur Thema Lean Change Management ist, dass es ein Weg zur lernenden Organisation ist. Ich finde, dass es zwingend und notwendig ist alle Beteiligten in einer Organisation einzubeziehen und durch die Experimente und kurze Wiederholungsphasen zu lernen. So wird die Selbständigkeit, sowie Selbstorganisation und die kontinuierliche Verbesserung gefördert.

In dem letzten Modul des CAS Agile Organisation haben wir uns mit der agilen Transformation beschäftigt, hierbei wurde die Methode «Lean Change Management» von Jason Little detailliert vorgestellt und anhand von Praxisübungen vertieft. Im Zentrum dieser Methode steht der Lean Change Cycle:

Abbildung 1: Lean Change Cycle aus Lean Change Management von Jason Little

Die vorgestellte Methode erinnerte mich als «Ingenieur» sehr an Qualitätssicherungsprozesse. Erste implementierte Prozesse finden sich bereits in den 1930er, hier sei der Shewhart-Zyklus genannt.

Abbildung 2: Shewart-Zyklus

Shewart hatte hier bereits alle Elemente ausreichend definiert, wie eines seiner Zitate darlegt: «Diese drei Schritte müssen in einem Kreis verlaufen … Es kann hilfreich sein, sich die drei Schritte als wissenschaftliche Methode in den Massenprozessen vorzustellen. In diesen Sinne korrespondieren Spezifikation, Produktion und Prüfen mit ‚Hypothese erstellen‘, ‚Experiment durchführen‘ und ‚Überprüfen der Hypothese‘. Diese drei Schritte stellen einen dynamischen, wissenschaftlichen Prozess des Wissenserwerbs dar.» (R. Moen, C. Norman: Evolution of the PDCA Cycle). Ferner verweist er auf wissenschaftliches Arbeiten, welches seit Jahrhunderten bereits diesem einfachen Zyklus folgt. Dieser Zyklus wurde schnell zur allgemeinen Form Plan-Do-Ceck-Act-Zyklus (PDCA) durch W. Edwards Deming in den 1950ern weiterentwickelt. Schon Deming stellte dabei den betroffenen Menschen in den Mittelpunkt der Problemlösung, da er selbst Anhänger des Human-Relations-Ansatzes war. Zusammenfassend war Deming der Meinung, dass nur durch die betroffenen Menschen am Ort des Geschehens die Lösung des Problems erfolgen kann. Irgendwie ein Déjà-Vu zum Kursmodul, doch im Kern fasst ein Jahrhundert alt oder sogar noch älter?!

Abbildung 3: PDCA-Zyklus

Beim PDCA-Zyklus können die folgenden Analogien zum Lean Change Cycle gezogen werden (die Unterpunkte sind nicht voll umfänglich, sie sollen nur die Überschneidungen und die Kernelemente vereinfacht darstellen):

Plan

·      Analyse des aktuellen Zustands

·      Erkennen von Verbesserungspotentialen

·      Entwickeln eines neuen Konzeptes

Insights

·      Analyse des aktuellen Zustands

Options

·      Erkennen von Verbesserungspotentialen

Experiments

·      Entwickeln eines neuen Konzeptes

 

Do

·      Vorbereitungen treffen

·      Ausprobieren beziehungsweise Testen und praktische Optimieren des Konzeptes mit schnell realisierbaren, einfachen Mitteln

Experiments (Prepare)

·      Vorbereitungen treffen

Experiments (Introduce)

·      Einführen

Check

·      Resultate werden sorgfältig überprüft

Experiments (Review)

·      Resultate werden sorgfältig überprüft

Act

·      Transformation, Einführung auf breiter Front

Kein Äquivalent

Auf dieser Flughöhe ist kein Unterschied für mich in der Methodik zu erkennen. Eine weitere, umfangreichere und derzeit in der Industrie stark eingesetzte Methodik ist SixSigma, die ebenfalls ihren Ursprung in der Qualitätssicherung findet. Dabei baut SixSigma auf dem Define-Measure-Analyse-Improve-Control-Zyklus (DMAIC) auf.

Abbildung 4: DMAIC-Zyklus

Ich möchte an dieser Stelle die einzelnen vorgestellten Werkzeuge aus dem Lean Change Management den einzelnen Phasen des DMAIC-Zykluses zuordnen:

Phase DMAIC-Zyklus Werkzeug Lean Change Management
Define

Leitfrage: «Was ist das Problem?»

Inhalt:

·      Definition des Problems

·      Klären der Kundenbedürfnisse

·      Stakeholder-Analyse

·      Definition messbares Projektergebnis

·      Planung

·      Anwendung des SCRAF-Modells (oder «Moving Motivators») bei der Stakeholderanalyse, sowie Ermittlung des «Blast Radius of the Change» inkl. «Movers, Movables, Immovables»-Analyse

·      Lean Change Canvas begleitend zur Visualisierung

·      Anwendung Hot Seat Methode zur Klärung der Kundenbedürfnisse

·      Retrospektiven und Lean Coffee zur Problemdefinition

Measure

Leitfrage: «Wie gross ist das Problem?»

Inhalt:

·      Datensammlung

·      Statistik

·      Messkriterien

·      Lean Change Canvas begleitend zur Visualisierung

·      Hypothesendefinition mit Fokus auf

«Measuring Change»

 

Analyse

Leitfrage: «Was sind die Hauptursachen für das Problem?»

Inhalt:

·      Prozessvisualisierung

·      Ursachenforschung

·      Einfussfaktoren

·      Lean Change Canvas begleitend zur Visualisierung

·      Wertstromanalyse

·      Anwendung Hot Seat Methode zur Ursachenforschung

·      Retrospektiven und Lean Coffee zur Ursachenforschung

·      Hypothesendefinition mit Fokus auf

Ursachen und Einflussfaktoren

Improve

Leitfrage: «Wie sieht die Lösung aus?»

Inhalt:

·      Lösung für die wichtigsten Ursachen

·      Bewertung der Lösung

·      Auswahl der Lösung

·      Transformationsplan

·      Ausrollen von Piloten

·      Lean Change Canvas begleitend zur Visualisierung

·      Hypothesendefinition abschliessen und Experimente ableiten

·      Relative «Cost-Value-Analysis» zur Bewertung und Auswahl

Control

Leitfrage: «Wie stellen wir eine Nachhaltigkeit sicher?»

Inhalt:

·      Kontrollplan

·      Dokumentation

·      Lean Change Canvas begleitend zur Visualisierung und Dokumentierung

·      Retrospektiven und Lean Coffee zur Festigung der Lösung

·      Erneute Stakeholderanalyse inkl. «Movers, Movables, Immovables»-Analyse

 

Eine gute Übersicht zum DMAIC-Zyklus inkl. Werkzeuge für die einzelnen Phasen kann auf Wikipedia.de gefunden werden. Zusammenfassend zeigt diese Gegenüberstellung wiederum, dass das Kursmodul «Agile Transformation» nichts Neues an Werkzeugen beinhaltet. In meinem Umfeld sehe ich jedoch einen kleinen aber vielleicht wichtigen Unterschied: Der Schwerpunkt im Kursmodul «Agile Transformation» liegt beim Menschen und rückt ihn in den Mittelpunkt. Im Gegensatz dazu ist der DMAIC-Zyklus auf Effizienz und Exekution ausgerichtet, der Mensch bzw. besser die Problemursachen durch menschliche Interaktion werden nicht ursächlich beseitigt, sondern die Interaktion wird standardisiert. Dies ist bei komplizierten Aufgaben sicherlich zielführend, jedoch kann so keine Innovation auf komplexe Fragestellungen erfolgen.

Nun noch ein kleines Feedback zum Kursmodul. Was bleibt? Ich fand es ein sehr umfangreiches und gelungenes Kursmodul mit der richtigen Balance aus Theorie und Praxis. Einen grossen Dank an Pit! Ich konnte das eine oder andere Element meinem persönlichen Werkzeugkasten hinzufügen. Nach einer Woche der Reflektion zu den 4 Halbtagen fehlen mir persönlich wichtige Elemente in diesem Kursmodul. Diese Elemente beziehen sich auf den Faktor «Mensch» (Abschliessend eigentlich die wichtigste Komponente in der Agilität). Hier einige Leitfragen zu Punkten die mir zu wenig thematisiert werden:

  • Wie soll ich mit Immovables umgehen?
  • Wie soll ich mit politischen Spielchen in der Hierarchie umgehen?
  • Wie bereitet man ein Alignement auf menschlicher Ebene vor?
  • Wie schafft man einen Raum des menschlichen Vertrauens und Offenheit?
  • Wie geht man mit enttäuschten Erwartungen im Change menschlich um?
  • Wie vermeidet man «Glaubenskriege»?
  • Wie stärke ich zwischenmenschliche Werte?
  • ….

Dies sind nur einige Leitfragen, die mir durch den Kopf gehen, auf die es wahrscheinlich kein Patentrezept gibt. Aber sicherlich Erfahrungen aus verschiedenen Handlungsoptionen. Diese sollten in der nächsten Durchführung des CAS Agile Organisation einfliessen. Damit das Thema «Mensch» greifbarer wird und eine Flughöhe einnimmt die anschaulich wird.

Nun noch zur Beantwortung der Leitfrage dieses Berichts: «Agile Transformation», des Kaisers neue Kleider? – Meine persönliche Antwort: Nein, nichts Neues im Westen! «Agil» liegt im Trend des pfiffigen Schneiders, der die alten Klamotten des Kaisers im Vintagetrend «aufpimpt».

 

keep looking »