Online PR & Social Media News - Autorenportal

(Online-Artikel.de) - Change Management und die Einführung von IT-Systemen

Wann ist ein IT-Projekt erfolgreich? Eine gängige Antwort: Es sollte in der vorgesehenen Zeit umgesetzt werden, innerhalb des vorgesehenen Budgets, und sollte die erwarteten Funktionalitäten bieten. Richtig, aber zu kurz gesprungen: Es sollte die Erreichung des Zieles ermöglichen, das hinter dem Entschluß steht, in neue Systeme zu investieren. Für gewöhnlich also zu besseren Arbeitsergebnissen führen, sei es in qualitativer und/oder quantitativer Hinsicht. Ein Blick nach links und rechts zeigt, daß Erfolg bei der Einführung komplexer IT-Systeme eher die Ausnahme als die Regel ist. Selbst wenn man den Erfolg lediglich an Zeit, Budget und Funktionalitäten mißt, kommen nur rund ein Drittel der IT-Projekte zu einem positiven Ergebnis, und etwa ein Viertel wird gar vorzeitig abgebrochen (vgl. z.B. The Standish Group´s CHAOS Report 2009; eine Zusammenfassung findet sich unter www.standishgroup.com/..). Wie viele IT-Projekte auch tatsächlich den Mehrwert geschaffen haben, den sie sollten, sei vor diesem Hintergrund einmal dahingestellt. Wüßte man es, wäre es höchstwahrscheinlich deprimierend.

Warum ist das so? Eine auch nur halbwegs umfassende Antwort auf diese Frage will und kann dieser Artikel nicht geben. Er soll lediglich einige Überlegungen zum Thema „Change Management" bei der Einführung von IT-Systemen zeigen, angestoßen von der Beobachtung zweier Phänomene, die bei der Einführung neuer Systeme, nicht gerade selten zu finden sind. Das erste Phänomen ist die „Ohne mich"-Haltung auf seiten der Mitarbeiter. Es reicht von der Skepsis, über die Unzufriedenheit, bis hin zum Widerstand der Mitarbeiter, die sich mit der Einführung neuer Systeme konfrontiert sehen. Das zweite Phänomen ist die Unzufriedenheit des Managements, das den Mangel an Veränderungsbereitschaft bei den Mitarbeitern beklagt, und die Frage stellt, warum hier so wenige „Team-Player" zu finden sind. Auch wenn es auf den ersten Blick so scheinen könnte, ein linearer Zusammenhang zwischen Ursache und Wirkung läßt sich hier nicht zwingend herstellen. Was man aber leicht erschließen kann ist, daß diesen Symptomen handfeste Probleme zugrunde liegen – das „Change Management" hat nicht stattgefunden, oder nicht funktioniert. Aber wie kann das sein, wo doch sogar ein Change Management-Plan aufgestellt wurde, nachdem die ersten Probleme aufgetaucht sind, und den am Projekt Beteiligten wiederholt eingebleut wurde, daß das auch wichtig ist?

Das Rezept für erfolgreiches Change Management?

Gibt es nicht. Die Worte „Change" und „Management" zu einem Begriff zu verschmelzen, ist an sich schon nicht ganz unproblematisch. Näher betrachtet hat der Begriff „Change Management" viel von einem Oxymoron und spiegelt eher den Wunsch als die Wirklichkeit wider. Dem Wandel, der passiert, mit einem Plan zu begegnen, der den Erfolg sicherstellt – das ist die Hoffnung und Erwartung, die viele Manager mit einer Change Management-Initiative verbinden.

Es wird bereitwillig angenommen, daß es einen richtigen Weg gibt, der vorab geplant werden kann. Den man dann nur Punkt für Punkt umsetzen muß, um zum Erfolg zu kommen. Das erscheint naheliegend, weil es sich mit den Erfahrungen aus vielen anderen Bereichen der täglichen Arbeit deckt. Und es hat etwas Beruhigendes, zu glauben, den unvorhersehbaren und chaotischen Ereignissen, die Veränderungen mit sich bringen, etwas „Konkretes" entgegenhalten zu können. Ganz dem Gesetz von Nachfrage und Angebot folgend, gibt es demnach Patentrezepte zuhauf. Und wenn sie scheitern – was meist der Fall ist – dann ist der einfachste Weg, die Ursache in der Ausführung des Planes zu suchen.

