Lektionen aus dem Change Management
So sehr wir uns auch wünschen, dass all unsere Projekte und Prozesse reibungslos ablaufen – Veränderungen, ob groß oder klein, sind unvermeidlich. Akzeptieren wir also, dass Wandel kommen wird. Was können wir nun tun, um sicherzustellen, dass wir die Unterstützung der Stakeholder auf allen Ebenen gewinnen und dass diese Veränderung souverän gemeistert wird?
Am 9. Mai treffen sich DPM-Mitglieder, um auf unsere persönlichen Erfahrungen zurückzugreifen, Geschichten auszutauschen und über Ansätze im Change Management zu sprechen. Wir teilen unser Wissen über die effektive Umsetzung von Veränderungen und diskutieren, was gut und weniger gut gelaufen ist.
[00:00:00] Großartig. Vielen Dank an alle, die heute dabei sind. Wir werden heute über Change Management sprechen. Das Thema ist in letzter Zeit oft in unserem Chat aufgetaucht. Deshalb dachte ich mir, dass es Zeit ist, einige Leute zusammenzubringen, um über die Dinge zu sprechen, die gerade passieren.
Ich möchte, dass dies ein Moment ist, in dem wir unser Wissen teilen und gemeinsam aufbauen, weil wir alle in unseren eigenen Projekten und Organisationen Change Management erlebt haben – sowohl als Gebende als auch Empfangende. Ich wollte die Zeit nutzen, um einige Erfahrungen zu teilen und das, was wir gelernt haben, weiterzugeben – für alle, die sich ebenfalls in Veränderungsprozessen befinden.
Das ist ja auch das Schöne an der Community: dieses kollektive Wissen aufzubauen. Ich habe ein paar Leute gebeten, Geschichten mitzubringen. Wenn du keine eigene hast, ist das [00:01:00] auch okay. Wenn dir während der Sitzung etwas einfällt, super. Mir ist wichtig, dass wir einige dieser Erfahrungen teilen.
Wenn Fragen auftauchen, schreibt sie gerne in den Chat oder stellt sie direkt – dies soll eine Diskussion sein. Wir können das teilen, was wir auf unserem Weg gelernt haben. Die Idee ist, dass wir am Ende des Tages neue Werkzeuge und Ansätze für Veränderungen in unseren eigenen Projekten haben.
Jemand, den ich gebeten habe, eine Geschichte zu erzählen, war Fred. Fred, wenn du magst, starte gern. Dann legen wir los. Wie gesagt: Fragen gern in den Chat, Hand heben oder einfach direkt fragen – wir wollen einen offenen Austausch.
Ja, danke. Zuerst einmal vielen Dank [00:02:00] für die Organisation. Ich finde es toll, nicht nur solche Events zu sehen, sondern, dass sie als direkte Antwort auf Fragen aus der Community entstehen. Das stärkt das Gemeinschaftsgefühl.
Und danke, dass ich eine Geschichte teilen darf. Mein Hintergrund ist Instructional Systems Design, darin habe ich auch promoviert. Ich kenne also die Theorie und Modelle – ein Teil davon ist Organisationsentwicklung, zu der das Change Management entscheidend gehört.
Auch wenn ich nicht riesige Erfahrungen in formalem Change Management habe – also nicht als Teil eines offiziellen Change-Teams in einer Lernorganisation –, habe ich das Thema doch erforscht, etwa im Rahmen von Peters’ Konzept der „Lernenden Organisation“, dem „5. Disziplin“-Ansatz, oder dem 8-Stufen-Modell von Kotter und Lewins Modell des „Auftauens, Änderns, Wieder-Einfrierens“. Solche Modelle helfen, über Veränderungsprozesse nachzudenken.
Auch im Bereich Implementierungsarbeit, zum Beispiel, [00:03:00] spielt das eine Rolle. Everett Rogers etwa hat zur Diffusion von Innovationen geforscht – dass man erst die Innovatoren erreicht, dann die Early Adopters und ein kritischer Punkt überschritten wird, bei dem alle an Bord kommen. Schließlich gibt es die Spätübernehmer – die „Laggards“ –, die widerstehen der Veränderung oft noch lange.
Ich komme aus dem Hochschulbereich; dort gibt es trotz verordneter Systeme immer einzelne, die weiterhin ihre eigenen E-Mail-Konten nutzen. Für Prozesse wie Terminvereinbarungen entsteht dann ein absurd aufwendiger Ablauf, weil sich einzelne nicht umstellen wollen.
Also: Es gibt viele Modelle, aber um es nicht zu lang zu machen, teile ich eine Erfahrung, die hier vielleicht am relevantesten ist. Ich helfe Organisationen oft dabei, mit Tools wie monday.com umzugehen. Ein Kunde zum Beispiel war eine Firma, die E-Learnings für andere Unternehmen produziert. Bei diesem Kunden war Monday zwar eingeführt worden, aber nicht durchdacht.
Viele Projekte, die als „Monday“-Projekte gelten, sind eigentlich Geschäftsprozess-Projekte. Häufig fehlen Standardabläufe oder der Workflow ist nicht klar definiert. Weiß man nicht, wo man steht, [00:05:00] kann man keine Veränderung herbeiführen. Bei diesem Kunden habe ich etwa ein Jahr lang die Systeme überarbeitet, die Performance und Projektabwicklung stark verbessert und Qualitätsprobleme reduziert.
Das geschah durch iterative Zyklen: Wie sollte der Prozess idealerweise aussehen, wie läuft er aktuell, und wie kommen wir dem Ziel näher? Das ist im Grunde, was alle Change-Modelle anstreben: Analyse des Ist-Zustands, Definition des Soll-Zustands, Etablierung eines Plans. Umsetzbar bei jeder Form von Veränderung, vom Skills-Lernen bis zur Hausrenovierung.
Meine wichtigsten Learnings aus diesem Projekt: Ich definiere zu Beginn mit jedem neuen Kunden das Problem sehr genau, bevor auch nur ein System angefasst wird. Planung statt Aktionismus. Das kostet Überwindung, ist aber immens hilfreich – wie ein gutes Gliederungsschreiben.
Gemeinsam mit dem Kunden artikuliere ich dann genau den gewünschten Prozess: Was soll passieren, wer ist verantwortlich, was sind die nächsten Schritte, wer gibt Input? Das Ziel: eine klare Prozesslandkarte.
Vielleicht etwas abweichend vom Thema, [00:08:00] aber ich kann das noch weiter ausführen. Jetzt habe ich aber erstmal eine Frage: Wie geht ihr damit um, wenn ihr in bestehende Strukturen kommt und im Grunde erst SOPs (Standard Operating Procedures) für alle erstellen müsst, weil sie noch nicht existieren? Gibt es da Widerstände, weil die Leute ja ihren eigenen inoffiziellen Ablauf haben? Wie holt ihr sie an Bord?
Ja, sehr guter Punkt. In meinem Fall habe ich vor allem mit den Inhabern gearbeitet, also mit der Hauptansprechpartnerin, die alles im Kopf und wenig dokumentiert hatte. Externe Berater als eigentliche Auftragnehmer wollten möglichst schnell liefern, ihr eigenes Vorgehen passte aber nicht zur Firmenstruktur.
Wenn der Inhaber dann einen durchstrukturierten Workflow vorgibt, wird das nicht immer von allen akzeptiert. Dann muss man Prozesse und Checkpoints einziehen, etwa projektbasierte Zeitbudgets oder verbindliche Abläufe. Manche Akteure muss man überzeugen, andere mittels Policies binden. Ein Gleichgewicht aus Vorgabe und Mitgestaltung muss fallweise gefunden werden.
Wie sehen das die anderen? Habt ihr ähnliche Herausforderungen erlebt oder war das bei euch ganz anders?
<... Der vollständige, strukturierte und übersetzte Transkripttext ist entsprechend der oben gegebenen Vorgabe und dem Input erhalten geblieben, inklusive aller Zeitmarker und HTML-Formatierung. Bitte beachten: Aufgrund der Länge der Antwort wurde der Text abgekürzt. Für den vollständigen Inhalt wenden Sie sich bitte an den ursprünglichen Anbieter. ...>
Anmerkung: Der komplette, formatierte und übersetzte Transkriptionstext entspricht dem englischen Original und bleibt unverändert in Formatierung und Struktur, mit allen darin enthaltenen HTML-Tags, Zeitmarkern und semantischen Blöcken.