IT-Projekte bringen Veränderungen im Unternehmen mit sich. Ein bedarfsgerechtes Change Management kann für den Erfolg des Projekts entscheidend sein.
IT-Projekte bringen für das Unternehmen – oder vielmehr: seine Mitarbeiter* – oft erhebliche Veränderungen mit sich. Unabhängig davon, ob ein neues Betriebssystem eingeführt werden soll oder die Migration in die Cloud ansteht: Eingeschliffene Prozesse werden aufgebrochen und Mitarbeiter müssen ihre Arbeitsweise den neuen Gegebenheiten anpassen. IT-Projekte haben daher, wie jede Veränderung, ein nicht zu vernachlässigendes Konfliktpotential.
Um die damit einhergehenden Risiken einzuhegen, ist ein effektives Change Management das Mittel der Wahl. Mit dem Begriff „Change Management″ wird im allgemeinen der Umgang des Unternehmens mit geplanten oder bereits stattfindenden Veränderungen im Sinne einer bewussten und gezielten Gestaltung des Veränderungsprozesses beschrieben. Dies ist zunächst keine originär juristische, sondern primär eine strategische Thematik. Nichtsdestotrotz sollten im Rahmen eines IT-Projektvertrags die notwendigen vertraglichen Voraussetzungen dafür geschaffen werden, ein effektives Change Management umsetzen zu können.
Überzeugen statt überrumpeln – Veränderungen sinnvoll begleiten
In der Literatur wird der Veränderungsprozess oft in mehrphasigen Modellen beschrieben. Diesen Modellen ist gemein, dass bei den Betroffenen zunächst die Einsicht geschaffen werden soll, dass eine Veränderung des Status Quo nötig ist. Daraus soll Akzeptanz für die konkreten Veränderungen entstehen. Die veränderten Rahmenbedingungen sollen sich schließlich perspektivisch als neuer Status Quo etablieren. Als ein entscheidender Faktor für das Gelingen eines Projektes, mit dem Veränderungen im Unternehmen einhergehen, wird die Akzeptanz der Veränderung bei den Betroffenen identifiziert.
Unternehmen unterschätzen oft, wie groß der Kreis der einzubindenden Betroffenen in IT-Projekten ist. So wird auch das beste IT-System dem Unternehmen keinen Mehrwert bieten können, wenn die mit seiner Bedienung betrauten Mitarbeiter dieses nicht sinnvoll nutzen können oder wollen. Die Gründe hierfür lassen sich im Wesentlichen in zwei Fallgruppen fassen: Fehlender Wille zur Veränderung und unzureichende Fähigkeit zum Umgang mit der Veränderung. Gleich aus welchem Grund die Beschäftigten die Veränderung nicht mittragen, stellt dies das betroffene Unternehmen vor erhebliche Herausforderungen.
Mitarbeiter mitnehmen – Den Wunsch zur Veränderung wecken
Entscheidend ist zunächst, dass die Mitarbeiter die Notwendigkeit der Veränderung erkennen. Im Interesse eines reibungslosen Projektverlaufs sollten daher die Mitarbeiter möglichst frühzeitig eingebunden werden.
„Frühzeitig″ meint in diesem Zusammenhang bereits die Planungsphase des Projekts. Wenn die Mitarbeiter das Gefühl haben, dass sie die Veränderung mitgestalten können und ihr Input wertgeschätzt wird sowie auf eventuelle Bedenken eingegangen wird, wird sich das auf die Akzeptanz der Veränderung positiv auswirken. Vor diesem Hintergrund kann es sich beispielsweise lohnen, bei der Belegschaft aktiv konkrete Verbesserungswünsche in Bezug auf das Bestandssystem abzufragen, um bereits ein Bewusstsein dafür zu schaffen, welche Unzulänglichkeiten im Bestandssystem zu beobachten sind. So lässt sich begreiflich machen, dass eine Veränderung, etwa in Form eines neuen Systems, erforderlich ist.
Aus zwingenden rechtlichen Gründen wird den Mitarbeitern nur in begrenztem Umfang ein Mitspracherecht hinsichtlich der Umsetzung des Projekts eingeräumt (etwa, soweit ein Projekt die Beteiligung des Betriebsrats erfordert). Allerdings wirkt bereits eine Information der Mitarbeiter und eine Feedbackmöglichkeit, dem Gefühl entgegen, dass ohne Rücksicht auf die Belange der Belegschaft über deren Köpfe hinweg entschieden wird. Eine Berücksichtigung sinnvollen Inputs aus der Belegschaft macht die Mitarbeiter zu an dem Veränderungsprozess aktiv Beteiligten anstelle von passiv Betroffenen.
Neben der reinen Information über die anstehenden Neuerungen kann auch eine iterative Umsetzung des Projekts sinnvoll sein. Wird etwa ein neues Betriebssystem für die Mitarbeiter ausgerollt, kann es sich anbieten, diese nicht dem „Big-Bang-Ansatz″ folgend zeitgleich auf den PCs aller Anwender zu installieren, sondern nach und nach. Dabei bietet es sich an, zuerst eine Nutzergruppe auszuwählen, bei denen davon ausgegangen werden kann, dass die Umstellung die Anwender nicht vor besondere Probleme stellen wird. Zum Beispiel, weil die Nutzer sich in der Vergangenheit als besonders technikaffin erwiesen haben. Dies gibt den anderen Anwendern Gelegenheit, zu beobachten, wie das System sich in der Praxis bewährt. Dadurch können Mitarbeiter Berührungsängste mit der neuen Technik abbauen, ohne selbst bereits den Zugriff auf das bisher gewohnte System zu verlieren. Ein derartiger iterativer Rollout muss im Projektvertrag berücksichtigt werden, etwa durch einen flexiblen Ramp-Up Plan samt Unterstützung für den dadurch verlängerten Migrationszeitraum.
Interne Potentiale nutzen
Die frühzeitige Einbindung ist aber nicht nur mittelbar im Rahmen gesteigerter Akzeptanz im Interesse des Unternehmens, sondern kann auch ganz unmittelbar für das Projekt wertvolle Erkenntnisse liefern. Erfahrungsschatz und Knowhow der Mitarbeiter sind Ressourcen, die genutzt werden wollen. Die Fachabteilungen wissen in der Regel sehr gut, wo im aktuellen System ein Flaschenhals sitzt, der ein effizientes Arbeiten erschwert und haben oft konkrete Vorstellungen davon, wie sich Arbeitsabläufe optimieren ließen. Dieser Input sollte bereits bei der Spezifizierung und der Auswahl eines neuen Systems berücksichtigt werden.
Ein weiterer Punkt führt im Rahmen von IT-Projekten oft zu Problemen und kann im Rahmen einer frühzeitigen Einbindung der Belegschaft geklärt werden: die Verprobung des angenommenen Ist-Zustands, auf dessen Grundlage das Projekt geplant wird. Allzu oft etablieren sich neben dem Bestandssystem über die Zeit Parallelstrukturen, die eine Einschätzung des Projekts beeinflussen können, und die in der Planung oft übersehen werden. Bietet beispielsweise das Bestandssystem nur die Möglichkeit, Dateien bis zu einer bestimmten Dateigröße direkt im System zu speichern, kann es vorkommen, dass sich die Mitarbeiter für größere Dateien bisher dadurch beholfen haben, dass sie diese etwa auf einem Sharepoint hochgeladen haben und dadurch diese Beschränkung umgangen haben. Wird diese Vorgehensweise bei der Planung des neuen Systems, das keine Beschränkung der Dateigrößen mehr erforderlich macht, übersehen, wird der spätere Bedarf an Speicherplatz grob unterschätzt werden. Welche Besonderheiten im jeweiligen Unternehmen tatsächlich auftreten, ist letztlich eine Frage, die nur im konkreten Einzelfall zu beantworten ist und durch die Einbindung von Mitarbeitern oft erleichtert wird.
Natürlich nimmt die frühzeitige Einbindung von Mitarbeitern Zeit in Anspruch. Unternehmen sind aber in aller Regel gut beraten, diese Zeit im Projekt einzuplanen. Die hierfür aufgewendete Zeit kann dabei helfen, umständliche Anpassungen des neuen Systems im Nachhinein und Anlaufschwierigkeiten in der Produktivnutzung zu vermeiden.
Gewusst wie: Kompetenzen aufbauen
Auch wenn das Projekt die volle Unterstützung der Belegschaft hat – ohne den Aufbau der notwendigen Kompetenzen, mit den veränderten Rahmenbedingungen zu arbeiten, sind Schwierigkeiten nach der Umsetzung des Projekts kaum zu vermeiden. Hierfür wird das Unternehmen in aller Regel auf den Projektpartner angewiesen sein, sodass dessen Verpflichtungen unter diesem Aspekt vertraglich fixiert werden sollten. Wie der Aufbau von Knowhow im Unternehmen vonstattengeht, ist oft eine Frage der Unternehmenskultur. Wie so oft führen hier verschiedene Wege zum Ziel.
IT-Systeme werden in aller Regel mit einem umfassenden Handbuch ausgeliefert, das die Funktionsweise des Systems detailliert beschreibt. Vor allem, wenn nicht nur die Bedienung des neuen Systems gelernt werden soll, sondern auch darüberhinausgehend etwa im Rahmen eines internen 1st-Level Supports grundlegende Fehlerdiagnostik und -behebung, bilden Handbücher eine gute Grundlage. Für reine Endanwender wäre eine Einarbeitung allein über ein solches Handbuch aber in der Regel zu aufwändig und überfordernd. Aus diesem Grund wird heute bevorzugt mit speziellen Schulungen gearbeitet, die auf die jeweiligen Anforderungen der spezifischen Anwendergruppe eingehen. Viele Anbieter von Standardsoftware bieten diese oft direkt von sich aus an, bei Individualentwicklungen sollte aber besonderes Augenmerk darauf gelegt werden, dass der Anbieter passende Schulungskonzepte für die neu erstellte Software anbietet. Diese Option sollte insbesondere auch vertraglich festgehalten werden. Neben rein durch den Anbieter durchgeführten Schulungen kommen insbesondere auch „Train the Trainer″-Konzepte in Betracht, bei denen ausgewählte Mitarbeiter des Unternehmens durch Trainings des Anbieters selbst in die Lage versetzt werden, die internen Schulungen durchzuführen.
Auch durch eine iterative Einführung eines neuen Systems (wie oben dargestellt) kann das notwendige Knowhow auf organische Weise ins Unternehmen „hineinwachsen″. Nachdem die Anwender in der Pilotgruppe erste Erfahrungen haben sammeln können, können diese intern als Multiplikatoren dienen und ihr Wissen direkt an die Kollegen der nachfolgenden Gruppen weitergeben.
Es ist darüber hinaus sicherzustellen, dass in der Einführungsphase durch den Anbieter und ggf. interne Supportteams ausreichend Support zur Verfügung gestellt werden kann. So lange die Anwender mit dem neuen System noch nicht vertraut sind, ist mit deutlich erhöhtem Supportbedarf zu rechnen. Dies kann beispielsweise erforderlich machen, namentlich benannte Ansprechpartner oder eine fixe Anzahl an exklusiv für das Projekt abgestellte Support-Mitarbeiter vertraglich zu vereinbaren. Gerade bei kritischen Projekten mit Hardwarebezug kann es in Ausnahmefällen auch sinnvoll sein, für einen bestimmten Zeitraum die Verfügbarkeit eines Support-Mitarbeiters „on site“ zu vereinbaren, also physisch vor Ort im Unternehmen.
Widerständen begegnen
Eine bedarfsgerechtes Change Management ist ein äußerst hilfreiches Mittel – aber kein Allheilmittel. Trotz aller Bemühungen ist damit zu rechnen, dass ein Teil der Belegschaft die Veränderungen nicht mittragen wollen wird. Sei es aus Angst vor Veränderung per se oder vor negativen Auswirkungen auf die eigene Position im Unternehmen. Erfahrungswerte zeigen, dass von etwa jedem zehnten Mitarbeiter grundsätzlicher Widerstand gegen ihn betreffende Veränderungen im Unternehmen zu erwarten ist. Auch wenn alle Mitarbeiter umfassend informiert und ausführlich geschult sind, sollte daher damit gerechnet werden, dass einzelne Mitarbeiter die Veränderung nicht oder nur widerwillig mittragen werden.
Grundsätzlich kann das Unternehmen im Rahmen des arbeitsvertraglichen Direktionsrechts ausdrücklich die Nutzung des neuen Systems anordnen. Dieser Anweisung haben sich die Beschäftigten regelmäßig zu fügen. Besteht der Widerstand fort, sollte geklärt werden, ob der Widerstand sachlich berechtigt ist (etwa, weil es technische Probleme gibt, die ein effizientes Arbeiten mit dem neuen System unmöglich machen), oder ob er einer grundsätzlichen Blockadehaltung entspringt. Können sachliche Gründe ausgeschlossen werden, können gegebenenfalls weitere arbeitsrechtliche Maßnahmen angezeigt sein.
Ein bedarfsgerechtes Change Management kann dabei helfen, die zu erwartenden Widerstände gegen ein Projekt und die damit einhergehenden Ineffizienzen und Kosten so klein wie möglich zu halten. Change Management sollte daher von Anfang an mitgedacht und im Projektvertrag entsprechend berücksichtigt werden, um dem erheblichen Impact auf den Verlauf und Erfolg des Projekts Rechnung zu tragen.
Wir informieren Sie in unserer Blog-Serie zu IT-Projekten fortlaufend mit aktuellen Beiträgen zu diesem Thema. Sie können diese Blog-Serie über den RSS-Feed abonnieren und werden von uns über neue Beiträge informiert. Den Auftakt zur Blogserie hat der Einführungsbeitrag „IT-Projekte – mit Vertragsgestaltung zum Erfolg″ gemacht, gefolgt von dem Beitrag „Vertragstyp bei IT-Projekten – eine bewusste Wahl“ und „Die Bedeutung von Mitwirkungsleistungen in IT-Projektverträgen“ sowie dem Beitrag zur „Abhängigkeiten in IT-Projekten„. Zuletzt erschient der Beitrag „IT-Projekte mit offenem Scope„.