Der vielleicht entscheidende Schritt für ein erfolgreiches Gestalten von Veränderungsprozessen ist, ein paar grundsätzliche Dinge zu reflektieren:

Punkt 1 & 2 sprechen die nun gegen das Bestreben, Veränderungen zu gestalten und zu steuern? Keineswegs. Sie sprechen nur gegen die Annahme, daß es einen „Master-Plan" geben kann, und für die Einsicht, daß erfolgreiches Change Management immer auch heißt, mit dem Unvorhergesehenen zurechtzukommen. Auch eine vorausschauende Planung steht in keinem Konflikt zu diesen Überlegungen -sie liefert die Antworten auf die Fragen, die man bereits kennt. Nicht mehr, aber auch nicht weniger. Zum Problem wird ein Change Management-Plan immer dann, wenn die Antworten, die er liefert, beibehalten werden, obwohl sich die Fragen im Laufe des Veränderungsprozesses geändert haben.

Punkt 3 führt direkt zum häufigsten Grund für das Scheitern von Veränderungsprozessen: zur Obstruktion. Die eigenen Mitarbeiter, oder auch die Kunden, Lieferanten etc., ziehen nicht mit. Die möglichen Gründe hierfür sind vielfältig. Aber um im Rahmen dieses Artikels zu bleiben, will ich mich auf den Fall beschränken, daß die Veränderung an sich notwendig und sinnvoll ist und daß sie trotzdem nicht akzeptiert wird.

Ihre Mitarbeiter haben eine klare Priorität, nämlich das Lösen von Problemen. Wird der Status quo betreffend den Bereich, in dem die Veränderung stattfinden soll, als „in Ordnung" angesehen, warum das Bewährte verwerfen? Wird das Problem nicht in den dem Veränderungsbedarf zugrunde liegenden Ursachen gesehen, sondern in der Veränderung selbst, werden Ihre Mitarbeiter – bewußt oder unbewußt – dagegen wirken. Ein „Top-Down- Marschbefehl hilft hier wenig, dem Befolgen von Weisungen kommt im Denken des normalen Menschen (Gott sei Dank) eine nachrangige Rolle zu. Und die Angst vor etwaigen Sanktionen führt nicht zu Einsicht, sondern zur Suche nach kompatiblen Problemlösungsansätzen: Wie begegne ich dem Problem (= der Veränderung), ohne mich dabei der Gefahr von Sanktionen auszusetzen? Womit wir wieder bei der Obstruktion wären.

Die schlechte Nachricht: Ist ein Veränderungsprozeß an dem Punkt angelangt, daß das „Was" und „Wie" beschlossene Sache sind, und die Betroffenen an der Seitenlinie stehen und die Stirn runzeln, ist es zu spät. Dann kann man sich nur noch in Schadensbegrenzung üben, oder darauf warten, daß die normative Kraft des Faktischen ihre Wirkung entfaltet. Zumeist ein sehr langwieriger, schmerzhafter Prozeß.

Die gute Nachricht: Es ist durchaus kein Hexenwerk, Veränderungen erfolgreich zu gestalten. Entscheidend ist der Entscheidungsprozeß. Stark vereinfacht, gibt es drei Muster, um zu einer Entscheidung über das „Was" und „Wie" einer Veränderung zu kommen: Die Order, die Beratschlagung und den Konsens.

