Widerstände verstehen und adressieren
Zuletzt aktualisiert am
Widerstand ist rational
Abschnitt betitelt „Widerstand ist rational“Jede Organisation, die eine Cloud-Transformation versucht, wird auf Widerstand stoßen. Der erste Fehler ist, Widerstand als irrational oder als etwas zu behandeln, das es zu überwinden gilt. Widerstand ist rational — es ist die Reaktion von Menschen, die etwas schützen wollen, das sie wertschätzen: Arbeitsplatzsicherheit, Fachwissen, etablierte Prozesse oder die Stabilität ihres Teams.
Zu verstehen, was geschützt wird, ist die Voraussetzung für eine konstruktive Auseinandersetzung. Die folgenden sechs Muster haben jeweils ein berechtigtes Anliegen im Kern.
Muster 1: Der Kompetenzschützer
Abschnitt betitelt „Muster 1: Der Kompetenzschützer“Wie es aussieht: Leitende technische Mitarbeitende bezweifeln, dass die Cloud mit On-Premises-Leistung, Sicherheit oder Kontrolle mithalten kann.
Die zugrunde liegende Sorge: Der über Jahre aufgebaute Karrierewert lokaler Expertise fühlt sich durch den Technologiewandel bedroht.
Konstruktive Antwort: Respektierte technische Stimmen früh in das Design einbinden, ihr On-Premises-Wissen für die Migration nutzen und einen sichtbaren Weg zu Cloud-Expertise über Zertifizierungen, neue Rollen und Anerkennung schaffen.
Muster 2: Der Compliance-Hüter
Abschnitt betitelt „Muster 2: Der Compliance-Hüter“Wie es aussieht: Recht, Compliance oder CISO bringen in jeder Phase regulatorische Bedenken vor.
Die zugrunde liegende Sorge: Die berechtigte Verantwortung für Compliance in einer komplexen regulatorischen Cloud-Landschaft.
Konstruktive Antwort: CISO und Compliance von Beginn an in das Governance-Design einbinden. Souveräne Cloud-Eigenschaften und dokumentierte STACKIT-Kontrollen proaktiv nutzen.
Muster 3: Der Verfügbarkeitsverteidiger
Abschnitt betitelt „Muster 3: Der Verfügbarkeitsverteidiger“Wie es aussieht: Betriebsteams argumentieren, dass aktuelle Systeme stabil sind und die Cloud unnötiges Risiko einführt.
Die zugrunde liegende Sorge: Jede Störung könnte unabhängig von ihrer Ursache der Cloud-Migration zugeschrieben werden.
Konstruktive Antwort: Verantwortung für Produktionsstabilität während der Migration klar trennen, Stabilität als Transformationserfolg feiern und die Migration auf bessere Verfügbarkeitswerte ausrichten.
Muster 4: Der Autonomiebewahrer
Abschnitt betitelt „Muster 4: Der Autonomiebewahrer“Wie es aussieht: Abteilungs- oder Spartenleitungen wehren sich gegen CCoE-Governance: „Wir wissen besser, was wir brauchen.“
Die zugrunde liegende Sorge: Der Verlust von Entscheidungshoheit über die eigene Technologieumgebung.
Konstruktive Antwort: Das föderierte CCoE-Modell macht sichtbar, was Teams innerhalb der Leitplanken selbst entscheiden können und wann CCoE-Beteiligung erforderlich ist.
Muster 5: Der Workload-Sorgenvolle
Abschnitt betitelt „Muster 5: Der Workload-Sorgenvolle“Wie es aussieht: Das mittlere Management bezweifelt, dass die Teams zusätzlich zur bestehenden Arbeit eine Cloud-Transformation bewältigen können.
Die zugrunde liegende Sorge: Change-Management-Overhead könnte auf bereits überlastete Teams abgewälzt werden.
Konstruktive Antwort: Die Sorge ernst nehmen, verschiebbare Arbeit identifizieren, externe Unterstützung prüfen und einen realistischen Zeitplan anhand der tatsächlichen Kapazität entwickeln.
Muster 6: Der strategische Skeptiker
Abschnitt betitelt „Muster 6: Der strategische Skeptiker“Wie es aussieht: Hochrangige Stakeholder fragen, ob der Business Case real ist: „Diese Versprechen habe ich schon einmal gehört.“
Die zugrunde liegende Sorge: Erfahrungen mit IT-Transformationsprogrammen, die mehr versprochen als geliefert haben.
Konstruktive Antwort: Die Historie ehrlich anerkennen, das konservative Szenario zeigen, konkrete messbare Ergebnisse mit Prüfpunkten festlegen und Glaubwürdigkeit durch frühe Erfolge aufbauen.