Diagnose Ihres Veränderungsvorhabens

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

Entgegen vielen 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, kaum etwas 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.

Dass die Einführung eines neuen IT-Systems, wie immer wieder kolportiert wird, am Widerstand der Belegschaft oder gar an einem "Boykott" gescheitert sei, 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 Tauglichkeit des Systems. Zuweilen konnte man sogar den Eindruck haben, dass die Projektverantwortlichen die Angst der Linienmanager und des Top Managements in subtiler Weise geschürt und sie so veranlasst hatten, aus Angst vor einer operativen Katastrophe schließlich die "Notbremse" zu ziehen. Denn für interne wie externe IT-Verantwortliche ist natürlich das kleinere Übel, an angeblichen Widerständen gescheitert zu sein, als den Offenbarungseid leisten zu müssen, dass sie nicht dazu in der Lage waren, ein funktionsfähiges System auf die Beine zu stellen.

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 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.) 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, der 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 Unternehmens erreicht und es an Komplexität mühelos in den Schatten stellt.

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 mit Kommunikation nicht zu heilen. Denn es ist keineswegs immer so, dass Vorbehalte der Linie gegen ein neues System darin begründet sind, 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 ..."

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 wirklich 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.

Auftragsklärung unter einem schlechten Stern

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. Sie fühlen 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.

Denn in der Tat liegt hier ein Konflikt, der keineswegs nur gruppendynamischer Natur ist. Es ist ja tatsächlich so, dass die Projektverantwortlichen ein Interesse daran haben, 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 Erreichung ihrer Projektziele 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.

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. 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.

Diese Verhandlungen stehen insofern unter einem schlechten Stern, als beide Seiten, wenn sie sich subjektiv vernünftig verhalten, mit großer Wahrscheinlichkeit zu einem Ergebnis kommen, 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).

Am Ende kommt so leicht ein Lastenheft heraus, das zwar an einigen 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.

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.

Dafür 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. Das heißt aber auch, dass ein Change Manager 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 "Hybrid" zwischen IT und dem jeweiligen Fachgebiet, die zusätzlich Moderationskenntnisse und ein ausgeprägtes Strukturierungsvermögen besitzt.

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.

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. Denn für jedes größere IT-Projekt kann risikolos vorhergesagt werden, dass spätestens dann, wenn es in Zeitnot kommt, 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 sein mag, 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.

Diese konsequente Beschränkung des Projektumfangs ist natürlich 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 noch mit in den Projektumfang aufzunehmen. Und es ist sowohl für den Projektleiter als auch für den Moderator und die Eskalationsinstanzen naheliegend, um des lieben Friedens willen den drängendsten Forderungen der Fachbereiche nachzugeben. Dennoch sind der Moderator und die Projektverantwortlichen gut beraten, den Interessengruppen klarzumachen, dass sie nicht wirklich die Wahl zwischen einem guten, aber aufs Allernötigste beschränkten System und einem ebenfalls guten, aber deutlich umfangreicheren System haben, sondern dass ihre zweite Alternative in Wahrheit völlig anders lautet: 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.

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. Und wenn die Linie sich mit der Auftragsdefinition wohl fühlt, profitiert davon letztlich auch das Projekt: Es macht 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 die wirklichen Anforderungen abbilden, desto wahrscheinlicher ist, dass das System hinterher den Anforderungen entspricht – und das erleichtert die Einführung ungemein.

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 nur so der oben beschriebenen Tendenz zur Loslösung des Lastenhefts von den Projektzielen entgegenwirken kann. Auch wenn diese zweite Variante ganz 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 hat, dann hat er sein Vertrauen verspielt.

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 schon. 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, wird es Bescheid sagen.

Seien Sie daher auf einen ähnlichen Verlauf des Interesses gefasst wie bei der Euro-Einführung: Eine erstaunlich lange Zeitspanne, wo sich keiner für das Thema interessiert, schlägt irgendwann kurz vor der Einführung plötzlich um in eine Stimmung, wo sich alle furchtbar schlecht informiert fühlen. Daran 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. Statt daher mit immer neuen Aktionen gegen das 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.

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! Die Erfahrung zeigt, dass man selbst gutwillige Zeitgenossen zur Raserei bringen kann, wenn man nur alle negativen 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.

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. Das ist aus zwei Gründen gar nicht so einfach. Der eine ist, dass manche Mitarbeiter sehr hartnäckig und suggestiv nach ihren Lieblings-Features fragen, sodass 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 empört dagegen verwahren, "das Projekt öffentlich schlecht zu reden". Aber es hilft alles 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.

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.

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 fraglich, ob es etwas nützt. 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 es endlich so weit ist. Dennoch geht es auch mit geringerem Aufwand. 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 es nicht an der Kommunikation, aber es ist dann auch mit noch so viel Kommunikation nicht zu retten. Mangelnde Akzeptanz eines IT-Systems ist in aller Regel nicht die Ursache, sondern die Folge des Scheiterns.

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 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.

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 Geschick im Umgang mit Computern besitzen, zweitens kommunikativ sind und drittens im eigenen Bereich ein gewisses Ansehen genießen. 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. Eine sorgfältige 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 sie von ihren Kollegen als "Change Champions" oder "System Wizards" aufgezogen werden, fördert das in aller Regel nicht ihre Identifikation mit der Aufgabe.)

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, dies 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 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 ihrem Chef und ihren 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 die wenigsten; 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.

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 sind als im alten und manche Abläufe anders strukturiert sind. Die Umgewöhnung erträgt sich leichter, wenn man gemeinsam auf "die Idioten, die dies 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. 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!)

Schnittstelle zu Betriebsrat und Datenschutzbeauftragtem

Der Betriebsrat hat bei der Einführung neuen 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 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.

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.

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. So wie die förmliche Unterrichtung des Betriebsrats nicht durch beiläufige Informationen ersetzbar ist und nicht einmal durch die Mitarbeit von Betriebsratsmitgliedern in dem Projekt, so 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. Das Change Management bietet sich dafür an, zumal dort 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.

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, 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 Besucher. 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.

Kommunikation innerhalb des Projekts

Häufig wird übersehen, dass schon mittelgroße 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 durchaus nicht alle freiwillig in dem Projekt sind, sondern viele mit mehr oder weniger belastbaren Versprechungen dorthin abkommandiert wurden.

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; er kann durch eine geeignete Vertragsgestaltung – etwa durch Vertragsstrafen für externe Partner bei Terminverzögerungen – noch deutlich "lebhafter" gestaltet werden. 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 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.

In dieser Gemengelage entsteht eines sicherlich nicht spontan, nämlich ein Zusammengehörigkeitsgefühl 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. 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 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 Rücksicht auf übergeordnete Zusammenhänge tagein, tagaus einfach die Abdeckbleche zu montieren oder die Lohn- und Gehaltsabrechnung zu machen.

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 große 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.

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 E-Mail-Newsletter für 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.

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.

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.

Für fachliche Beratung danke ich den Kollegen Dr. Mark Herbrich und Dr. Thomas Pollehn, Naurion Executive Consulting GmbH

© 2005 Winfried Berner - vollständige oder auszugsweise Wiedergabe, gleich in welcher Form, honorarpflichtig und nur mit vorheriger schriftlicher Genehmigung / Zitate im üblichen Umfang mit Quellenangabe gemäß wiss. Zitationsregeln zulässig. Näheres siehe Nutzungsbedingungen.

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