Die Order von oben, bei der das Top-Management, oder ein einzelner Verantwortlicher, zu der Entscheidung kommen, wie die Veränderungen in einem Bereich auszusehen haben, ist die schnellste Methode, um die Vorbereitungs- und Planungsphase abzuschließen. Der Nachteil ist, daß es auch die teuerste und aufwendigste Herangehensweise mit der längsten Gesamtprojektdauer ist. Auch wenn die beschlossene Lösung für sich genommen vernünftig und von guter Qualität ist. Die eingesparte Zeit in der Vorbereitung kann man mit mindestens dem Faktor 5 multiplizieren und sie auf die Umsetzungsphase aufschlagen. Denn die Zahl der zu erwartenden Verwerfungen auf dem Weg zum Ziel wird leicht Legion.

Die Beratschlagung, bei der eine Entscheidung getroffen wird, nachdem einige oder alle Betroffenen konsultiert worden sind, um ihr fachliches Wissen, ihre Prozeßkenntnisse, und idealerweise auch ihre Ideen, in die Gestaltung der Veränderung mit einzubeziehen, ist in der Praxis am häufigsten anzutreffen. Die Konsultation derjenigen, die von der Veränderung betroffen sind, kann die Akzeptanz erhöhen, muß es aber nicht. Denn im Wesentlichen zielt sie darauf ab, Informationen zu sammeln. Das integrative Moment, das die Beratschlagung beinhalten kann, wird oft als netter Nebeneffekt gesehen. Was bedeutet, seine Bedeutung zu unterschätzen.

Der Konsens, getragen vom gesamten Team, basiert im Wesentlichen auf der kollektiven Einsicht, daß ein Veränderungsbedarf besteht. Was dazu führt, daß der Status quo, und nicht die Veränderung, von den Beteiligten als Problem gesehen wird. Das ist kein einfacher Prozeß. Die Vorbereitungsphase wird dadurch verlängert; die Zeit, die danach für die Implementierung benötigt wird, reduziert sich dadurch allerdings ganz erheblich. Und ebenso erhöht sich die Chance ganz wesentlich, daß sich die gewünschten Verbesserungen auch tatsächlich materialisieren.

Leider besteht nicht immer die Möglichkeit, zu einem derart umfassenden Konsens zu kommen. Wenn es etwa Teil der gewünschten Veränderung ist, die Zahl der Mitarbeiter in einem Bereich zu reduzieren, wird niemand ernsthaft annehmen, daß das unisono auf Einsicht treffen kann. Aber auch in diesen Fällen gilt die Grundregel: Je stärker sich die Einbeziehung der Beteiligten und Betroffenen auf der Skala „Konsultation vs. Konsens" in Richtung Konsens bewegt, desto größer werden die Chancen für eine erfolgreiche Umsetzung der Veränderung. Deswegen ist die Abwägung zwischen Konsultation und Konsens, mit allen ihren Graustufen, eine der wichtigsten Entscheidungen, wenn ein Veränderungsprozeß gestaltet werden soll. Wird sie unterlassen, bleibt eine „Wundertüte" zurück, deren Inhalt einen nur in den seltensten Fällen positiv überrascht. Wenn es einfach kommt, wie es kommt, kommt meist nichts Gutes.

Der Weg zur „richtigen" Entscheidung ist, wie skizziert, ein sehr dynamischer, selten linearer Prozeß. Wenn dem so ist, wie kann man dann dafür Sorge tragen, daß das Ganze die richtige Richtung nimmt? Sehr viel wird von der Person des Verantwortlichen abhängen, noch mehr von der Firmenkultur, der Einbindung und dem Selbstverständnis der Mitarbeiter. Es würde den Rahmen dieses Artikels deutlich sprengen, alle relevanten Faktoren hier zu benennen. Sie gar zu bewerten: ein Ding der Unmöglichkeit, denn dieser Versuch kann nur am konkreten Fall vorgenommen werden. Ein probates Mittel, die Erfolgsaussichten einer Veränderungsanstrengung zu erhöhen, ist jedoch das Vermeiden von Fehlern, denn Widerstand gegen die Veränderung von heute resultiert aus den Fehlern von gestern.

