Change Management ist die strukturierte Disziplin, mit der Sie eine Organisation und die Menschen darin von einem aktuellen Zustand in einen gew\u00fcnschten Zielzustand f\u00fchren. Sie umfasst die Planung, Kommunikation, Qualifizierung und Verankerung, die n\u00f6tig sind, damit neue Technologien, Prozesse oder Strukturen tats\u00e4chlich angenommen werden und ihren geplanten Nutzen entfalten. F\u00fcr CTOs, IT-Leiter und Verantwortliche f\u00fcr die digitale Transformation entscheidet Change Management dar\u00fcber, ob eine Plattformmigration, ein ERP-Rollout oder eine DevOps-Transformation messbare Ergebnisse liefert oder an Widerst\u00e4nden und Nacharbeit scheitert.<\/p>\n
Change Management bezeichnet die Steuerung eines organisatorischen Wandels von der ersten Idee und Vorbereitung \u00fcber die Umsetzung bis zu seinem Abschluss. Der Begriff beschreibt sowohl eine Managementpraxis als auch einen Forschungsbereich. Seine geistigen Wurzeln liegen in der Verhaltenswissenschaft der 1940er-Jahre, als der Psychologe Kurt Lewin ein dreistufiges Modell aus Auftauen, Ver\u00e4ndern und Wiedereinfrieren von Gruppenverhalten vorschlug. Lewins Arbeit begr\u00fcndete die zentrale Annahme, dass nicht nur Systeme, sondern vor allem Menschen bewegt werden m\u00fcssen, damit Ver\u00e4nderungen Bestand haben.<\/p>\n
In der zweiten H\u00e4lfte des 20. Jahrhunderts reifte die Disziplin weiter. Managementberater wie Thomas J. Peters und Robert H. Waterman, deren Arbeiten \u00fcber organisatorische Exzellenz sp\u00e4ter in das McKinsey-7-S-Modell einflossen, zeigten, dass Strategie und Struktur allein nicht erkl\u00e4ren, warum Organisationen beim Wandel erfolgreich sind oder scheitern. Der Harvard-Professor John Kotter formalisierte in den 1990er-Jahren einen Acht-Schritte-Prozess, der auf den gemeinsamen Erfolgsfaktoren zahlreicher Ver\u00e4nderungsf\u00fchrender beruhte. In den vergangenen rund 25 Jahren hat sich Change Management durch forschungsbasierte Praxis zu einem anerkannten Berufsfeld mit Zertifizierungen, Werkzeugen und F\u00e4higkeitsmodellen f\u00fcr Unternehmen entwickelt.<\/p>\n
In der Praxis wird \u201eChange Management\u201c in zwei sich \u00fcberschneidenden Bedeutungen verwendet. Die erste ist das organisatorische Change Management<\/em>, das sich auf die menschliche Seite des Wandels konzentriert: Bewusstsein, Engagement, Qualifikation und Akzeptanz. Die zweite ist das IT-Change-Management<\/em>, eine Praxis des IT-Service-Managements, die steuert, wie \u00c4nderungen an Produktivsystemen bewertet, genehmigt und ausgerollt werden. Das IT Infrastructure Library (ITIL) 4-Framework unterscheidet beides ausdr\u00fccklich. ITIL definiert das organisatorische Change Management als die Praxis, Ver\u00e4nderungen reibungslos umzusetzen und nachhaltige Vorteile zu erzielen, indem die menschlichen Aspekte gesteuert werden. Die IT-\u00c4nderungssteuerung behandelt ITIL als eigene Praxis mit Schwerpunkt auf Risikobewertung und Terminplanung. F\u00fcr Entscheidungstr\u00e4ger in Unternehmen sind beide Bedeutungen relevant, und dieser Artikel behandelt beide.<\/p>\n Organisatorischer Wandel bezeichnet jede wesentliche Ver\u00e4nderung der Art, wie ein Unternehmen arbeitet. Er kann die Unternehmenskultur, interne Prozesse, Technologie und Infrastruktur, die Berichtshierarchie oder die Marktpositionierung betreffen. Die Harvard Business School unterscheidet zwischen adaptivem Wandel, der klein, schrittweise und iterativ ist, und transformativem Wandel, der gr\u00f6\u00dfer im Umfang und oft tiefgreifend ist. Einen neuen Mitarbeiter einzustellen, um zus\u00e4tzliche Nachfrage abzufangen, ist adaptiv. Ein Kernbankensystem in die Cloud zu migrieren oder einen neuen nationalen Markt zu erschlie\u00dfen, ist transformativ. Change Management gilt f\u00fcr beide Formen, doch Tiefe der Vorbereitung, Sponsoring und Governance sollten mit dem Umfang der Ver\u00e4nderung wachsen.<\/p>\n Change Management wirkt, indem es drei voneinander abh\u00e4ngige Dimensionen gleichzeitig adressiert: die Menschen, deren Verhalten sich \u00e4ndern muss, die Prozesse, die festlegen, wie Arbeit erledigt wird, und die Technologie, die neue Arbeitsweisen erm\u00f6glicht oder begrenzt. Ein h\u00e4ufiger Fehler besteht darin, Ver\u00e4nderung als Technologieeinf\u00fchrung mit angeh\u00e4ngtem Kommunikationsplan zu behandeln. Prosci, einer der am weitesten verbreiteten Methodenanbieter, warnt ausdr\u00fccklich davor, Change Management auf einen Kommunikationsplan zu reduzieren, der lediglich ank\u00fcndigt, dass sich etwas \u00e4ndert. Damit bleibt die eigentliche Arbeit aus, Menschen in ihren individuellen \u00dcberg\u00e4ngen zu begleiten.<\/p>\n Der Mechanismus l\u00e4sst sich als Abfolge zusammenh\u00e4ngender Aktivit\u00e4ten verstehen: die L\u00fccke zwischen Ist- und Sollzustand identifizieren, die Auswirkungen auf Menschen und Systeme bewerten, die Ma\u00dfnahme gestalten, die betroffenen Menschen vorbereiten und qualifizieren, die Ver\u00e4nderung ausrollen, sie verankern und messen, ob die Akzeptanz eingetreten ist. Jede Phase liefert Ergebnisse wie eine L\u00fcckenbeschreibung, eine Wirkungsanalyse, eine Stakeholder-Karte oder ein Akzeptanz-Dashboard, die in die n\u00e4chste Phase einflie\u00dfen.<\/p>\n Die meisten ausgereiften Modelle konvergieren in einer \u00e4hnlichen Abfolge von Phasen. Die folgende Tabelle vergleicht, wie drei weithin herangezogene Quellen den Lebenszyklus beschreiben, damit IT-Verantwortliche ihn auf das eigene Liefermodell \u00fcbertragen k\u00f6nnen.<\/p>\n Der Sinn dieser Abfolge liegt nicht in starrer Befolgung. Ver\u00e4nderungsverantwortliche sollten zur\u00fcckspringen, wenn Akzeptanzkennzahlen Probleme zeigen. IBM empfiehlt ausdr\u00fccklich, bei verfehlten Transformationen zu Discovery und Delivery zur\u00fcckzukehren und den Lebenszyklus als zyklisch statt linear zu verstehen.<\/p>\n Der wichtigste praktische Punkt lautet: Eine Ver\u00e4nderung ist nicht erfolgreich, wenn sie ausgerollt wird, sondern wenn Menschen sie wie vorgesehen nutzen. Die Forschung von Prosci, basierend auf Befragungen von Praktikern \u00fcber mehr als zwei Jahrzehnte, berichtet, dass Projekte mit exzellentem Change Management eine 7-fach h\u00f6here Wahrscheinlichkeit haben, ihre Ziele zu erreichen, eine 4,6-fach h\u00f6here, im Zeitplan zu bleiben, und eine 1,4-fach h\u00f6here, im Budget zu bleiben, verglichen mit Projekten mit schwachem Change Management. Die Harvard-Unterlagen verweisen auf eine Gartner-Erhebung, nach der nur 32 Prozent der F\u00fchrungskr\u00e4fte in ihrer letzten Ver\u00e4nderungsinitiative eine gesunde Akzeptanz der Mitarbeitenden erreichten. F\u00fcr einen CTO ist diese L\u00fccke zwischen Ausrollen und Akzeptanz der Punkt, an dem der meiste Nutzen entweder gehoben oder verspielt wird.<\/p>\n In Unternehmen werden mehrere Modelle gelehrt und angewendet. Keines ist universell \u00fcberlegen. Jedes bietet eine andere Perspektive: Manche beschreiben, wie Menschen den \u00dcbergang erleben, andere, wie F\u00fchrungskr\u00e4fte Ma\u00dfnahmen zeitlich ordnen sollten, und wieder andere, wie voneinander abh\u00e4ngige Faktoren die Ver\u00e4nderungsf\u00e4higkeit einer Organisation pr\u00e4gen. Erfolgreiche Ver\u00e4nderungsverantwortliche w\u00e4hlen Modelle nach Art der Ver\u00e4nderung, Reifegrad der Organisation und betroffener Zielgruppe aus.<\/p>\n Lewins Modell \u201eAuftauen \u2013 Ver\u00e4ndern \u2013 Wiedereinfrieren\u201c ist das \u00e4lteste und einfachste. Seine Metapher vergleicht eine Organisation mit einem Eisblock: Er l\u00e4sst sich umformen, ohne zu zerbrechen, wenn das Eis zun\u00e4chst geschmolzen, in eine neue Form gegossen und wieder gefroren wird. Es bleibt n\u00fctzlich als Erinnerung daran, dass die Reihenfolge der Schritte z\u00e4hlt. Kotters Acht-Schritte-Prozess \u00fcbersetzt diese Logik in einen Handlungsplan, der mit dem Schaffen eines Dringlichkeitsgef\u00fchls und dem Aufbau einer F\u00fchrungskoalition beginnt und mit der Verankerung der Ver\u00e4nderung endet. Das \u00dcbergangsmodell von William Bridges verlagert den Blick vom Wandel selbst auf den psychologischen \u00dcbergang, den Menschen durchlaufen. Es beschreibt Enden, eine neutrale Zone der Unsicherheit und neue Anf\u00e4nge. Besonders wertvoll ist Bridges\u2019 Modell, wenn ein Wandel Rollen oder vertraute Routinen entfernt, weil es erkl\u00e4rt, warum die Produktivit\u00e4t oft sinkt, bevor sie sich erholt.<\/p>\n Das ADKAR-Modell, Teil der Prosci-Methodik, konzentriert sich auf Einzelpersonen statt auf Organisationen. Seine f\u00fcnf Bausteine sind Awareness (Bewusstsein f\u00fcr die Notwendigkeit des Wandels), Desire (Bereitschaft, sich zu beteiligen und den Wandel zu unterst\u00fctzen), Knowledge (Wissen, wie der Wandel umzusetzen ist), Ability (F\u00e4higkeit, neue Fertigkeiten und Verhaltensweisen umzusetzen) und Reinforcement (Verst\u00e4rkung, um den Wandel zu sichern). ADKAR ist diagnostisch: Ver\u00e4nderungsverantwortliche k\u00f6nnen erkennen, welches Element bei einer bestimmten Gruppe fehlt, und Ma\u00dfnahmen gezielt ausrichten. Ein niedriger Wert bei Desire erfordert etwa das Engagement von Sponsoren und eine klare Erl\u00e4uterung des pers\u00f6nlichen Nutzens, ein niedriger Wert bei Ability dagegen praktische \u00dcbung und Coaching. Die Prosci-Methodik umfasst au\u00dferdem den Prosci Change Triangle, der Sponsoring, Projektmanagement und Change Management als voneinander abh\u00e4ngige Treiber des Erfolgs darstellt.<\/p>\n Das McKinsey-7-S-Modell beschreibt sieben voneinander abh\u00e4ngige Elemente: gemeinsame Werte, F\u00e4higkeiten, Personal, Strategie, Struktur, F\u00fchrungsstil und Systeme. Es ist besonders n\u00fctzlich, um zu diagnostizieren, warum eine strategische Initiative nicht Fu\u00df gefasst hat, denn es zeigt, dass eine \u00c4nderung in einem Element, etwa einer neuen Strategie, nicht gelingt, wenn Struktur und Systeme unver\u00e4ndert bleiben. ITIL dagegen ist ein operatives Rahmenwerk f\u00fcr das IT-Service-Management. Seine Praxis der Change Enablement regelt, wie IT-\u00c4nderungen genehmigt und ausgerollt werden, und ist die meistgenutzte Referenz f\u00fcr IT-Betriebsteams.<\/p>\n Change Management wird h\u00e4ufig mit Projektmanagement und mit der IT-\u00c4nderungssteuerung verwechselt. Die drei Disziplinen erg\u00e4nzen einander und scheitern auf unterschiedliche Weise, wenn man eine f\u00fcr die andere h\u00e4lt. Projektmanagement verantwortet Umfang, Termine, Budget und die Lieferung der technischen L\u00f6sung. Change Management verantwortet die menschliche Seite: ob Anwender die Ver\u00e4nderung verstehen, bereit sind, sie anzunehmen, wissen, wie sie zu nutzen ist, und darin unterst\u00fctzt werden, sie dauerhaft zu leben. Die IT-\u00c4nderungssteuerung, unter ITIL 4 als Change Enablement bezeichnet, verantwortet die Governance von \u00c4nderungen an Produktivdiensten, einschlie\u00dflich Risikobewertung, Genehmigung und Terminplanung.<\/p>\n Die Unterscheidung ist wichtig, weil ein Projekt termingerecht und budgetkonform abgeschlossen werden kann, w\u00e4hrend das Unternehmen das Ergebnis nicht annimmt. Umgekehrt kann eine gut angenommene Ver\u00e4nderung schlecht gesteuert sein, wenn IT-\u00c4nderungen nicht kontrolliert werden. Prosci beschreibt das Verh\u00e4ltnis als zwei entscheidende Rollen f\u00fcr den Erfolg: Projektmanagement konzentriert sich auf die technische Seite, Change Management auf die menschliche Seite des Wandels.<\/p>\n IT-Change-Management ist die Praxis, \u00c4nderungen an IT-Diensten mit minimalem Risiko und minimaler St\u00f6rung zu planen, zu genehmigen und auszurollen. Atlassian beschreibt es als Praxis, St\u00f6rungen von IT-Diensten zu minimieren, w\u00e4hrend kritische Systeme ver\u00e4ndert werden. Eine \u00c4nderung ist in diesem Kontext jede Hinzuf\u00fcgung, Modifikation oder Entfernung von etwas, das direkte oder indirekte Auswirkungen auf Dienste haben kann. Dazu geh\u00f6ren Infrastruktur, Anwendungen, Konfigurationen und zunehmend Code und Pipelines.<\/p>\n Die Praxis existiert, weil Organisationen zwei konkurrierende Erwartungen erf\u00fcllen m\u00fcssen. Sie brauchen stabile, verl\u00e4ssliche Dienste, die Anwender produktiv halten, und sie brauchen h\u00e4ufige Aktualisierungen, um auf ver\u00e4nderte Anforderungen an Sicherheit, Kosten und Gesch\u00e4ftsmodelle zu reagieren. Ein Versagen auf einer der beiden Seiten ist teuer. Gartner hat gesch\u00e4tzt, dass Ausfallzeiten Unternehmen mehr als 300.000 US-Dollar pro Stunde kosten k\u00f6nnen, bei webbasierten Diensten deutlich mehr. Wirksames Change Management l\u00f6st diesen Konflikt, indem es \u00c4nderungen sicher genug macht, um h\u00e4ufig stattfinden zu k\u00f6nnen.<\/p>\n ITIL definiert drei \u00c4nderungstypen, und die Klassifizierung bestimmt, wie viel Governance eine \u00c4nderung erh\u00e4lt. Ein einziger Genehmigungsweg f\u00fcr alle \u00c4nderungen ist die h\u00e4ufigste Ursache f\u00fcr Engp\u00e4sse.<\/p>\n Ein Change Advisory Board (CAB) ist ein Gremium, das das Risiko vorgeschlagener \u00c4nderungen bewertet und sie genehmigt oder ablehnt. In klassischen IT-Organisationen tagt das CAB regelm\u00e4\u00dfig, um alle anstehenden \u00c4nderungen zu pr\u00fcfen, und zieht bei Bedarf Fachleute hinzu. Das CAB bietet wertvolle Risikokontrolle, besonders bei wirkungsstarken \u00c4nderungen wie einem Wechsel im Rechenzentrum. Sind seine Mitglieder jedoch weit von den betroffenen Systemen entfernt, wird es zum Engpass, der die Lieferung verlangsamt, ohne die Sicherheit zu erh\u00f6hen.<\/p>\n Moderne Praxis beschr\u00e4nkt die CAB-Pr\u00fcfung auf die riskantesten und strategisch wichtigsten \u00c4nderungen. ITIL 4 empfiehlt, die \u00c4nderungsverantwortung auf Fachbereichs- und Peer-Ebene zu dezentralisieren, w\u00e4hrend Automatisierung, virtuelle Checklisten und Peer-Reviews \u00c4nderungen mit geringerem Risiko abwickeln. Das CAB wird dadurch zu einer beratenden Instanz, die Trends \u00fcberwacht und Teams koordiniert, statt zu einem Tor, das jede \u00c4nderung passieren muss.<\/p>\n Unternehmensweites Change Management ist in gro\u00dfen Technologieprogrammen besonders sichtbar: ERP-Einf\u00fchrungen, Cloud-Migrationen, CRM-Abl\u00f6sungen, Modernisierung von Datenplattformen und die Einf\u00fchrung von DevOps. In jedem dieser F\u00e4lle ist die Technologie der einfachste Teil. Die Schwierigkeit liegt darin, zu ver\u00e4ndern, wie Menschen planen, entscheiden, Arbeit \u00fcbergeben und Leistung messen.<\/p>\n Betrachten Sie einen ERP-Rollout \u00fcber mehrere Tochtergesellschaften. Das Projektteam liefert m\u00f6glicherweise ein funktionsf\u00e4higes System termingerecht, dennoch pflegen die Finanzteams weiter parallele Tabellen, weil sie der neuen Berichtslogik nicht vertrauen. Ein ver\u00e4nderungsorientierter Ansatz w\u00fcrde diese Stakeholder fr\u00fch identifizieren, sie in Designentscheidungen einbinden, Kompetenzstandards f\u00fcr jede Rolle definieren und die Verankerung an Leistungsbeurteilungen kn\u00fcpfen. Das Ergebnis ist Akzeptanz, nicht nur der Go-live.<\/p>\n Dieselbe Logik gilt f\u00fcr DevOps und Release-Management. Atlassian weist darauf hin, dass traditionelles Release-Management f\u00fcr agile Teams Reibung erzeugen kann, und dass moderne Praxis zu Integration, Automatisierung und kontinuierlicher Auslieferung \u00fcbergeht. Dieser Wechsel betrifft Rollen, Verantwortlichkeiten und Rechenschaftspflicht, nicht nur Werkzeuge. Teams m\u00fcssen das Prinzip \u201eWer baut, betreibt\u201c verstehen, automatisierten Pr\u00fcfungen vertrauen und neue Formen der Aufsicht akzeptieren.<\/p>\n Bevor eine Ver\u00e4nderung startet, sollten F\u00fchrungskr\u00e4fte die Bereitschaft der Organisation pr\u00fcfen: die St\u00e4rke des Sponsorings, die Ver\u00e4nderungshistorie, die Kapazit\u00e4t wichtiger Teams und den Grad, in dem die Ver\u00e4nderung bestehenden Anreizen widerspricht. Widerstand ist selten irrational. Meist zeigt er unklaren Nutzen, unzureichende Beteiligung oder konkurrierende Priorit\u00e4ten an. Harvards Kurs \u201eLeading Change\u201c empfiehlt das LEASH-Modell, um damit umzugehen, mit f\u00fcnf Hebeln: F\u00fchrungshandeln, Mitarbeiterbeteiligung, abgestimmte Anerkennung, Signale, Geschichten und Symbole sowie die Abstimmung der HR-Systeme. Das LEASH-Modell versteht Widerstand als Gestaltungsaufgabe, die F\u00fchrungskr\u00e4fte durch konsequentes Verhalten und Verst\u00e4rkung beeinflussen k\u00f6nnen.<\/p>\n Auch Harvards Hinweise zu L\u00fcckenbeschreibungen sind f\u00fcr IT-Verantwortliche praktisch. Eine gute L\u00fcckenbeschreibung hat vier Eigenschaften: eindeutige Verantwortung, definierte Zeitrahmen und Umfang, einen bedeutsamen Nutzen und messbare Erfolgskriterien. Eine Ver\u00e4nderung, die diese Pr\u00fcfungen nicht besteht, wird oft nicht nachhaltig verankert.<\/p>\nWas z\u00e4hlt als organisatorischer Wandel?<\/h3>\n
Wie funktioniert Change Management in der Praxis?<\/h2>\n
Die Kernphasen des Change-Management-Prozesses<\/h3>\n
\n\n
\n \nPhase<\/th>\n Harvard Business School (5 Schritte)<\/th>\n IBM-Modell f\u00fcr digitalen Wandel<\/th>\n Praktisches Ziel<\/th>\n<\/tr>\n<\/thead>\n \n Bedarf erkennen<\/td>\n Leistungs- oder Chancenl\u00fccken identifizieren<\/td>\n Vorbereiten: Recherche, Interviews und Analyse historischer Daten<\/td>\n Best\u00e4tigen, dass die Ver\u00e4nderung eine reale, messbare L\u00fccke schlie\u00dft<\/td>\n<\/tr>\n \n Ursachen analysieren<\/td>\n Grundursachen und strategische Fehlausrichtung diagnostizieren<\/td>\n Entdecken: Wirkungsanalyse und Roadmap<\/td>\n Verstehen, was den Fortschritt blockiert, bevor eine L\u00f6sung gestaltet wird<\/td>\n<\/tr>\n \n Gestalten und umsetzen<\/td>\n Ver\u00e4nderung schrittweise gestalten und umsetzen<\/td>\n Liefern: Ma\u00dfnahmen ausrollen, Ergebnisse messen, Anwender schulen<\/td>\n In kontrollierten Schritten mit Feedbackschleifen umsetzen<\/td>\n<\/tr>\n \n Bereitschaft aufbauen<\/td>\n Kulturelle Bereitschaft und Widerst\u00e4nde adressieren<\/td>\n \u00dcbergang: Einarbeitung, Support und Akzeptanzmessung<\/td>\n Menschen von Bewusstsein zu aktiver Nutzung f\u00fchren<\/td>\n<\/tr>\n \n Verankern<\/td>\n Normen und Anreize verst\u00e4rken<\/td>\n Realisieren und sichern: Bef\u00e4higung und laufende Messung<\/td>\n Ver\u00e4nderung so verankern, dass sie nach dem Go-live nicht erodiert<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Was Ver\u00e4nderung nachhaltig macht: Akzeptanz als Erfolgsma\u00dfstab<\/h3>\n
Welche Change-Management-Modelle sollten Unternehmensverantwortliche einsetzen?<\/h2>\n
Lewin, Kotter und Bridges: Reihenfolge und \u00dcbergang<\/h3>\n
ADKAR und die Prosci-Methodik: individuelle Akzeptanz<\/h3>\n
McKinsey 7-S und ITIL: organisatorische und operative Rahmenwerke<\/h3>\n
Vergleich der wichtigsten Modelle<\/h3>\n
\n\n
\n \nModell<\/th>\n Herkunft<\/th>\n Schwerpunkt<\/th>\n Geeignet f\u00fcr<\/th>\n<\/tr>\n<\/thead>\n \n Lewins Auftauen \u2013 Ver\u00e4ndern \u2013 Wiedereinfrieren<\/td>\n Kurt Lewin, 1940er-Jahre<\/td>\n Stufenweiser \u00dcbergang des Gruppenverhaltens<\/td>\n Erkl\u00e4ren, warum Ver\u00e4nderung zeitlich geordnet und verankert werden muss<\/td>\n<\/tr>\n \n Kotters Acht-Schritte-Prozess<\/td>\n John Kotter, Harvard, 1990er-Jahre<\/td>\n F\u00fchrungshandeln und Reihenfolge<\/td>\n Gro\u00dfe Transformationen unter F\u00fchrung einer Sponsorengruppe<\/td>\n<\/tr>\n \n Bridges\u2019 \u00dcbergangsmodell<\/td>\n William Bridges<\/td>\n Psychologische Reaktion auf Ver\u00e4nderung<\/td>\n Ver\u00e4nderungen, die Rollen oder vertraute Routinen entfernen<\/td>\n<\/tr>\n \n ADKAR<\/td>\n Prosci<\/td>\n Individuelle Akzeptanz<\/td>\n Bereitschaft diagnostizieren und Coaching gezielt ansetzen<\/td>\n<\/tr>\n \n McKinsey 7-S<\/td>\n McKinsey, entwickelt aus Arbeiten der 1970er- bis 1980er-Jahre<\/td>\n Voneinander abh\u00e4ngige Organisationselemente<\/td>\n Diagnose, warum strategischer Wandel stockt<\/td>\n<\/tr>\n \n ITIL Change Enablement<\/td>\n Axelos (ITIL 4)<\/td>\n Genehmigung und Risiko von IT-\u00c4nderungen<\/td>\n Steuerung produktiver \u00c4nderungen im IT-Betrieb<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Worin unterscheidet sich Change Management von Projektmanagement und \u00c4nderungssteuerung?<\/h2>\n
\n\n
\n \nDimension<\/th>\n Projektmanagement<\/th>\n Change Management<\/th>\n IT-\u00c4nderungssteuerung (Change Enablement)<\/th>\n<\/tr>\n<\/thead>\n \n Zentrale Frage<\/td>\n Wird die L\u00f6sung wie geplant geliefert?<\/td>\n Sind Menschen bereit, f\u00e4hig und willens, sie anzunehmen?<\/td>\n Ist diese \u00c4nderung sicher f\u00fcr den Produktivbetrieb?<\/td>\n<\/tr>\n \n Wichtigste Ergebnisse<\/td>\n Plan, Zeitplan, Budget, Umfang und Lieferobjekte<\/td>\n Wirkungsanalyse, Stakeholder-Plan, Schulung und Verankerung<\/td>\n \u00c4nderungsantr\u00e4ge, Risikobewertungen, Genehmigungen und Abschlussprotokolle<\/td>\n<\/tr>\n \n Typischer Verantwortlicher<\/td>\n Projekt- oder Programmleiter<\/td>\n Change Manager oder Ver\u00e4nderungsbegleiter<\/td>\n Change Manager, CAB oder benannte \u00c4nderungsinstanz<\/td>\n<\/tr>\n \n Erfolgsindikator<\/td>\n Gelieferter Umfang, Zeit und Kosten<\/td>\n Akzeptanz und Kompetenz<\/td>\n Weniger St\u00f6rungen und fehlgeschlagene \u00c4nderungen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Was ist IT-Change-Management und wie werden \u00c4nderungen klassifiziert?<\/h2>\n
Standard-, Normal- und Notfall\u00e4nderungen<\/h3>\n
\n\n
\n \n\u00c4nderungstyp<\/th>\n Definition<\/th>\n Genehmigungsweg<\/th>\n Beispiel<\/th>\n<\/tr>\n<\/thead>\n \n Standard\u00e4nderung<\/td>\n Risikoarm, wiederholbar und vorab genehmigt, folgt einem dokumentierten Prozess<\/td>\n Vorab genehmigt; geeignet f\u00fcr Automatisierung<\/td>\n Speicher oder Arbeitsspeicher erweitern; neue Datenbankinstanz anlegen<\/td>\n<\/tr>\n \n Normal\u00e4nderung<\/td>\n Nicht eilige \u00c4nderung ohne vorab genehmigten Prozess<\/td>\n Risikobewertung, danach CAB oder benannte \u00c4nderungsinstanz je nach Risiko<\/td>\n Umzug in ein neues Rechenzentrum; Upgrade eines Content-Management-Systems<\/td>\n<\/tr>\n \n Notfall\u00e4nderung<\/td>\n Sofort erforderlich, um einen Dienst wiederherzustellen oder eine Sicherheitsbedrohung abzuwehren<\/td>\n Beschleunigte Genehmigung mit nachtr\u00e4glicher Pr\u00fcfung<\/td>\n Einspielen eines kritischen Sicherheitspatches; Behebung eines gr\u00f6\u00dferen Ausfalls<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Ist ein Change Advisory Board noch zeitgem\u00e4\u00df?<\/h3>\n
Wie wenden Sie Change Management in Unternehmens-IT und digitalen Projekten an?<\/h2>\n
Bereitschaft und Widerstand bewerten<\/h3>\n