Die wichtigsten Change Management Faktoren in den Projektphasen einer ERP-Software Implementierung - Teil 2

 Tweet it: 'Erfolgreiches Change Management erfordert definierte Verantwortungsbereiche und abgebaute Barrieren'

Bei Deltek folgen wir einer industriestandardnahen Projektmanagement-Methode über mehrere Phasen, welche sich den Phasen der etablierten Change-Modelle angleichen lässt.

Somit ergeben sich für jede Projektphase besonders wichtige Faktoren aus der Theorie des Change Managements, auf die besonderer Fokus gelegt werden sollte. In dieser Blog-Serie widmen wir uns den fünf Projektphasen im Einzelnen und erläutern diese Faktoren.

Im zweiten Teil dieser Blog-Serie zum Thema Change Management in ERP-Einführungsprojekten stelle ich weitere wichtige Faktoren und Instrumente aus dem Change Management vor, die in der Designphase Anwendung finden.

Dieser Blogbeitrag baut auf dem ersten Teil der Change Management Serie auf, der vorher gelesen werden sollte.

Wichtige Change Management Faktoren in der Software-Designphase

Ziel der Designphase der ERP-Softwareimplementierung ist die Definition einer IT-Lösung durch Kunde und Software-Dienstleister/-entwickler im Rahmen gemeinsamer Workshops. Die Ergebnisse der Workshops werden zur Designdokumentation (Blueprint) zusammengetragen, welche als Vorlage für das erste Testprodukt (Testsystem) dient. Dieses liegt nahe am Best-Practice Industriestandard und deckt gleichzeitig individuelle Kundenanforderungen ab, da Maconomy durch modulare Konfiguration – und gegebenenfalls kundenspezifische Zusatzentwicklungen – die Möglichkeit einer maßgeschneiderten Anpassung des Systems an Kundenbedürfnisse bietet.

Verantwortungsbereiche definieren und Barrieren abbauen

Angelehnt an Kotters Phasenmodell des organisatorischen Wandels ist die von ihm beschriebene Phase fünf „Enable action by removing barriers” in der Designphase besonders relevant. Die in den Workshops involvierten Key User und Entscheidungsträger müssen in die Verantwortung für die ihnen übertragenen Bereiche genommen und dazu befähigt werden, zeitnah Designentscheidungen zu treffen. Eine häufige Schwierigkeit, besteht darin, dass die benötigten Entscheidungen oft weitgreifender sind, also ursprünglich angenommen: Es müssen also neue Stakeholder in das Projekt involviert werden und Geschäftsprozesse, sowie Verantwortungsbereiche sind von Änderungen betroffen. Wichtig ist daher, dass Entscheidungsmatrizen und Verantwortungsbereiche definiert sind, damit die Entscheidungsprozesse die Projekt-Timeline nicht beeinflussen.

Erwartungen an die neue Lösung abstecken

Ein weiterer wichtiger Aspekt sind die teils hohen Erwartungen an die neue IT-Lösung (Stichwort „eierlegende Wollmilchsau“) des Kernteams. Oftmals wird versucht, alles besser zu machen und jeden Wunsch im Design zu berücksichtigen. Dies würde den Projektrahmen und das –budget sprengen. Daher ist es insbesondere wichtig, dass die Erwartungen an das neue System entsprechend abgesteckt werden, zum Beispiel durch klare Kommunikation des Projektziels „wir bleiben nahe am Industriestandard“ oder „wir sind ok mit 80 % zum Go-Live und setzen ein Folgeprojekt für die anderen 20 % auf“.

Dies kann die Erwartungshaltung der Teammitglieder beeinflussen und das Design der Lösung in den richtigen Rahmen im Unternehmenssinne lenken.

Des Weiteren spielen auch während der Lösungsdefinition die in der Initiierungsphase eingeleiteten Aspekte – wie Kommunikation, Konfliktmanagement und die Weiterentwicklung der teambasierten Projektkultur – eine wichtige Rolle und sollten weiter vorangetrieben werden.

Lesen Sie mehr über Phase 3 und besuchen Sie diesen Blog wieder, um alles über Phase 4 und 5 zu erfahren.