Change Management und die Einführung von IT-Systemen

Vom Grundlegenden zum Speziellen, will ich im Folgenden deshalb vier Fehler beschreiben, die bei Veränderungsprozessen im IT-Umfeld leider nicht gerade selten zu finden sind. Manche dieser Fehler werden ähnlich auch in anderen Bereichen begangen, aber es scheint, daß der stark technologische Fokus im IT-Bereich besonders dazu geeignet ist, die sogenannten „weichen Faktoren" in den Hintergrund zu drängen. Dabei können diese „weichen Faktoren" gerade im Zuge einer Veränderung verdammt harte Fakten schaffen. Ist es der vorherrschende Konsens des Managements, daß Prozesse, Daten, Systeme, Analysen etc. das Wesentliche sind, und die Werte des Unternehmens, die Kommunikationskultur, die Wahrnehmung der Mitarbeiter und Kunden etc. als zweitrangig oder „nice to have" einzustufen sind, ist das recht fruchtbarer Boden für ein Mißlingen.

„Mit dem Best Practices-Prinzip sind wir auf der sicheren Seite": An sich keine schlechte Idee, das Rad nicht neu zu erfinden. Aber kann und will man die Strukturen und Prozesse des zum Vorbild genommenen Unternehmens wirklich vollständig übertragen? Sollte die Antwort „Nein" lauten, ist Vorsicht geboten. Die Implementierung gleicher IT-Systeme bedeutet keineswegs, daß man auch gleiche Ergebnisse erwarten kann – natürlich eine Binsenweisheit. Trotzdem ist nicht selten die diffuse Hoffnung anzutreffen, daß dieser Effekt schon eintreten wird, wenn das Projekt erst mal abgeschlossen ist.

Diese Form des „magischen Denkens" ist deshalb problematisch, weil sie eine falsche Herangehensweise befördert. Nämlich die Einführung neuer Systeme von oben nach unten, und von innen nach außen. Nur: andersherum wird ein Schuh draus. Die Wertschöpfung erfolgt bei und mit den Kunden, mittels der Mitarbeiter, denen Prozesse und Systeme als Werkzeuge dienen. Das Management hat das Ziel, die Wertschöpfung zu steigern. Also die Kundenbedürfnisse zu befriedigen, und den Mitarbeitern die richtigen Werkzeuge dafür an die Hand zu geben. Bei der Frage was man machen soll, ist demnach der Kunde entscheidend, und bei der Frage wie man es machen soll, die Mitarbeiter. Praktischerweise eröffnet das auch die richtige Richtung betreffend das Thema „Change Management", nämlich hin zu Konsultation und Konsensfindung.

Daß bei der Suche nach besseren IT-Systemen ein Blick auf andere Unternehmen sehr hilfreich sein kann, ist klar. Daß man dabei aber nur selten „die Antwort" finden wird, die sich eins zu eins übertragen läßt, sollte es ebenso sein.

„Möglichst gestern": Der Versuch, an der falschen Stelle Zeit zu sparen, kann die Dauer einer Veränderungsanstrengung ganz erheblich verlängern. Getrieben von dem verständlichen Wunsch, die Vorteile besserer IT-Systeme möglichst schnell nutzen zu können, legen viele Firmen mit der Implementierung oder Anpassung los, bevor die eigene Organisation, und/oder die externen Partner und Kunden, in die Lage versetzt wurden, die Veränderung zu verstehen, mitzutragen und zu „verdauen". Derselbe Wunsch liegt auch dem Phänomen zugrunde, daß möglichst viele Baustellen auf einmal aufgeworfen werden, mit dem selben Effekt.

Es ist deshalb gut, sich bei der Planung stets vor Augen zu führen, daß IT-Systeme von, mit und für Personen genutzt werden und für sich allein genommen immer nutzlos sind.

