Change Management in ERP-Projekten

Die Einführung oder der Wechsel eines ERP-Systems ist nicht nur technisch herausfordernd, sondern auch in Sachen Akzeptanz der Mitarbeitenden. Dazu kann ein Change Manager im Projekt entscheidend beitragen, indem er (m/w/d) Veränderungen identifizieren hilft und Führungskräfte im Veränderungsprozess begleitet.

Noch immer gibt es Erzählungen von ERP-Projekten, die rein durch die technische Brille gesehen wurden. Die oftmals gewichtigen Veränderungen, die das Projekt auf Prozesse und Mitarbeitende haben wird, werden in diesen Projekten unterschätzt und die Ressource Führungskraft als aktiver Gestaltungspartner der nötigen Transformation insofern nicht genutzt.

Ganzheitliches Change Management in der ERP-Transformation, gerade auch durch die Führungskräfte, ist jedoch ein kritischer Erfolgsfaktor dafür, die Mitarbeitenden nicht nur mitzunehmen, sondern auch so weit wie möglich einzubinden, um den Go Live des neuen Systems so effizient wie möglich zu gestalten.

Technische Änderungen

Stell dir vor, ein Projektteam soll ein ERP-System einführen. Dazu sollen Prozesse und Funktionalitäten dokumentiert und schließlich mit dem neuen System auch Altsysteme abgelöst werden. Die Systemlandschaft soll dadurch gleich ein wenig schlanker werden.

Zum Team gehören interne wie externe Berater und alles Wissen über die bisherigen Systeme, die Schnittstellen und die Funktionalitäten des neuen ERP-Systems sind im Projekt gegeben.

Im besten Fall (und das geschieht nicht immer) werden in Abstimmung mit der Geschäftsführung und den Bereichen die Geschäftsprozesse auf das neue ERP-System abgestimmt. Das System wird eingerichtet. Schlüsselpersonen aus den Geschäftsbereichen unterstützen das Projekt, in dem sie ihr Fachwissen, fachliche Anforderungen an die neue Technik und ihr Wissen zu den bisherigen Ablaufprozessen einbringen.

Üblicherweise haben die Berater jedoch vor allem die Systemtechnik im Fokus. Sie fragen danach, welche Reports in Zukunft zur Verfügung stehen müssen, welche Daten aus den alten Systemen in das neue migriert werden müssen und wie Stammdaten künftig strukturiert sein sollen. Sie prüfen, ob das neue System die gestellten Anforderungen erfüllt oder ob es zusätzlich individuelle Entwicklungen braucht. Dazu gehört auch die Frage, ob es ein starres Rollen-/Berechtigungskonzept gibt oder ob zusätzlich neue Rollen definiert werden können.

Was geschehen kann, wenn nur die technischen Aspekte berücksichtigt werden

Während des Projektes liegt der Fokus der meisten Beteiligten – wie natürlich – auf dessen IT-Aspekten. Erst kurz vor der eigentlichen Umstellung geraten die Auswirkungen auf die Anwender, auf deren Arbeitsabläufe und ihre bisherigen “menschlichen Schnittstellen”, also ihre Co-Worker in diesen Prozessen, in den Blick. Erst kurz vor Vollendung des Systems werden Umfang und Inhalt der nötigen Schulungen für die Mitarbeitenden definiert.

Das jedoch ist sehr spät oder sogar zu spät, um begleitende Change Maßnahmen wirkungsvoll einzusetzen. Es fehlt die Zeit für Führungskräfte und Mitarbeiter, sich über die Änderungen zu informieren, sich mit ihnen auseinanderzusetzen, sie zu verstehen und sich darauf vorzubereiten bzw. um weitere Unterstützung zur Orientierung zu bitten, geschweige denn, um anzumerken, wo im neuen Prozess kritische Begleiterscheinungen absehbar sind, die nur von der operativen Ebene aus wirklich einsehbar sind und so bisher ggf. nicht gesehen wurden. Diese fehlende Zeit wäre jedoch wichtig dafür gewesen, die Vorteile des Neuen zu kommunizieren, Ängste bezüglich der Erlernbarkeit des Neuen zu nehmen und Widerständen zu begegnen. Schulungen können dann weniger motiviert und erfolgreich verlaufen; das neue System vor allem mit problemorientierten Augen gesehen werden.

Dabei wäre es ganz entscheidend, dass die künftigen Anwender des Systems es nicht nur bedienen können, sondern auch die Veränderungen antizipieren, die es mit sich bringt. Und ich möchte ergänzen: Gerade WEIL erfahrungsgemäß nicht jede Änderung auch einen Vorteil für den Mitarbeitenden bedeuten muss, gerade dann, wenn ein ERP-Altsystem über viele Jahre individuell angepasst an die firmeninternen Bedürfnisse weiterentwickelt worden war. Insofern sind Schulungen extrem wichtig, reichen als alleinige Maßnahme “on the people side of change” allerdings bei Weitem nicht aus.

Wichtig und wirkungsvoll ist es, wenn die Geschäftsführung und die Führungskräfte ein geteiltes Bild von den Zielen der ERP-Einführung haben. Was soll bezweckt und erreicht werden? (Anfangs, wenn vieles noch offen ist, braucht es ggf. den Mut, sich gegebenenfalls im Laufe der Systementwicklung revidieren zu müssen, doch der Vorteil des Vertrauens- und Akzeptanzaufbaus bei den Mitarbeitenden überwiegt dieses Risiko. Wichtig ist nur, mögliche Effekte der Änderungen einzukalkulieren und geeignete Gegenmaßnahmen zu ersinnen, sollten Negativeffekte eintreten).

