Die Umsetzungsberatung

Diagnose Ihres Veränderungsvorhabens






Winfried Berner:
"CHANGE!" (Erweit. Neuauflage)

20 Fallstudien zu Sanierung, Turnaround, Prozessoptimierung, Reorganisation und Kulturveränderung

Change! - 20 Fallstudien zu Sanierung, Turnaround, Prozessoptimierung, Reorganisation und Kulturveränderung

Für weitere Informationen
klicken Sie bitte hier.
 

Winfried Berner:
Culture Change

Unternehmenskultur als Wettbewerbsvorteil

Culture Change: Unternehmenskultur als Wettbewerbsvorteil

Für weitere Informationen
klicken Sie bitte hier.
 

Winfried Berner, Regula Hagenhoff, Th. Vetter, M. Führing
"Ermutigende Führung"

Für eine Kultur des Wachstums

Ermutigende Führung: Für eine Kultur des Wachstums

Für weitere Informationen
klicken Sie bitte hier.
 

Winfried Berner:
"Bleiben oder Gehen"

Bleiben oder Gehen

Für weitere Informationen
klicken Sie bitte hier.
 

Anzeige


Anzeige

IT-Systeme: Vier Schwerpunkte für das begleitende Change Management

Druckversion dieser Seite

Entgegen anders lautenden Legenden stellt die Einführung neuer IT-Systeme wie auch die Ablösung bestehender Systeme keine extremen Herausforderungen an das Change Management. Denn sie hat, wie alle Veränderungen an Strukturen und Systemen, die "normative Kraft des Faktischen" auf ihrer Seite: Gleich wie heftig die Diskussionen im Vorfeld waren und wie gut oder schlecht die Kommunikation war, wenn am Stichtag das alte System abgeschaltet wurde, bleibt Mitarbeitern, die Daten abrufen oder eingeben wollen, nichts anderes übrig, als das neue zu benutzen – oder dies zumindest zu versuchen, so gut es das System eben zulässt. Die eigentliche Aufgabe des Change Management liegt denn auch weniger darin, mit aufwändiger Kommunikation ein Scheitern des Projekts zu verhindern, als darum, mit sauberem Handwerk die Reibungsverluste bei der Einführung und dem Betrieb zu minimieren.

  • Normative Kraft des Faktischen
  • Dass die Einführung eines neuen IT-Systems, wie immer wieder kolportiert, am Widerstand der Belegschaft oder gar an einem "Boykott" scheitert, dafür ist mir aus der Praxis kein einziges Beispiel bekannt. In einigen Fällen, wo dies behauptet wurde, habe ich eher den Verdacht, dass die wachsende Unruhe in der Belegschaft wie auch beim Top Management der willkommener Vorwand dafür war, ein verkorkstes Projekt samt der darin versenkten Millionen in der Versenkung verschwinden zu lassen, ohne sich und anderen eingestehen zu müssen, dass das eigentliche Problem nicht der Widerstand war, sondern die Funktionsfähigkeit des IT-Systems. Zuweilen konnte man sogar den Eindruck haben, dass die Projektverantwortlichen die Ängste der Linienmanager und des Top Managements in subtiler Weise geschürt und sie so veranlasst hatten, aus Furcht vor einer operativen Katastrophe schließlich die "Notbremse" zu ziehen. Denn für interne wie externe IT-Verantwortliche ist ohne Zweifel das kleinere Übel, an angeblichen Widerständen gescheitert zu sein, als den Offenbarungseid leisten zu müssen, dass sie es nicht fertiggebracht haben, ein funktionsfähiges System auf die Beine zu stellen.

  • Wahre Gründe des Scheiterns
  • Saubere Bestimmung von Projektzielen, Anforderungen und Umfang

     

    Change Management kann zur erfolgreichen Einführung neuer IT-Systeme vier zentrale Beiträge leisten. Die erste und wichtigste ist, aktiv dazu beizutragen, dass das System auch wirklich das leistet, was das Unternehmen braucht. (Was in der Praxis allerdings oft daran scheitert, dass die späteren Change Manager an dieser zentralen Aufgabe überhaupt nicht beteiligt sind – und dass sie von ihr oft auch fachlich überfordert wären.)

  • Vier zentrale Leistungen
  • Die zweite Aufgabe ist, die späteren Anwender und ihre Linienvorgesetzten realistisch (!) auf das kommende System vorzubereiten – was mit allgemeinen Informationen beginnt, sich mit immer spezifischeren Fragen fortsetzt und schließlich in die Anwenderschulung und den Support mündet. Drittens kann und sollte das Change Management die Schnittstelle zum Betriebsrat und zum Datenschutzbeauftragten koordinieren, die bei IT-Systemen beide ein Mitspracherecht haben. Die vierte, oft übersehene Aufgabe ist die projektinterne Kommunikation. Ihre Notwendigkeit ergibt sich schlicht daraus, dass schon ein mittelschweres IT-Projekt in einem Großunternehmen leicht die Größe eines mittelständischen Betriebs erreicht und es an Komplexität mühelos in den Schatten stellt.

  • Vorbereitung einer möglichst reibungslosen Einführung
  • Der Schlüssel zum Erfolg von IT-Projekten ist die saubere Bestimmung von Projektzielen, Anforderungen und Projektumfang. Denn wenn ein System falsche oder unklare Ziele hat und deswegen an den Bedürfnissen des Geschäfts vorbeigeht, ist das auch durch noch so gute Kommunikation nicht zu heilen. Denn die Vorbehalte der Linie gegen ein neues IT-System sind durchaus nicht immer darin begründet, dass sie nicht genügend informiert sind. Sie können ihren Grund auch genau darin haben, dass sie gut informiert sind – und gerade deshalb größte Bedenken haben, ob das System ihre Anforderungen erfüllen wird. Wer diese Bedenken vorschnell psychologisiert, begeht einen doppelten Fehler: Erstens, weil er die wertvollen Hinweise wegwirft, die in den vorgebrachten Einwänden zumindest enthalten sein können, zweitens weil die mangelnde Ernstnahme den Widerstand entweder herausfordert oder, noch schlimmer, in trotzige Wurstigkeit umschlagen lässt: "Dann sollen sie doch mal sehen, wo sie mit ihrem blöden System hinkommen ..."

  • Vielleicht haben die Kritiker ja Recht ...
  • Dass IT-Systeme den Anforderungen des Geschäfts entsprechen müssen, ist natürlich eine Binsenweisheit, und infolgedessen findet sich auch in jedem Vorgehensmodell ganz zu Beginn eine Phase, in der das Linienmanagement nicht nur nach seinen Wünschen und Bedürfnissen befragt, sondern bis zur Bewegungsunfähigkeit "eingebunden" wird. Dennoch geht schon in dieser frühen Phase oftmals Entscheidendes schief. Das liegt weniger an einem Mangel an gutem Willen, sondern vor allem daran, dass beide Seiten keine gemeinsame Sprache haben: Die IT-Leute verstehen zu wenig vom Geschäft, und die Liniemanager zu wenig von IT, um sich verständigen zu können. Infolgedessen redet man auch in vielen Meetings eher aneinander vorbei als miteinander – und bekräftigt dabei die wechselseitigen Vorurteile, statt zu einem belastbaren Zielkonsens zu kommen.

  • Frühe falsche Weichen- stellung
  • Ängste und Vorbehalte auf beiden Seiten

     

    Das wird dadurch verstärkt, dass die Auftragsklärung unterschwellig auf beiden Seiten mit Misstrauen und Ängsten belastet ist: Die IT-Leute, die das Projekt ja hinterher realisieren müssen, machen sich größte Sorgen, dass ihnen die Linie so viel an "überflüssigen Sonderlocken" in die Spezifikationen schreibt, dass das Projekt hinterher vor Komplexität und Kosten kaum noch handhabbar ist, und erst recht nicht in dem Zeit- und Budgetrahmen, den der Vorstand zuzugestehen bereit scheint. Umgekehrt befürchten die Linienmanager, dass die IT'ler ihre Anforderungen nicht wirklich verstehen (wollen), sondern hauptsächlich daran interessiert sind, ihnen eine möglichst simple, standardisierte Lösung unterzujubeln.

  • Ängste und Misstrauen auf beiden Seiten
  • Die Leute aus dem Business tun sich schwer, ihre operativen Anforderungen in "Specs" zu übersetzen, und erst recht sind sie aus naheliegenden Gründen unsicher, ob ihre Anforderungen mit dem, was da niedergelegt wurde, wirklich vollständig beschrieben sind. Zudem fühlen sie sich überfordert, so weit im Voraus alle wesentlichen Aspekte einzubringen, und haben Angst, sich mit ihrer Unterschrift für alle Zeiten festzulegen und später keine Möglichkeit mehr zu haben, neue Erkenntnisse, und seien sie auch noch so wichtig, in das System einzubringen. Dass die Befürchtungen beider Seiten in aller Regel wenigstens teilweise berechtigt sind, macht den Dialog nicht leichter.

  • Angst vor einer endgültigen Festlegung
  • In der Tat liegt hier ein Konflikt, der keineswegs nur gruppendynamischer Natur ist. Die Projektverantwortlichen haben ja tatsächlich ein Interesse daran, den Umfang und die Komplexität des Projektes so gering wie möglich zu halten, einfach weil die Wahrscheinlichkeit, es innerhalb des Zeit- und Budgetrahmens zu realisieren, umso geringer ist, je mehr an Komplexität hineingepackt wurde. Umgekehrt haben die auftraggebenden Fachabteilungen ein berechtigtes Interesse daran, dass ihr Projekt all die Funktionen umfasst, die zur Erledigung ihrer Arbeit erforderlich sind. Darüber hinaus haben sie in aller Regel den durchaus verständlichen Wunsch, bei dieser Gelegenheit noch ein paar Funktionalitäten mit einzubauen, die für das eigentliche Projektziel vielleicht nicht zwingend erforderlich sind, aber von erheblichem Nutzen für sie wären und – wie sie glauben und hoffen – mit geringem Zusatzaufwand zu realisieren sein müssten.

  • Echter Inter- essenkonflikt
  • Auftragsklärung unter einem schlechten Stern

     

    Ängste, Misstrauen und Vorbehalte auf beiden Seiten sind klassische Empathie-Killer und damit eine ausgesprochen schlechte Voraussetzung für eine produktive Zusammenarbeit, die am Ende den Bedürfnissen beider Seiten gerecht wird. Zumal sich die schlimmsten Befürchtungen zu bestätigen scheinen: Bei den ersten Gesprächen finden die Linienmanager nun schnell heraus, dass die Projektverantwortlichen alle Forderungen und Wünsche abzuwehren versuchen, die zur Erreichung der Projektziele nicht zwingend erforderlich sind – und sie lernen ebenso rasch, alle ihre Sonderwünsche dann eben mit deren Bedeutung für die Verwirklichung der Projektziele zu begründen.

  • Ängste verhindern Empathie
  • Dies wiederum wird den Projektverantwortlichen nach kurzer Zeit unheimlich. Da sie die vorgebrachten Argumente aber inhaltlich oft nicht beurteilen können, beginnen sie nun, auch Forderungen abzuwehren, die zu Recht mit den übergeordneten Projektzielen begründet werden. Daraus entwickelt sich dann jenes Geschacher, das am Beginn vieler IT-Projekte steht und in dessen Ergebnissen oft schon der Keim für das Scheitern des Projekts oder jedenfalls für erhebliche Zeit- und Kostenüberschreitungen gelegt ist.

  • Taktieren auf beiden Seiten
  • Diese Verhandlungen stehen insofern unter einem schlechten Stern, als beide Seiten, wenn sie sich subjektiv vernünftig verhalten, ein Verhalten an den Tag legen, das durchaus nicht im besten Interesse des Unternehmens liegt. Zum ersten treten die Vertreter der Fachbereiche erfahrungsgemäß für manche ihrer Sonderwünsche mit größerer Entschiedenheit ein als für die strategischen Projektziele, teils weil sie die ohnehin für einen "Selbstgänger" halten, teils weil manche davon nicht von ihnen, sondern vom Vorstand kommen und den Fachbereichen gar nicht so wichtig (oder sogar unangenehm) sind.

    Zum zweiten bewerten die IT-Leute die an sie herangetragenen Forderungen weniger nach ihrer Bedeutung für die Projektziele als danach, wie viel Aufwand mit ihnen verbunden ist. Infolgedessen werden sie dazu neigen, Wünsche der Fachbereiche dann zu akzeptieren, wenn sie mit relativ wenig Aufwand zu erfüllen sind (unabhängig von ihrer Bedeutung für die Projektziele), und sie desto heftiger abzuwehren, je mehr Aufwand und Komplexität sie nach sich ziehen würden (ebenfalls unabhängig von deren Bedeutung für die Projektziele).

  • Ablösung vom eigentlichen Ziel
  • Am Ende kann so leicht ein Lastenheft herauskommen, das zwar an wichtigen Projektzielen vorbeigeht, aber dennoch von einer kaum noch zu beherrschenden Komplexität ist. Damit aber sind alle Weichen in Richtung "Katastrophen-Projekt" gestellt: Es wird mit einiger Wahrscheinlichkeit seinen Zeit- und Budgetrahmen überschreiben, und wenn es dennoch einmal fertig ist, wird sich herausstellen, dass es die Ziele, um derentwillen es gestartet wurde, nur zum Teil erfüllt.

  • Keim des Scheiterns

  • Change! - 20 Fallstudien Zahlreiche Fallbeispiele zu den unterschiedlichsten Typen von Change-Projekten finden Sie in meinem Buch "Change! – 20 Fallstudien zu Sanierung, Turnaround, Prozessoptimierung, Reorganisation und Kulturveränderung" (Schäffer-Poeschel, 2. erweiterte Auflage 2015). Es vermittelt Ihnen einen breiten Überblick über die unterschiedlichsten Arten von Veränderungsprozessen und zeigt Ihnen, worauf es jeweils ankommt, um Ihre Change-Vorhaben zum Erfolg zu führen.

    Mehr Informationen über das Buch "Change! – 20 Fallstudien"


  • Buch "Change!"
  • Für einen belastbaren Zielkonsens sorgen

     

    Gerade wegen dieser Risiken kann die Bedeutung einer sauberen Auftragsklärung für Erfolg und Akzeptanz von IT-Projekten gar nicht hoch genug eingeschätzt werden: nicht nur wegen der friedensstiftenden Wirkung eines belastbaren Zielkonsens', sondern auch wegen des effizienzsteigernden Effekts klarer Ziele. Deshalb lohnt es sich hier auch, einen sachkundigen Moderator einzuschalten, der sowohl die Aufgabe hat, einen konstruktiven Dialog zwischen Fachbereichen und Projektverantwortlichen zu erleichtern ("Facilitator") und den Interessenkonflikt zu einer möglichst sachgerechten Lösung zu führen, als auch darauf zu achten, dass die übergeordneten Projektziele in schlüssiger Weise in die Struktur und den Umfang des Projekts übersetzt werden.

  • Sachkundiger Moderator
  • Auch wenn es bei dieser Moderation nicht zuletzt um die Emotionen geht, die hinter den inhaltlichen Forderungen und ihrer Abwehr stehen, muss der Moderator sowohl die Geschäftsabläufe, die hier automatisiert oder IT-unterstützt werden sollen, als auch die eingesetzte Informationstechnologie wenigstens in den Grundzügen verstehen. Vor allem aber muss er auch den betriebswirtschaftlichen oder strategischen Sinn des Projektes durchdrungen und verinnerlicht haben.

  • Fach- und IT-Kenntnisse unverzichtbar
  • Das heißt aber auch, dass ein Change Manager oder Moderator ohne spezifische Fachkenntnisse hier keine große Hilfe ist: Wer die vorhandenen "Sprachen" nicht versteht, kann auch nicht übersetzen, sondern würde die Verständigung eher zusätzlich verkomplizieren. Gefragt ist hier kein Change-Spezialist, sondern ein "Hybride" zwischen IT und dem jeweiligen Fachgebiet, die zusätzlich Moderationskenntnisse und ein ausgeprägtes Strukturierungsvermögen besitzt. Trotzdem liegt die eigentliche Wertschöpfung des Moderators nicht in seinem Sachverstand, sondern darin, ein wechselseitiges Verständnis für die Bedürfnisse und Anliegen der jeweils anderen Seite aufzubauen und damit das gegenseitige Vertrauen zu fördern.

  • Gegenseitiges Vertrauen fördern
  • Bei dieser Auftragsklärung ist es erforderlich, ins Detail zu gehen und nicht nur zu definieren, welche nachprüfbaren Leistungen das System bieten soll, sondern auch, auf welche Weise dies erreicht werden soll. Denn daraus ergibt sich auch der Projektumfang ("scope"), also die Abgrenzung, was zwingend Bestandteil des Projekts sein muss und welche Komponenten, Wünsche und Ideen entweder ganz weggelassen oder in einem späteren Release hinzugefügt werden können. Diese Eckpunkte müssen nicht bloß schriftlich dokumentiert, sondern auch allen Mitarbeitern und "Stakeholdern" des Projekts bekannt gemacht und immer wieder als dessen Geschäftsgrundlage im Bewusstsein aller Mitwirkenden verankert werden.

  • Ziele, Logik und Projektumfang
  • Bewusste Beschränkung auf die "Essentials"

     

    Die feste Verankerung von Zielen, Logik und Scope und die konsequente Beschränkung auf die "Essentials" ist deshalb dringend zu empfehlen, weil die Wahrscheinlichkeit, das Projekt im vorgesehenen Zeit- und Budgetrahmen abzuschließen, umso größer ist, je besser es gelingt, seinen Umfang und seine Komplexität auf das absolut Unvermeidliche zu reduzieren. Zugleich hilft dies, späteren Crash-Aktionen zur Reduktion von Komplexität und Umfang vorzubeugen.

  • Beschränkung statt späterer Crash-Aktionen
  • Denn für jedes größere IT-Projekt lässt sich risikolos vorhersagen, dass spätestens, wenn es eng wird, der Versuch gemacht werden wird, den Projektumfang "abzustrippen", indem angeblich überflüssige, aber arbeitsaufwändige Komponenten herausgestrichen werden. So sinnvoll dies zur Bewältigung einer akuten Krise ist, so ineffizient ist es im Grundsatz, weil zu diesem Zeitpunkt natürlich schon viel Zeit und Geld in jene Module geflossen ist, die dann notgedrungen über Bord geworfen werden. Nichts beugt solchen Krisen wirksamer vor als eine "Projektbibel", aus der klar hervorgeht, welche Bestandteile zur Erreichung der übergeordneten Projektziele zwingend erforderlich sind – und die den Projektumfang wenigstens für das erste Release konsequent auf jene Schlüsselkomponenten beschränkt.

  • Nachträgliches "Abstrippen" ist ineffizient
  • Diese konsequente Beschränkung des Projektumfangs ist konfliktträchtig, weil es den Fachbereichen oft schwer fällt einzusehen, weshalb es nicht mit ein bisschen gutem Willen möglich sein sollte, einige ihnen besonders wichtige Features von Anfang an in den Projektumfang aufzunehmen. Und es ist sowohl für den Projektleiter als auch für den Moderator und die Eskalationsinstanzen zuweilen naheliegend, um des lieben Friedens willen den drängendsten Forderungen der Fachbereiche nachzugeben.

  • Frühzeitiges Konflikt- management
  • Dennoch sind der Moderator und die Projektverantwortlichen gut beraten, vor allem den Fachbereichen klarzumachen, dass sie dabei möglicherweise von falschen Alternativen ausgehen: Sie haben nicht wirklich die Wahl zwischen einem guten, aber aufs Allernötigste beschränkten System und einem ebenfalls guten, aber deutlich umfangreicheren System. Vielmehr lautet die zweite Alternative in Wahrheit völlig anders: Sie besteht aus einem mäßigen bis schlechten System, das zwar sämtliche Zeit- und Budgetplanungen gesprengt hat, aber im Leistungsumfang kaum mehr bietet als die erste Alternative, weil all diese Wunsch-Features (und etliche andere) im Rahmen einer Crash-Aktion zur Projektsanierung brachial abgestrippt wurden.

  • Falsche Alternativen überwinden
  • Lohnende Anfangsinvestition

     

    Gerade wegen dieses Konflikts ist eine lohnende Investition, einen fachkundigen Change Manager als Moderator für die Anforderungsdefinition hinzuzuziehen. Das erleichtert eine saubere Auftragsklärung, die sowohl dem Bedürfnis der IT-Verantwortlichen nach verlässlichen Spezifikationen Rechnung trägt als auch dem ebenso berechtigten Anliegen der Linie, ein System zu bekommen, das hinterher auch den Anforderungen des Geschäfts gerecht wird. Vor allem aber trägt es dazu bei, dass sich beide Seiten – aber vor allem die Linie – mit dem erzielten Ergebnis sehr viel wohler fühlen als wenn sie das Gefühl mitnehmen, von den Projektverantwortlichen zu einer Unterschrift genötigt worden zu sein, deren Tragweite und Konsequenzen sie nicht überschauen.

  • Entlastung durch Moderation
  • Wenn die Linie sich mit der Auftragsdefinition wohl fühlt, profitiert davon letztlich auch das Projekt: Es reduziert die Ängste, mit einem nicht arbeitsfähigen System konfrontiert zu werden, mit dem sich Teile des Tagesgeschäfts gar nicht bewältigen lassen, und macht so zum einen die hektische Anmeldung immer weiterer Änderungswünsche unwahrscheinlicher und kommt zum anderen der Akzeptanz des eingeführten Systems zugute. Denn je besser sich in der Auftragsdefinition tatsächlich die zentralen operativen Anforderungen abbilden, desto wahrscheinlicher ist, dass das System hinterher den Anforderungen entspricht – und das erleichtert die Einführung ungemein.

  • Abbau von Ängsten und Stress
  • Klärungsbedürftig ist im Vorfeld die genaue Rolle und der Auftrag des Moderators: Soll er ein "inhaltliches Neutrum" sein, das zwar nach besten Kräften versucht, einen Konsens zwischen Projekt und Fachabteilungen herbeizuführen, aber selbst keine Stellung bezieht, oder soll – gewissermaßen er als Beauftragter des Vorstands oder des Lenkungsausschusses – zugleich als Gralshüter der übergeordneten Projektziele fungieren? Letzteres ist ohne Zweifel die schwierigere Rolle, sowohl inhaltlich als auch emotional. Dennoch hat sie einiges für sich, weil der Moderator so am wirksamsten der oben beschriebenen Tendenz zur Loslösung des Lastenhefts von den Projektzielen entgegenwirken kann.

  • Rolle des Moderators
  • Auch wenn diese zweite Variante sicherlich nicht der reinen Lehre der Moderation entspricht, ist sie im übergeordneten Interesse des Unternehmens zumindest erwägenswert. Wichtig ist aber, dass dabei von vornherein mit offenen Karten gespielt wird, denn wenn die Teilnehmer den Eindruck bekommen, dass der Moderator seine eigene Agenda und/oder einen heimlichen Steuerungsauftrag hat, dann hat er sein Vertrauen verspielt.

  • Mit offenen Karten spielen
  • Kommunikation: Bitte kein euphorisches Geplapper ("Happy Talk")!

     

    Am Anfang, solange die Einführung des neuen Systems noch in weiter Ferne liegt, hält sich das Interesse der meisten Mitarbeiter und Führungskräfte in engen Grenzen: Man will grob informiert sein, was läuft, aber damit genügt es auch. Das gilt erst recht, wenn die Fachbereiche intensiv an der Definition des Lastenheftes beteiligt waren und von dort mit einem guten Gefühl zurückgekommen sind. Denn diese gute Vorarbeit bedeutet für sie erst einmal Entwarnung: Wenn das Projekt richtig eingestielt wurde, kann man es bis auf Weiteres "machen lassen" und darauf vertrauen, dass die Dinge schon ihren Gang gehen – wenn das Projekt soweit ist, soll es Bescheid sagen.

  • Begrenztes Interesse
  • Seien Sie daher auf einen ähnlichen Verlauf des Interesses gefasst wie bei vielen anderen Neuerungen: Zunächst eine erstaunlich lange Zeitspanne, in der sich keiner für das Thema interessiert, die kurz vor der Einführung plötzlich umschlägt in eine Stimmung, wo sich alle furchtbar schlecht informiert fühlen. An diesem Muster lässt sich auch durch noch so "proaktive" Kommunikation wenig ändern, einfach weil es zuvor an der Aufnahmebereitschaft fehlt. Im Grunde gibt es auch keine Notwendigkeit für die Mitarbeiter, sich schon Monate oder gar Jahre im Voraus mit dem neuen System zu befassen.

  • Keinen Overkill betreiben ...
  • Statt daher mit immer neuen Kommunikationsmaßnahmen gegen das allgemeine Desinteresse anzurennen, ist es klüger, den anfänglichen Interessemangel als (völlig unproblematische) Tatsache zu akzeptieren, die Mitarbeiter und Führungskräfte aber fortlaufend "auf kleiner Flamme", zum Beispiel über das Intranet oder die Werkszeitung, informiert zu halten – und im übrigen auf einen sprunghaften Anstieg des Interesses kurz vor dem "Go-Live" vorbereitet zu sein.

  • ... aber bereit sein
  • Die Kommunikation bei der Einführung von IT-Systemen ist kein Hexenwerk, sondern brave, biedere Fleißarbeit. Wenn Ihnen an Ihrer eigenen Glaubwürdigkeit und an der des gesamten Projekts gelegen ist, verzichten Sie bewusst auf Glamour und unterlassen jede schönfärberische Glorifizierung des neuen Systems – selbst wenn dies von der Projektleitung oder dem Top Management möglicherweise erwartet wird! Man kann selbst gutmütige Zeitgenossen zur Raserei bringen, wenn man alle negativen oder problematischen Aspekte konsequent verschweigt und sich stattdessen in allgemeinen Lobpreisungen der "schönen neuen IT-Welt" ergeht. Zudem liefern solche Verklärungen nur ein äußerst kurzlebiges Hochgefühl: Es weicht umso größerer Enttäuschung, wenn das neue System schließlich eingeführt wird und vor dem Hintergrund der hochgejubelten Erwartungen eine umso kläglichere Figur macht. Wer so kommuniziert, braucht sich nicht wundern, wenn die Mitarbeiter bald mit Demotivation und Zynismus reagieren.

  • Selbstgemachte Enttäuschung
  • Die Alternative dazu ist, ganz einfach so ehrlich und realistisch zu sein wie nur möglich. Man muss und sollte das Projekt nicht schlechter machen als es sein wird, aber man sollte auch keinerlei Erwartungen nähren oder auch nur entstehen lassen, die – wenigstens im ersten Release – nicht in Erfüllung gehen werden. Gerade das erste Release eines neuen Systems wird unvermeidlich viele Erwartungen und Hoffnungen nicht erfüllen; daran lässt sich nicht viel ändern, deshalb ist es besser, ehrlich zu sein. "The baby will be ugly", sagte die Change-Managerin eines großen IT-Projekts bei einer Managementtagung, in der alle nur "Happy Talk" erwarteten – und löste damit befreites Gelächter aus.

  • Ehrlich und realistisch sein
  • Das ist allerdings aus zwei Gründen gar nicht so einfach. Der eine ist, dass manche Mitarbeiter und Linienführungskräfte so hartnäckig und suggestiv nach ihren Lieblings-Features fragen, dass es oft schwer fällt, ihnen ein klares und unzweideutiges "Nein" zur Antwort zu geben. Der zweite ist, dass solch eine klare Linie zuweilen auch die Projektverantwortlichen und das Top Management irritiert, mit der Folge, dass sie sich möglicherweise dagegen verwahren, "das Projekt öffentlich schlecht zu reden". Aber es hilft ja nichts: Das Projekt wird später nicht nur an den Erwartungen gemessen, die es selbst geweckt hat, sondern auch an denen, die es durch Unterlassen klarer Aussagen entstehen ließ. Und je höher der Maßstab, desto sicherer seine Verfehlung.

  • "The baby will be ugly"
  • Sorgfältige Vorbereitung und Begleitung der Systemeinführung

     

    Solange es noch nicht darum geht, die Systemeinführung konkret vorzubereiten, bringt es wenig, die Mitarbeiter mit ständigen Informationen über den Projektstand zu überhäufen. Solange die Fachbereiche noch nicht direkt betroffen sind, gibt es kaum Nachrichten, die für sie wirklich spannend sind. Klar ist es für das Projekt eine tolle Sache, wenn die erste probeweise Datenbank-Migration gelungen oder der Integrationstest erfolgreich verlaufen ist. Doch für die Mehrzahl der Mitarbeiter hat das kaum mehr Nachrichtenwert als die Eröffnung einer Vertriebsniederlassung in Kuala-Lumpur oder die Einweihung einer neuen Lagerhalle. Deshalb genügend eine "Informationspolitik auf kleiner Flamme": gelegentliche Informationen über den Projektfortschritt und die bevorstehenden nächsten Schritte.

  • Information auf kleiner Flamme
  • Trotzdem kann man auch in dieser Phase ein Vielfaches an Aufwand betreiben. Man kann zum Beispiel, wie es die sogenannte "ASAP-Methodik" von SAP vorsieht, mit aufwändigen Befragungen das "People Risk" bei der Einführung des neuen Systems bestimmen. (Ein charmanter Ansatz, nebenbei gesagt, die eigenen internen Kunden als Risikofaktor zu identifizieren und zu be-managen.) Man kann groß angelegte "Road-Shows", Info-Märkte und ähnliche Events veranstalten – das schadet alles sicherlich nicht, aber es ist auch zweifelhaft, ob es etwas nützt.

  • Aufwändige Placebos
  • Manche der empfohlenen Maßnahmen erinnern eher an Regentänze: Sie verändern das Wetter nicht wirklich, aber sie halten die Leute beschäftigt, bis der Regen endlich kommt. Insofern sind sie unschädlich: Wenn das System etwas taugt, wird seine Einführung zwar mit großer Wahrscheinlichkeit auch dann gelingen, wenn in Sachen Kommunikation ein maßloser Overkill betrieben wurde. Falls es nichts taugt, lag sein Scheitern nicht an der Kommunikation, war aber auch mit noch so viel Kommunikation nicht zu verhindern. Die mangelnde Akzeptanz eines IT-Systems ist in aller Regel nicht die Ursache, sondern die Folge des Scheiterns.

  • Regentänze schaden nicht, nützen aber auch wenig
  • Große Bedeutung bekommt die Kommunikation jedoch dann, wenn es konkret auf die Einführung des Systems zugeht – und erst recht, wenn dies auch mit organisatorischen Änderungen verbunden ist. Allgemeine Informationen stoßen hier rasch an ihre Grenzen, denn die Mitarbeiter interessieren sich nun einmal weniger für die Systemarchitektur und den betriebswirtschaftlichen Nutzen – sie wollen vor allem wissen, welche Auswirkungen das System auf ihren Arbeits- und Verantwortungsbereich hat: Löst es bisher bestehende Probleme? Schafft es neue?

    Das heißt keineswegs, dass es überflüssig ist, den Mitarbeitern die übergeordneten Projektziele zu erklären und den betriebswirtschaftlichen Nutzen zu verdeutlichen. Aber dies sind eher flankierende Hintergrundinformationen; auf die Dauer können sie eine Antwort auf die konkreten operativen Auswirkungen vor Ort nicht ersetzen. Wer auf solch handfeste Fragen nur allgemeine Ausführungen über die Vorzüge des neuen Systems zu bieten hat, löst bald nur noch Verärgerung aus. Um aber eine befriedigende Antwort geben zu können, ist es mit jedoch reiner Systemkenntnis nicht getan; dazu muss man mit den Arbeitabläufen an den vom System unterstützten Arbeitsplätzen vertraut sein, und zwar idealerweise sowohl im Zustand vor der Systemeinführung als auch danach.

  • Spezifische Antworten gefragt
  • Nicht schöne Worte, sondern handfeste Unterstützung

     

    Da der oder die Change Manager aber kaum mit allen Arbeitsabläufen vor Ort vertraut sein können und in der heißen Phase der Einführung außerdem schnell an die Grenzen ihrer Kapazitäten stoßen, ist es bei größeren IT-Projekten meist sinnvoll, für die Unterstützung der Systemeinführung interne Multiplikatoren einzusetzen. Ideal sind dafür Mitarbeiter aus den betroffenen Bereichen, die erstens eine gewisse IT-Affinität besitzen, zweitens kommunikativ sind und drittens im eigenen Bereich geschätzt und angesehen sind. Sie müssen besonders früh und besonders intensiv mit dem neuen System vertraut gemacht werden, damit sie ihren Kollegen vor Ort in der heißen Phase als Auskunftspersonen, Ansprechpartner und Ermutiger dienen können.

  • Multiplikatoren vor Ort
  • Eine sorgfältige Vorbereitung und Betreuung der Multiplikatoren ist von zentraler Bedeutung, denn wenn ihre ersten Eindrücke negativ bekommen, können sie auch im Schlechten als Multiplikatoren wirken – und dann ist das Projekt in Not. (Wer seinen "Multis" das Leben nicht unnötig erschweren möchte, sollte ihnen übrigens keine allzu hochtrabenden Titel verleihen: Wenn man sie als "Change Champions" oder "System Wizards" tituliert und sie deswegen von ihren Kollegen als aufgezogen werden, fördert das in aller Regel nicht ihre Identifikation mit der Aufgabe.)

  • Schulung und Betreuung der "Multis"
  • Klar ist, dass die Nutzer bei komplexeren Anwendungen für deren Bedienung geschult werden müssen. In letzter Zeit wird hier zunehmend das Thema "E-Learning" diskutiert und erprobt, also das Lernen am eigenen Bildschirm. Ich habe jedoch Zweifel, ob das wirklich der Weg der Zukunft ist – nicht, weil PC-gestütztes Lernen prinzipiell unmöglich wäre, sondern weil es erstens schwierig ist, es in den normalen Büroalltag zu integrieren, und weil zweitens die soziale Komponente des Lernens fehlt. Das klassische Präsenz-Lernen hat halt bei all seinen Mängeln und Kosten den ganz banalen Vorteil, dass es eine "institutionalisierte Auszeit" zum Lernen schafft: Die Mitarbeiter sind in dieser Zeit eben "auf Schulung", was in der Regel auch von ihren Chefs und Kollegen respektiert wird. Theoretisch könnten sie natürlich auch einen Termin mit sich selber in ihren Kalender eintragen: "8 – 12 Uhr E-Learning". Faktisch tun das jedoch kaum jemand; infolgedessen absolvieren viele das elektronische Training nur unvollständig, spät und unter Schwierigkeiten. Was sich dann natürlich bei der Einführung rächt.

  • Leibhaftiges Nutzer-Training
  • Diese Schwierigkeiten werden dadurch verstärkt, dass Umlernen auf ein neues System immer mit Frustrationen und oftmals auch mit Ängsten verbunden ist: Frustrationen, weil im neuen System mit Sicherheit manche Funktionen anders gestaltet und manche Abläufe anders strukturiert sind als im alten. Die Umgewöhnung erträgt sich leichter, wenn man gemeinsam auf "die Idioten, die das verbockt haben", schimpfen kann. Auch die Ängste, die vor allem bei (mental) älteren Arbeitnehmern oft auftreten, wenn sie mit der Notwendigkeit zum (Um)Lernen konfrontiert werden, sind in der Gruppe leichter zu ertragen: Die aufflackernde Panik, den neuen Anforderungen nicht mehr gewachsen zu sein, relativiert sich, wenn man sieht, dass die Kollegen auch zu kämpfen haben.

  • Emotionale Entlastung
  • Diese emotionale Entlastung ist in ihrer Bedeutung für eine reibungsarme Systemeinführung nicht zu unterschätzen. Wenn es dennoch aus Zeit- oder Kostengründen E-Learning sein muss, sollten auf jeden Fall die betroffenen Fachvorgesetzten mit in die Verantwortung genommen werden, etwa indem man es zum Teil ihrer Zielvorgaben macht, dass ihre Mitarbeiter die elektronischen Kurse tatsächlich erfolgreich absolvieren. (Was ja durch Training-Management-Systeme einfach überprüft werden kann – sofern der Betriebsrat mitspielt!)

  • Rolle der Vorgesetzten
  • Schnittstelle zu Betriebsrat und Datenschutzbeauftragtem

     

    Der Betriebsrat hat bei der Einführung neuer und der Ablösung alter IT-Systeme ein gewichtiges Wörtchen mitzureden. Der § 87 Abs. 1 Ziffer 6 des Betriebsverfassungsgesetzes sieht ausdrücklich eine Mitbestimmung bei der "Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen" vor. Das klingt zunächst, als ob sich die Mitbestimmung nur auf Überwachungssysteme beziehen würde. Da der Arbeitgeber die Beweislast hat, dass IT-Systeme nicht zur Überwachung verwendet werden, bekommt die Formulierung "dazu bestimmt" faktisch die Bedeutung von "prinzipiell dazu geeignet".

    Mit anderen Worten, die Mitbestimmung entfiele nur dann, wenn der Arbeitgeber dem Betriebsrat nachweisen würde, dass es technisch unmöglich ist, mit dem neuen System die Leistung oder das Verhalten von Mitarbeitern zu überwachen. Das ist es aber in der Regel nicht, weil zum Beispiel datenbankgestützte Systemen fast immer automatisch protokollieren, wer Einträge gemacht und Änderungen vorgenommen hat. Damit aber lassen sich auch Fehler und Mängel auf ihre Urheber zurückverfolgen: eindeutig eine mögliche Leistungskontrolle. Doch auch schon das, was versteckt in ganz normalen Office-Dokumenten abgespeichert wird, dürfte genügen, um nicht nur Betriebsräte, sondern auch Datenschützer auf den Plan zu rufen.

  • Mitbestim-mungsrechte
  • Da Unternehmen in aller Regel nicht darauf verzichten können und wollen, in Logfiles zu dokumentieren, wer Datensätze eingegeben oder bearbeitet hat, muss vor der Einführung neuer IT-Systeme eine Betriebsvereinbarung darüber abgeschlossen werden, welche Daten aufgezeichnet werden dürfen und welche Spielregeln für den Umgang mit diesen Daten gelten. Zweckmäßigerweise sollte man damit nicht erst beginnen, wenn das System fertig und einführungsreif ist, denn der Betriebsrat wird sich mit großer Wahrscheinlichkeit querlegen, wenn er sich vor vollendete Tatsachen gestellt sieht. Es ist daher ratsam, Gespräche mit dem Betriebsrat spätestens dann aufzunehmen, wenn das Lastenheft für das neue System steht, wenn also, arbeitsrechtlich gesprochen, die Willensbildung des Arbeitgebers abgeschlossen ist. Zu diesem Zeitpunkt ist es vielleicht noch zu früh, um in Verhandlungen einzutreten, aber es wirkt auf jeden Fall vertrauensbildend, wenn der Betriebsrat von Anfang an informiert ist, und reduziert überdies seine spätere Einarbeitungszeit.

  • Betriebs- vereinbarung
  • Je größer ein Projekt ist, desto höher ist die Wahrscheinlichkeit, dass auch der Betriebsrat seine Drähte in das Projekt hinein hat. Doch ist es ratsam, sorgfältig zu trennen zwischen formellen und informellen Kontakten. Die förmliche Unterrichtung des Betriebsrats ist nicht durch beiläufige Informationen ersetzbar und erst recht nicht durch die Mitarbeit von Betriebsratsmitgliedern in dem Projekt. Ebenso wenig kann und darf jedes beliebige Teilprojekt offizielle Gespräche mit dem Betriebsrat oder gar Verhandlungen führen. Daher ist anzuraten, die offiziellen Kontakte zum Betriebsrat an einer Stelle im Projekt zu bündeln, die dabei natürlich in enger Absprache mit dem Projektleiter handeln muss.

    Sofern diese Aufgabe nicht durch den Personalbereich abgedeckt wird, bietet sich das Change Management dafür an, zumal hier auch die übrige Kommunikation in das Unternehmen hinein koordiniert wird und eine Konsistenz der Aussagen gegenüber der Belegschaft und dem Betriebsrat nicht nur aus taktischen Gründen anstrebenswert ist. Diese projektinterne Stelle muss sich ihrerseits eng mit der Personalabteilung koordinieren, denn dort sitzt in aller Regel eine Person oder Einheit, die für die Beziehungen zum Betriebsrat generell verantwortlich ist, und die sollte zur Vermeidung von Komplikationen nicht übergangen werden.

  • Ein Ansprech- partner für den Betriebsrat
  • Juristisch eine völlig andere Baustelle, praktisch aber oft verzahnt ist die Zusammenarbeit mit dem betrieblichen Datenschutzbeauftragten. Seine Rolle ergibt sich nicht aus der Betriebsverfassung, sondern aus dem Bundesdatenschutzgesetz sowie aus europäischen Richtlinien, und sie besteht im Kern darin, auf den gesetzeskonformen Umgang mit personenbezogenen Daten zu achten. Dabei ist er nicht nur für die Daten von Betriebsangehörigen zuständig, sondern auch für die von Betriebsfremden, also beispielsweise von Kunden, Lieferanten und Besuchern. In vielen Unternehmen existiert zwischen Betriebsrat und Datenschutzbeauftragtem eine informelle Arbeitsteilung, wonach der Betriebsrat sich auf den Datenschutzbeauftragten verlässt, was den Schutz der personenbezogenen Daten von Betriebsangehörigen betrifft. Doch das muss von Fall zu Fall geklärt werden; auf keinen Fall dürfen sich die Projektverantwortlichen einfach darauf verlassen, dass der "interne Datenschutz" über die Absprachen mit dem Datenschutzbeauftragten abgedeckt ist oder der Datenschutz generell durch die Verhandlungen mit dem Betriebsrat, außer wenn dies ausdrücklich so vereinbart ist. Um auch diese Schnittstelle sauber zu managen, sollten die Change Manager auch der offizielle Ansprechpartner für den Datenschutzbeauftragten sein und das Gespräch mit ihm frühzeitig suchen.

  • Datenschutz- beauftragter
  • Interne Komplexität größer als bei einem Mittelständler

     

    Häufig wird übersehen, dass schon mittlere IT-Projekte rasch die Mitarbeiterzahl und das Budget eines mittelständischen Unternehmens erreichen: Es ist durchaus nicht ungewöhnlich, dass 50, 100 oder gar mehrere 100 Mitarbeiter über etliche Monate oder gar Jahre an einem Projekt arbeiten. Die Informations- und Kommunikationsprobleme, die sich dabei ergeben können, stellen mühelos diejenigen eines Mittelständlers in den Schatten. Denn bei den Mitarbeitern des Projekts handelt es sich in aller Regel nicht um eine gewachsene Mannschaft, in der wie bei einem Mittelständler jeder jeden kennt, sondern um einen bunt zusammengewürfelten Haufen von Internen und Externen, von IT-Fachleuten wie von Mitarbeitern aus den betroffenen Geschäftsbereichen. Von denen wiederum arbeiten längst nicht alle freiwillig in dem Projekt mit, sondern wurden mit mehr oder weniger belastbaren Vorinformationen, Aufträgen und Versprechungen dorthin abkommandiert.

  • Große und heterogene Truppe
  • Die Heterogenität hat nicht nur Auswirkungen auf die Motivation, sondern bedingt auch unterschiedliche Interessenlagen, die im Projektverlauf an den unterschiedlichsten Stellen unvermittelt aufbrechen können. So kann zum Beispiel ein Interessenkonflikt zwischen Internen und Externen über die Abwägung zwischen schnellstmöglicher Fertigstellung und der sorgfältigen Implementierung von Prozessen und Abläufen bestehen. Dieser Konflikt kann durch eine geeignete Vertragsgestaltung – etwa durch Vertragsstrafen für die externen Berater bei Terminverzögerungen – noch deutlich "herzhafter" gestaltet werden.

  • Interessen-konflikte
  • Auch die Zusammenarbeit unterschiedlicher Beratungsfirmen, wie sie bei Großprojekten nicht selten vorkommt, hat ihre Tücken. Da genügt es schon, wenn auch nur eine unterausgelastete Beratungsfirma von ihren Mitarbeitern erwartet, zusätzliche Ressourcen in das Projekt zu verkaufen, und bei ihren Beraterkollegen zu "wildern" beginnt. Und schließlich sind auch Interessenkonflikte zwischen Mitarbeitern der IT und denen der Fachabteilung nicht ungewöhnlich: Die einen identifizieren sich meist stärker mit dem Projekt und seinen Zielen, während die anderen einerseits bald wieder "heim ins Reich" wollen, sich andererseits aber auch als Interessenvertreter ihrer Vorgesetzten und Kollegen in dem Projekt verstehen.

  • Koordination mehrerer Beratungsfirmen
  • In dieser Gemengelage entsteht eines sicherlich nicht spontan, nämlich ein Zusammengehörigkeitsgefühl wie bei einem Mittelständler oder gar ein "Team Spirit", der die freiwilligen und unfreiwilligen Projektmitglieder miteinander und mit ihrer Aufgabe verbindet. Wenn hier nicht gezielt etwas geschieht, um dem entgegenzusteuern, ist die naheliegendste Entwicklung eine "Verinselung" des Gesamtprojekts: Die einzelnen Teammitglieder kapseln entweder in ihrem Arbeitsteam ab oder mit den Teammitgliedern gleicher Provenienz. So entsteht "entfremdete Arbeit": Die Leute arbeiten einzeln oder in kleinen Gruppen vor sich hin, aber das Gefühl, damit zu etwas sinnvollem Größerem beizutragen, entwickelt sich kaum, Identifikation mit und Loyalität zu dem Projekt ebenso wenig.

  • "Verinselung" des Projekts
  • Aus all diesen Gründen sind die Informations- und Kommunikationsprobleme eines Großprojekts in aller Regel deutlich größer als in einem vergleichbaren mittelständischen Unternehmen. Zugleich ist der Informations- und Orientierungsbedarf sehr viel höher, denn in einem solchen Projekt gibt es ja keine Routine des Tagesgeschäfts, an der man sich innerlich festhalten kann. Emotional überforderte Mitarbeiter können sich daher nicht darauf zurückziehen, ohne Einblick in übergeordnete Zusammenhänge einfach ihre Arbeit zu machen und tagein, tagaus Abdeckbleche zu montieren oder die Lohn- und Gehaltsabrechnung zu machen.

  • Hoher Informations- und Orientierungsbedarf
  • Kommunikation innerhalb des Projekts

     

    Das hat zur Konsequenz, dass die Projektleitung das Entstehen eines "Wir-Gefühls" nicht, wie oft bei kleineren Projekten, ohne eigenes Zutun geschenkt bekommt: Ein Teamgeist und ein gemeinsames "Commitment" für das übergeordnete Ziel wird nur entstehen, wenn sie aktiv etwas dafür tut. Ein ausführliches Kickoff-Meeting, das die Projektziele verankert, aber auch genügend Raum zum Beschnuppern und gegenseitigen Kennenlernen lässt, ist in jedem Fall eine gute Anfangsinvestition. Eine externe Moderation ist dafür nicht zwingend erforderlich; sie hat aber den Vorteil, dass alle Beteiligten den oder die Moderatoren kennenlernen und bei positivem Verlauf ein gewisses Vertrauen entwickeln. Das kann im weiteren Verlauf von Vorteil sein, weil dann bei Konflikten und Krisen die Hemmschwelle deutlich geringer ist, fremde Unterstützung in Anspruch zu nehmen: Man kennt sich ja bereits.

  • Kickoff-Meeting
  • Doch auch hier geht es nicht um Hexenkunst, sondern "nur" um sauberes Handwerk: Um die fortlaufende (und ehrliche!) Information aller Projektmitarbeiter über den Projektfortgang, denn falsche Hurra-Meldungen werden von den Projektbeteiligten noch eher durchschaut als von der Belegschaft insgesamt, mit fatalen Rückwirkungen auf die Glaubwürdigkeit der Projektleitung. Bewährte Instrumente hierfür sind regelmäßige Info-Veranstaltungen im direkten Anschluss an die Lenkungsausschuss-Sitzungen, aktuelle Informationen per Newsletter zwischendurch und die Nutzung passender Gelegenheiten zum Feiern. Nützlich ist weiterhin von Zeit zu Zeit ein Workshop, um eine Zwischenbilanz zur Sache und zum Prozess zu ziehen.

  • Konsequenz und Beharrlichkeit
  • Falls der Projektleiter nicht zusätzlich zu all seinen übrigen Fähigkeiten ein ausgesprochenes Führungs- und Kommunikationstalent ist, ist es sinnvoll, mit ihm ein regelmäßiges "Kommunikations-Coaching" zu vereinbaren. Dann übernehmen der oder die Change Manager auch die Planung und Koordination der projektinternen Kommunikation und arbeiten dem Projektleiter entsprechend zu. Sie entwerfen Newsletter und Vorträge, sorgen für regelmäßige Informationsveranstaltungen, versorgen den Projektleiter mit Feedback aus dem Projekt und machen ihm bei Bedarf Vorschläge für besondere Maßnahmen, seien es nun Feste oder Krisensitzungen. Auf diese Weise kann das Change Management einen erheblichen Beitrag zum Teamklima in dem Projekt und damit letztlich auch zu dessen Produktivität leisten.

  • Coaching des Projektleiters
  • All dies ist, wie gesagt, keine Hochtechnologie, es erfordert "nur" Beharrlichkeit und Konsequenz – also schlicht, dass man es macht und dass man es auch unter Stress und Zeitdruck durchhält. Was sich sehr viel leichter liest und abnickt als es in der Praxis unter dem Dauerstress und Zeitdruck eines Großprojekts in die Tat umzusetzen. Auch insofern ist die Change Management-Begleitung von IT-Projekten ein gutes Trainingsfeld für angehende Change Manager: ohne extreme Schwierigkeiten, aber vielfältig und abwechslungsreich – und vor allem herausfordernd genug, um seine Steher-Qualitäten zu testen.

  • Resümee:
    "Just do it!"
  • Für fachliche Beratung danke ich den Kollegen Dr. Mark Herbrich und Dr. Thomas Pollehn, Naurion Executive Consulting GmbH

     


    Sie planen gerade ein Change-Projekt, bei dem es um derartige Themen geht? Oder haben eine verwandte Fragestellung, zu der Sie fachkundige Unterstützung oder eine kompetente Hintergrund-Beratung suchen? Dann sprechen Sie uns gerne an!


    Link zum Kontaktformular

    oder direkte Mail an w.berner(at)umsetzungsberatung.de

    oder Telefon +49 / 9961 / 910044


  • Wir unterstützen Sie gern!
  •  


    Verwandte Themen:

    Typologie der Veränderungsprozesse
    Ängste
    Widerstand
    Auftragsklärung
    Multiplikatoren
    Betriebsrat
    Mitbestimmung

    Plagiate dieser Website werden automatisiert erfasst und verfolgt.