„Das Budget reicht nur fürs Wesentliche": Natürlich. Nur, ist es das Wesentliche, neue IT-Funktionalitäten zu bekommen, oder geht es um bessere Ergebnisse? Wenn die Vorteile guter IT-Systeme diskutiert und verkauft werden, und die positiven Ergebnisse, die andere Firmen erzielen konnten, zum Vorbild genommen werden, fällt oft ein guter Teil dessen unter den Tisch, was diese Erfolge ermöglicht hat. Nämlich die Investitionen, die vorab in diesen Organisationen getätigt wurden, um ein Klima und eine Kultur zu schaffen, auf deren Fundament die Veränderung ohne große Verwerfungen möglich war. Das passiert leicht, weil es schwer ist, diese Anstrengungen zu quantifizieren, und einen mechanischen Kausalzusammenhang herzustellen.

Bei der Budgetplanung wird dann viel über Lizenzen, den Programmieraufwand in Stunden und die nötigen Hardwareanpassungen geredet. Und sehr wenig über Schulungen, die sich nicht auf die Programmbedienung beziehen, sondern auf die Hinführung und Einbeziehung der Betroffenen. Und auch die Planung von Zeit und Ressourcen für Meetings und andere Aktivitäten, die nicht dem Austausch von Fakten, sondern der Diskussion und Konsensfindung dienen, fällt gerne mal aus, denn schließlich sollen die Leut´ arbeiten und nicht reden.

Es ist deshalb gut, daran zu denken, daß es die Investition in Personen braucht, um die Investition in Systeme zu sichern.

„Die Experten werden es richten": Ein Blick auf das Organigramm und die Rollenbeschreibungen, die zu der Planung eines Systemwechsels oder einer Systemänderung erstellt werden, kann oft sehr erhellend sein. Das Top-Management fungiert als „Sponsor" und trägt die Verantwortung. Die Projektleitung liegt bei einem IT-Experten, der ist die treibende Kraft, und koordiniert etliche externe Systemexperten mit Unterstützung des internen IT-Supports. In der Peripherie tauchen dann irgendwo die Manager, Supervisoren und Teamleiter auf, deren Bereiche von der Systemänderung betroffen sind. In beratender Funktion, mit gepunkteten Reporting-Linien zum Projektleiter. Und natürlich könnten die ja ihre Mitarbeiter auch mit einbeziehen, wo nötig.

Derart verkürzt wird es sichtbar: Im Zentrum dessen, was passieren soll, stehen Leute, die den „Alltag" der Organisation und das Arbeiten mit den bestehenden Systemen nicht kennen. Das untere und mittlere Management kann sich auf die Funktion beschränken, Fachwissen an das IT-Projektteam zu liefern. Aber wer ist nun für das Change Management verantwortlich? Da gibt es dann den praktischen Begriff der „Gesamtverantwortung" für das Projekt, und damit hat der Projektleiter eine Aufgabe, die ihm vielleicht gar nicht bewußt ist, die ihn aber sicherlich vor ziemliche Probleme stellen dürfte. Ein IT-Experte ist nicht zwingend auch ein Experte für Veränderungsmanagement. Und selbst wenn, tut die Abkoppelung der Projektleitung vom operativen Bereich ein übriges, um allen Beteiligten das Leben schwer zu machen.

Es sind erhebliche Designfehler, wenn die Formung und die Einbettung der Veränderung nicht bei den faktisch Verantwortlichen und Betroffenen liegen, und wenn keine passenden Ressourcen für die Bewältigung dieser Aufgaben eingeplant werden. Und - unnötig zu erwähnen(?) - eine passende Ressource läßt sich nicht dadurch schaffen, daß man irgendwo im Organigramm den Titel „Change Manager" hinzufügt.

Es ist deshalb gut, daran zu denken, daß es die Experten nur richten werden, wenn es für alle relevanten Aufgaben welche gibt, und sie ihre Arbeit auf einem vernünftigen Fundament beginnen können.

In diesem Sinne:

Viel Erfolg!
Martin Haack

VARICON^® Unternehmens- und Managementberatung Stuttgart / München
Kontakt via XING