Für jeden Bereich kann es darüber hinaus eine bereichsspezifische Vision dessen geben, wozu die ERP-Transformation dienen wird. Wenn die Führungskräfte wissen, welche Änderungen sich system- und prozessseitig für ihre Mitarbeitenden ergeben werden, können Hintergründe, Ziele und insbesondere die Vorteile, die sich aus den Neuerungen ergeben, proaktiv kommuniziert und hervorgehoben werden und können die Mitarbeitenden zur kritischen Diskussion des Neuen und zur Mithilfe in der Umsetzung aufgefordert werden.

Bleiben Prozesse und Rollen dieselben?

Eine ERP-Transformation ist also Führungsaufgabe in allen betroffenen Bereichen und in Schnittstellenteams. Zusätzlich kann sich die Verteilung von Aufgaben ändern, wenn der Zuschnitt der Rollen, die zu bestimmten Arbeiten im System berechtigen, das erforderlich macht. Vielleicht entstehen auch neue Rollen. Führungskräfte sollten sich daher die Zeit nehmen und den nötigen Ansprechpartner suchen, sich das Rollenkonzept des neuen Systems erklären zu lassen, um anschließend ihre Mitarbeitenden vorzubereiten.

Gleichzeitig hilft dieser Schritt auch den Projektmitgliedern, mögliche Rollenzuschnitte, die möglich sind und Bestehendes bewahren könnten (ohne die Vision zu gefährden) und die vom Standard des neuen Systems abweichen, ggf. noch frühzeitig zu veranlassen oder, wenn dies nicht möglich ist, auf ggf. weitere nötige Prozessänderungen innerhalb der Organisation zu verweisen, wenn sich dies erst im Gespräch mit der Führungskraft ergeben hat (häufig werden ja nur die wichtigsten Prozesse für den Startkatalog an umzusetzenden Anforderungen erhoben, wodurch dieses Szenario gar nicht unwahrscheinlich ist).

Änderung von Arbeitsschritten, Ansprechpartnern und Routinen

Ein Beispiel: Ein Mitarbeiter der Finanzbuchhaltung hatte bisher ein technisch passend zu seinen Arbeitsabläufen entwickeltes System zur Verfügung. Mit dem neuen System entstehen ihm lästige Work Arounds und neue händische Arbeiten, die unangenehm und ineffizient erscheinen.

Für diesen Menschen findet die tatsächliche Veränderung im Arbeitsablauf statt und in seinen Routinen. Erlerntes und Gewohntes funktionieren nicht mehr und auch manche bisher enge und gute Zusammenarbeit mit KollegInnen kann sich verändern oder ganz entfallen.

Es wundert nicht, wenn dies als Verschlechterung der persönlichen Arbeitsbedingungen gesehen wird. Wird das nicht erkannt und aufgegriffen, kann daraus ein hartnäckiger Widerstand nicht nur gegen das neue System, sondern auch gegen weitere IT-Projekte entstehen. Es bleibt das Gefühl, dass Neuerungen eingeführt werden, ohne dass mit Betroffenen darüber gesprochen oder gar diskutiert wird, was dies für sie bedeutet.

Change Management-Verantwortliche

Es ist daher lohnend, einen dezidierten Change Manager im Projekt einzusetzen. Diese Person hat die Aufgabe, Auswirkungen der ERP-Einführung früh zu erkennen, Prozessbegleiter für die Führungskräfte zu sein und so zu gewährleisten, dass Mitarbeitende rechtzeitig involviert werden, um das Projekt erfolgreich abzuschließen.

Der Change Manager bringt, zusätzlich zur technischen Perspektive, die menschliche Perspektive ein. Er zeigt auf, welche Effekte das neue System auf Mitarbeitende und Teams haben wird. Er sorgt dafür auch durch planvolle, regelmäßige und gesicherte Information an die Betroffenen. Er bietet Kommunikationsformate, sichert die nötige Weiter- bzw. Ausbildung der Endnutzer hinsichtlich von Prozessen und Systemfunktionen und stärkt die Führungskräfte.

Er kennt die Hintergründe und Zwecke des Projektes oder sorgt moderierend dafür, dass ein einheitliches Bild darüber in der Führungsmannschaft entstehen darf. Er zeigt auf, was bisher gut war und auch, was bewahrt werden wird. Er legt Wert darauf, dass dieses wertvolle Bild im Bewusstsein bleibt und nicht im Projektverlauf zwischen den Bereichen auseinanderdiffundiert.

Der oder die Change Managerin unterstützt die Führungskräfte, Veränderungen zu erkennen, mögliche Bedenken und Sorgen zu antizipieren und hilft, geeignete Maßnahmen zu entwickeln, um die Mitarbeitenden in der Umstellung optimal zu begleiten.

Das Change Management ist in einem solchen Projekt eine phasenweise sehr arbeitsintensive (und nicht zuletzt daher) eigene Aufgabe in einer ERP-Transformation. Besetzt man diese Funktion intern, sollte man dies mit einer anerkannten, möglichst gut vernetzten Person tun, die bestenfalls über sehr gute kommunikative Skills und solche zum Projektmanagement verfügt und über Prozesswissen im Unternehmen.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen