Change Management vs. Veränderungsmanagement
In der Literatur herrscht eine Kontroverse über die Begriffe Change Management, Veränderungsmanagement, Management of Change, etc. - da die Begriffe nicht klar abgegrenzt werden.
Im Internet finden sich hierzu etliche Beispiele, bei denen die Begriffe Change Management und Veränderungsmanagement entweder als Synonym verwendet oder klar differenziert werden. Da in diesem Beitrag allerdings keine Personen kritisiert werden sollen, sondern eine Thematik beleuchtet werden soll, nehme ich ein Definitionsbeispiel von Wikipedia (auch wenn dies nicht zu meinen Hauptinformationsquellen zählt):
Hier werden unter dem Begriff “Change Management” (siehe Wikipedia - Change Management) zwei unterschiedliche Bedeutungen angeboten (Stand: 27. April 2008): ein Begriff aus der Informatik (ITIL) und ein Begriff aus der Betriebswirtschaftslehre (Veränderungsmanagement). Will man also Change Management aus Betriebswirtschaftssicht beschreiben, so kann hierfür auch Veränderungsmanagement verwendet werden (?).
Eine Ursache hierfür ist die Zunahme von Anglizismen in der deutschen Sprache. Veränderungsmanagement (als Begriff aus der Betriebswirtschaftslehre) wird so eins zu eins mit Change Management übersetzt, weshalb hier auch keine klare Abgrenzung mehr stattfindet und Verwechslungsgefahr besteht. Anglizismen haben heutzutage (leider) Vorrangstellung bekommen, auch wenn manche Begriffe nun doppeltbelegt sind.
Soll nun das Management von IT-Veränderungen thematisiert werden, steht man vor einem Dilemma. Einerseits kann die Thematik in das Veränderungsmanagement aus der Betriebswirtschaftslehre eingegliedert werden, auf der anderen Seite will man hier keinen direkten Zusammenhang mit dem Change Management aus der IT Infrastructure Library (ITIL) herstellen und die Begriffe Änderungsmanagement und Konfigurationsmangement klar von der Thematik abgrenzen.
Der Begriff “IT-Veränderungsmanagement” ist bisher (noch) nicht in den Duden aufgenommen worden, würde diese Thematik aus meiner Sicht jedoch ziemlich genau bezeichnen.
Ich hoffe, dieser Beitrag regt zur Diskussion an, da ich beim Googeln lediglich auf einen Beitrag gestossen bin, der sich mit diesem Thema befasst: siehe Projektmagazin.de.
Informationen über Change Management finden sich im Change Pool.





Es stimmt, dass die angesprochenen Begriffe häufig unklar und missverständlich verwendet werden. Aus meiner Sicht wird langfristig nicht viel übrig bleiben, als nachzufragen, wenn ein derartiger Begriff fällt. Nach dem Motto: “Was genau verstehst Du unter Change Management?”.
Ich verwende die Begriffe wie folgt:
Change Management / Veränderungsmanagement / Organisationsentwicklung / Organisationales Lernen: jede Form organisatorischen
Wandels
Change Control / Änderungsmanagement: Management von sich verändernden Anforderungen und Zielen in Projekten (meist IT-Projekte)
Obwohl Change Management häufig im Kontext mit ITIL und auch IT-Projekten genannt wird, finde ich den Begriff hier etwas unpassend. Laut dem PMBoK (größter Projektmanagement Standard weltweit) des Project Management Institute (PMI) ist Change Control in diesem Zusammenhang der “richtige” Begriff.
Aber ich bleibe dabei: Im Einzelfall einfach nachfragen und das Begriffs-Wirr-Warr aufklären.
“Die Sprache gleicht dem Fleck zwischen Siegfrieds Schulterblättern, auf den das Lindenblatt gefallen ist; an dem mächtigen Leib der Realität ist sie die einzige Stelle, die der Zauber des Drachenbluts nicht schützt.” Ich weiß nicht mehr, wo ich diesen schönen Spruch gelesen habe. Er weist aber ganz gut darauf hin, dass sprachliche Präzision eben ihre Grenzen hat.
Letztlich ist der Versuch, diese Begriffe gegeneinander abzugrenzen, nur ein Versuch, die komplexe Realität des Managements von organisatorischen und technischen Systemen be-greif-bar zu machen. Und das geht eben nicht absolut eindeutig und überschneidungsfrei. So mancher IT-Manager wurde schon von der Erkenntnis überrascht, dass ein IT-Change erhebliche organisatorische Veränderungen (=Changes!) nach sich zog, die es dann auch noch zu managen galt.
Der Verwendung der Begriffe, wie sie Stefan beschrieben hat, kann ich mich gut anschliessen. Als Beraterin finde ich es bemerkenswert, dass in dem hier diskutieren Problem (”Was genau ist Change Management?”) schon fast die Lösung liegt, nämlich zu fragen “Worum geht es im Einzelfall genau?”.
Von wegen Anglizismus. Nützlich finde ich die Diskussion im angelsächsischen Raum zur Unterscheidung von “Management” und “Leadership”. Umgangssprachlich in etwa “was läuft am laufen halten und Resultate erreichen” und “führen, wo es noch keine Landkarte gibt.” In den meisten englischsprachigen Veröffentlichungen wird seit Peter Drucker in Bezug auf Veränderung/Change daher meistens der Begriff “Leadership” verwendet. - Das hört sich natürlich im Kontext der belasteten deutschen Sprache nicht ganz gut an “Führerschaft”. Der Unterschied zwischen der Realisierung einer Planung, die natürlich auch gut sein sollte, und der Integration des Ungeplanten sollte allerdings aufgehen, egal welchen Begriff ich für die Bezeichnung der Rolle und Verantwortung für Veränderung brauche.
Es ist effektiv so, dass der Begriff ‘Change Management’ - leider - mehrfach belegt ist.
In der ITIL-Literatur wird das Change Management im Buch Service Transition als eine eigene Prozessdisziplin beschrieben und gehört zu den Prozessen der Umsetzung von geschäftlichen Anforderungen in die IT-Service-Landschaft.
Das Ziel des Change Management nach ITIL ist es, alle Anpassungen an der IT-Infrastruktur kontrolliert und effizient unter Minimierung von Risiken durchzuführen.
[Quelle: Wikipedia, Change Management (ITIL)]
Wir von SAXOS gehen innerhalb der Informatik noch eine Stufe tiefer und verwenden den Begriff ‘Change Management’ als eine der Disziplinen des Software Change and Configuration Managements - kurz eben SCCM oder der Verwaltung von Software, welche im Unternehmen zur eigenen Verwendung oder zum Verkauf entwickelt wird.
Die Disziplin ‘Change Management’ innerhalb von SCCM dient der integrierten und automatisierten Verwaltung von Change Requests (Anforderungen, Problem Reports und Enhancement Requests) und allen damit zusammenhängenden Artefakten, deren Zustände, deren Änderungen usw.
Das Change Managements auf dieser Stufe hat zum Ziel, allen, die mit dieser unter SCCM verwalteten Software zu tun haben - Endbenutzer, Projektleiter, Entwickler usw. - jederzeit aktuell Auskunft geben zu können.