Ein neues ERP-System kann technisch sauber eingerichtet und Daten erfolgreich migriert worden sein. Trotzdem kann die Einführung im Alltag ins Stocken geraten.
Mitarbeiter arbeiten weiterhin mit alten Excel-Listen. Neue Abläufe werden unterschiedlich interpretiert. Für Rückfragen ist nicht klar, wer zuständig ist. Schulungen wurden zwar durchgeführt, aber viele Fragen entstehen erst Wochen später im tatsächlichen Arbeitsprozess.
Das Problem liegt dann nicht zwangsläufig im ERP-System.
Mit einer ERP-Einführung verändert ein Unternehmen nicht nur Software. Es verändert häufig auch Arbeitsabläufe, Zuständigkeiten, Informationswege und die Zusammenarbeit zwischen Abteilungen. Diese organisatorische Veränderung muss genauso geplant werden wie Migration, Schnittstellen und Systemkonfiguration.
Change Management bei einer ERP-Einführung bedeutet deshalb nicht, Mitarbeiter lediglich über eine neue Software zu informieren. Es bedeutet, sie auf eine veränderte Arbeitsweise vorzubereiten.
Eine ERP-Einführung verändert nicht nur Technik, sondern auch Prozesse, Rollen und Verantwortlichkeiten.
Mitarbeiter sollten nicht erst kurz vor dem Go-live erfahren, dass sich ihre tägliche Arbeit verändert. Je früher Auswirkungen und Gründe transparent werden, desto besser können Fragen und Risiken sichtbar werden.
Beteiligung bedeutet nicht, dass jeder Mitarbeiter über das ERP-System entscheidet. Die Mitarbeiter, die später täglich mit den Prozessen arbeiten, sollten jedoch ihre praktischen Anforderungen und Erfahrungen einbringen können.
Key User bilden die Verbindung zwischen ERP-Projekt und Fachbereichen. Dafür brauchen sie klare Aufgaben, ausreichend Zeit und frühzeitige Einbindung.
Schulung sollte nicht als einmaliger Termin vor dem Go-live betrachtet werden. Unterschiedliche Rollen benötigen unterschiedliche Lernformate – vor, während und nach der Einführung.
Auch nach dem Go-live müssen Ansprechpartner, Supportwege und Prozessverantwortlichkeiten eindeutig definiert sein.
Bei einem ERP-Projekt stehen zunächst häufig technische Fragen im Mittelpunkt: Welche Funktionen benötigen wir? Welche Daten müssen migriert werden? Welche Systeme müssen angebunden werden? Welche Workflows können automatisiert werden?
Diese Fragen sind notwendig. Sie bilden aber nur einen Teil des Projekts ab.
Für die Mitarbeiter verändert sich die ERP-Einführung auf einer anderen Ebene.
Ein Arbeitsschritt, der bisher telefonisch abgestimmt wurde, muss künftig im System dokumentiert werden. Eine Abteilung kann bestimmte Informationen nicht mehr selbst verändern. Freigaben laufen anders. Daten werden früher benötigt. Ein Prozess, der bisher flexibel gehandhabt wurde, bekommt klare Regeln.
Damit verändert sich nicht nur das Werkzeug, sondern die Art, wie Arbeit organisiert wird.
Genau deshalb reicht es nicht, ein ERP technisch korrekt bereitzustellen und anschließend eine Rundmail mit dem Termin für die Umstellung zu versenden.
Wenn Mitarbeiter einer neuen Software oder einem neuen Prozess skeptisch gegenüberstehen, wird schnell von fehlender Veränderungsbereitschaft gesprochen.
Das greift häufig zu kurz und wird den Mitarbeitern nicht gerecht.
Aus Sicht der Projektverantwortlichen gibt es oft gute Gründe für eine Veränderung. Das bisherige System ist zu teuer, wichtige Funktionen fehlen, Prozesse lassen sich nicht automatisieren oder die bestehende Systemlandschaft kann mit dem Wachstum des Unternehmens nicht mehr Schritt halten.
Die Mitarbeiter kennen diese Hintergründe jedoch nicht zwangsläufig.
Sie erleben zunächst etwas anderes:
Ein bekanntes Werkzeug verschwindet. Arbeitsabläufe verändern sich. Gewohnte Funktionen befinden sich plötzlich an anderer Stelle. Zusätzlich sollen Schulungen absolviert werden, während das Tagesgeschäft weiterläuft.
Wenn die Kommunikation erst an diesem Punkt beginnt, ist Widerstand wenig überraschend.
Deshalb sollte eine der ersten Fragen im Change Management lauten:
Verstehen die betroffenen Mitarbeiter, warum sich überhaupt etwas verändert?
Das bedeutet nicht, jede strategische oder wirtschaftliche Entscheidung vollständig offenzulegen. Es bedeutet aber, die Veränderung nachvollziehbar zu machen.
Warum reicht der bestehende Prozess nicht mehr aus? Welche Probleme sollen gelöst werden? Welche Vorteile sollen im Arbeitsalltag entstehen? Und welche Veränderungen werden zunächst möglicherweise zusätzlichen Aufwand verursachen?
Je konkreter diese Fragen beantwortet werden, desto weniger wirkt die Einführung wie eine Entscheidung, die lediglich „von oben“ angeordnet wurde.
Frühe Beteiligung wird manchmal mit vollständiger Mitbestimmung verwechselt.
Das ist bei einem ERP-Projekt weder notwendig noch sinnvoll.
Strategische Anforderungen, Kosten, Schnittstellen, Sicherheit, Skalierbarkeit oder technische Abhängigkeiten können die Auswahl eines Systems stark begrenzen. Diese Entscheidungen liegen letztlich bei den dafür verantwortlichen Personen.
Trotzdem verfügen die späteren Nutzer über Wissen, das in einer reinen Management- oder IT-Perspektive leicht verloren geht.
Sie wissen, welche Arbeitsschritte täglich stattfinden, wo Sonderfälle auftreten, welche Informationen fehlen und welche Funktionen tatsächlich verwendet werden.
Dieses Wissen sollte möglichst früh in das Projekt einfließen.
Wenn beispielsweise mehrere grundsätzlich geeignete Systeme zur Auswahl stehen, können die betroffenen Mitarbeiter die Lösungen anhand praktischer Kriterien bewerten.
| Kriterium | System A | System B | System C |
|---|---|---|---|
| Abbildung des täglichen Prozesses | |||
| Bedienbarkeit | |||
| Aufwand für wiederkehrende Aufgaben | |||
| Umgang mit typischen Sonderfällen | |||
| Verständlichkeit der Oberfläche | |||
| Schulungsbedarf | |||
| Auffällige Vor- oder Nachteile aus Anwendersicht |
Eine solche Bewertung ersetzt keine technische oder wirtschaftliche Entscheidung. Sie ergänzt sie um die Perspektive der Menschen, die später täglich mit dem System arbeiten.
Das kann auch verhindern, dass ein fachlich geeignetes System ausgewählt wird, dessen Bedienung unnötige Widerstände erzeugt, obwohl eine vergleichbare Alternative deutlich besser angenommen würde.
Vor allem aber verändert frühe Beteiligung die Wahrnehmung des Projekts: Das neue System erscheint nicht erst wenige Wochen vor dem Go-live, sondern wird bereits während seiner Entstehung sichtbar.
Mitarbeiterbeteiligung muss nicht zwangsläufig bedeuten, dass große Workshops organisiert oder Entscheidungen wochenlang diskutiert werden.
Das passende Format hängt vom Prozess und von der betroffenen Mitarbeitergruppe ab.
Für einen Büroprozess kann eine kurze digitale Befragung sinnvoll sein. In Lager oder Produktion kann ein Gespräch direkt am Arbeitsplatz wesentlich hilfreicher sein. Bei einem komplexen Prozess kann dagegen ein Workshop notwendig werden, um mehrere Rollen gemeinsam abzubilden.
Entscheidend ist weniger das Format als die Frage, ob die betroffenen Mitarbeiter eine realistische Möglichkeit bekommen, ihr Prozesswissen einzubringen.
Das kann beispielsweise über Interviews, kurze Umfragen, Testgruppen, Prozessbeobachtungen oder Feedbackrunden geschehen.
Eine Rückmeldung allein reicht allerdings nicht.
Wenn Mitarbeiter Hinweise geben, sollte anschließend sichtbar sein, was damit passiert ist. Wurde eine Anforderung übernommen? War sie technisch nicht umsetzbar? Wurde eine andere Lösung gewählt?
Sonst entsteht schnell der Eindruck einer Beteiligung, die faktisch keine Wirkung hat.
ERP-Einführung geplant?
Eine ERP-Schulung kann erklären, wo ein Button zu finden ist. Sie beantwortet aber nicht automatisch, wie ein Prozess künftig im Unternehmen funktioniert.
Das wird besonders sichtbar, wenn sich Zuständigkeiten verändern.
Wer legt künftig einen Artikel an? Wer darf Stammdaten ändern? Wer korrigiert einen Auftrag? Wer prüft einen Fehler? Wer gibt eine Bestellung frei? Was passiert, wenn eine Information fehlt?
Solche Fragen müssen vor dem Go-live geklärt sein.
| Prozessfrage | Vor dem Go-live zu klären |
|---|---|
| Wer startet den Prozess? | Rolle und Auslöser |
| Wer bearbeitet welchen Schritt? | Zuständigkeiten |
| Welche Informationen werden benötigt? | Pflichtinformationen und Datenquelle |
| Wer darf Änderungen vornehmen? | Rechte und Verantwortung |
| Was passiert bei Fehlern? | Eskalations- und Korrekturprozess |
| Wer entscheidet bei Sonderfällen? | Fachlich verantwortlicher Ansprechpartner |
| Wie wird der Prozess dokumentiert? | ERP, Ticketsystem, Formular oder anderer definierter Kanal |
Gerade bei Veränderungen zwischen Abteilungen entstehen sonst organisatorische Lücken.
Ein Prozess wurde zwar formal übergeben, aber Mitarbeiter wissen im Alltag nicht, an wen sie eine Frage richten sollen. Eine E-Mail-Adresse existiert, aber nicht jeder kennt sie. Für bestimmte Anliegen gibt es ein Formular, für andere ein Ticket und für wieder andere einen direkten Ansprechpartner.
Solche Übergabelücken wirken zunächst klein, verursachen aber im Tagesgeschäft schnell Unsicherheit und zusätzliche Abstimmung.
Wenn Sie neben Mitarbeiterbeteiligung, Schulung und Rollen auch die weiteren Voraussetzungen Ihres ERP-Projekts prüfen möchten, finden Sie in unserem ERP-Projektcheck Fragen zu Prozessen, Daten, Schnittstellen, Systemlandschaft, Migration, Go-live und Betrieb.
Eine wichtige Rolle bei ERP-Einführungen übernehmen Key User.
Sie kennen die Prozesse ihres Fachbereichs und arbeiten gleichzeitig intensiver mit dem neuen ERP-System als die übrigen Mitarbeiter. Dadurch können sie zwischen Projektteam, Fachbereich und späteren Nutzern vermitteln.
Key User sind nicht nur Tester, sondern unter anderem als Fachexperten, Multiplikatoren und Ansprechpartner während und nach der Einführung.
Diese Rolle sollte allerdings bewusst definiert werden.
Key User können beispielsweise Anforderungen aus ihrem Fachbereich aufnehmen, Prozesse testen, Schulungsinhalte auf Praxistauglichkeit prüfen, Fragen bündeln und nach dem Go-live erste Ansprechpartner sein.
Das funktioniert nur, wenn sie dafür ausreichend Zeit bekommen.
Ein Mitarbeiter wird nicht automatisch zum funktionierenden Key User, nur weil die Rolle zusätzlich zu seinen bisherigen Aufgaben vergeben wird.
Je nach Umfang des Projekts sollte deshalb geklärt werden:
- welche Fachbereiche einen Key User benötigen,
- welche Aufgaben die Rolle übernimmt,
- wie viel Zeit dafür eingeplant wird,
- welche Entscheidungen der Key User treffen darf,
- wann er geschult wird,
- und welche Verantwortung nach dem Go-live bestehen bleibt.
Ein häufiger Fehler bei Softwareeinführungen ist, Schulung als einzelnen Termin zu betrachten.
„Das neue System startet nächsten Monat. Bitte absolvieren Sie bis dahin diese Schulung.“
Formal wurde damit geschult. Praktisch entsteht Wissen aber selten so.
Mitarbeiter benötigen vor allem die Informationen, die zu ihrer tatsächlichen Rolle passen. Ein Mitarbeiter im Lager benötigt andere Inhalte als ein Mitarbeiter im Einkauf oder in der Buchhaltung.
Auch das Format sollte zur Aufgabe passen.
Für einen selten ausgeführten komplexen Prozess kann eine ausführliche Anleitung sinnvoll sein. Für einen täglichen Arbeitsschritt direkt an einer Packstation ist möglicherweise eine kurze visuelle Anleitung hilfreicher. Bei umfangreichen Prozessänderungen kann dagegen ein Workshop notwendig sein.
Entscheidend ist nicht, möglichst viele Schulungsstunden anzusetzen, sondern die richtige Unterstützung für den tatsächlichen Arbeitsprozess bereitzustellen.
Nach dem Go-live ist es gut, bewusst zu prüfen:
Welche Fragen treten häufig auf? Wo gibt es Workarounds? Welche Prozesse werden anders genutzt als geplant? Welche Schulungsinhalte fehlen? Welche Anforderungen wurden erst im realen Betrieb sichtbar?
Ein Go-live ist damit nicht das Ende der ERP-Einführung, sondern der Übergang in die Stabilisierungsphase.
Nicht jeder Mitarbeiter benötigt dieselbe Form der Unterstützung.
Ein häufiger Fehler besteht darin, ein einziges Schulungskonzept für das gesamte Unternehmen zu entwickeln.
Sinnvoller ist eine rollen- und prozessbezogene Betrachtung. Damit wird Schulung nicht als einmaliges Projektpaket verstanden, sondern als Teil des späteren Betriebs.
| Situation | Mögliche Unterstützung |
|---|---|
| Neuer, einfacher Arbeitsschritt | Kurzanleitung oder Checkliste |
| Bedienung direkt am Arbeitsplatz | Visuelle Anleitung am Arbeitsplatz |
| Komplexer neuer Prozess | Workshop oder praktische Schulung |
| Viele wiederkehrende Fragen | FAQ oder Wissensdatenbank |
| Fachlich komplexe Sonderfälle | Key User oder definierter Ansprechpartner |
| Erste Wochen nach Go-live | Sprechstunde, Floor Support oder Supportkanal |
| Neue Mitarbeiter nach Einführung | Standardisierter Onboarding-Prozess |
Eine der schwierigsten Situationen entsteht, wenn Mitarbeiter erstmals von einer Veränderung erfahren, sobald die Entscheidung bereits vollständig getroffen wurde.
Dann lautet die Kommunikation sinngemäß: „Das bisherige System wird abgeschaltet. Ab dem kommenden Monat arbeiten wir mit einem neuen Tool. Bitte absolvieren Sie bis nächste Woche die Schulung.“
Aus Sicht des Projektteams ist die Entscheidung zu diesem Zeitpunkt vielleicht bereits Monate alt. Anforderungen wurden verglichen, Kosten geprüft und verschiedene Lösungen bewertet.
Für die Mitarbeiter beginnt die Veränderung jedoch erst mit dieser Nachricht.
Genau hier entsteht eine Kommunikationslücke.
Sinnvoller ist eine schrittweise Kommunikation.
Zunächst kann angekündigt werden, dass ein System oder Prozess überprüft wird und warum. Später können die nächsten Schritte, mögliche Lösungen und Auswirkungen erläutert werden. Wenn eine Entscheidung getroffen wurde, sollten die Gründe und der weitere Ablauf erklärt werden.
Mitarbeiter müssen dadurch nicht jede Projektdiskussion verfolgen. Sie erhalten aber genügend Kontext, um die Veränderung einordnen zu können.
Vor dem Start sollten Unternehmen zumindest diese Fragen beantworten können:
| Bereich | Leitfrage |
|---|---|
| Ziel | Können wir erklären, warum das ERP oder der Prozess verändert wird? |
| Betroffene Mitarbeiter | Wissen wir, welche Rollen sich konkret verändern? |
| Beteiligung | Haben die späteren Nutzer ihre Prozesskenntnisse eingebracht? |
| Prozesse | Sind neue Abläufe und Verantwortlichkeiten dokumentiert? |
| Key User | Gibt es pro relevantem Fachbereich geeignete Ansprechpartner? |
| Schulung | Passt das Lernformat zur jeweiligen Rolle und Tätigkeit? |
| Kommunikation | Wissen Mitarbeiter rechtzeitig, was wann passiert? |
| Go-live | Ist Unterstützung für die ersten Tage organisiert? |
| Support | Ist klar, wo fachliche und technische Fragen gemeldet werden? |
| Betrieb | Ist definiert, wer Prozesse nach der Einführung weiterentwickelt? |
Wenn mehrere dieser Fragen nicht beantwortet werden können, besteht ein organisatorisches Risiko, selbst wenn die technische Implementierung bereits weit fortgeschritten ist.
Sind Rollen und Zuständigkeiten bei Ihnen schon geklärt?
Ein ERP-System kann Prozesse strukturieren, Daten verbinden und manuelle Arbeit reduzieren. Es entscheidet aber nicht selbst, wie Mitarbeiter miteinander kommunizieren, wer Verantwortung übernimmt oder wie eine neue Arbeitsweise im Unternehmen verankert wird.
Genau deshalb entstehen Probleme rund um ERP-Einführungen nicht zwangsläufig durch fehlende Funktionen oder schlechte Technik.
Manchmal wurde zu spät kommuniziert. Mitarbeiter wurden nicht früh genug einbezogen. Rollen blieben unklar. Eine Schulung erklärte das System, aber nicht den neuen Prozess.
Diese Punkte wirken im Projektplan oft weniger technisch und damit weniger dringend.
Im Alltag entscheiden sie jedoch darüber, ob das neue ERP tatsächlich zum Arbeitswerkzeug wird oder ob Mitarbeiter versuchen, ihre bisherigen Abläufe um das neue System herum weiterzuführen.
Eine gute ERP-Einführung betrachtet deshalb drei Ebenen gemeinsam: System, Prozess und Menschen.
Erst wenn diese Ebenen zusammenspielen, kann aus einer technischen Einführung eine dauerhaft funktionierende Veränderung werden.
eloquium betrachtet ERP-Projekte nicht isoliert als Softwareinstallation. Vor einer Einführung werden bestehende Prozesse, Datenflüsse, Anforderungen und Verantwortlichkeiten betrachtet und mit der zukünftigen Systemstruktur abgeglichen.
Dazu gehören je nach Projekt neben Konfiguration, Migration und Schnittstellen auch Schulungen für Teams und Fachbereiche sowie die Begleitung über den Go-live hinaus.
Ziel ist nicht nur, dass ein ERP technisch funktioniert. Die dahinterliegenden Prozesse müssen im Unternehmen verstanden, verantwortet und im Alltag nutzbar sein.
Noch offene Punkte im ERP-Projekt?
Diese Gedanken haben wir zuerst auf LinkedIn geteilt – folgen Sie uns dort für weitere Einblicke.