Key-User im ERP-Projekt: Erfolgsfaktor für Change, Akzeptanz und Go-Live

Kernaussagen

• Key-User sind im ERP-Projekt keine Nebenrolle, sondern ein zentraler Erfolgsfaktor.
• Wer Key-User nur als Tester oder Schulungsunterstützung versteht, unterschätzt ihre Bedeutung für Prozesse, Akzeptanz und Go-Live-Fähigkeit.
• Im ERP-Projekt werden künftige Arbeitsweisen festgelegt; Key-User entscheiden mit, ob diese Arbeitsweisen praxistauglich und tragfähig sind.
• Die größte Schwachstelle ist oft nicht fehlende Kompetenz, sondern fehlende Freistellung, unklare Erwartungen und schwache Linienunterstützung.
• Ein belastbares ERP-Projekt braucht deshalb ein strukturiertes Key-User-Programm statt nur nominierter Personen.

Key-User im ERP-Projekt: Warum sie über Akzeptanz, Arbeitsweise und Projekterfolg entscheiden

ERP-Projekte werden in Unternehmen noch immer zu oft wie reine Softwarevorhaben behandelt. Im Projektplan stehen Systemauswahl, Fachkonzept, Customizing, Tests und Go-Live. Was dabei leicht unterschätzt wird: Mit einem ERP-System werden nicht nur Masken und Funktionen eingeführt. Es werden künftige Arbeitsweisen, Verantwortlichkeiten, Prozesslogiken und Informationsflüsse für viele Jahre geprägt.

Genau an dieser Stelle werden Key-User kritisch. Sie sind nicht einfach Personen aus den Fachbereichen, die gelegentlich Workshops besuchen oder später Schulungen unterstützen. Sie sind die Verbindung zwischen Projektlogik und betrieblicher Realität. Wenn diese Rolle zu schwach besetzt, zu spät eingebunden oder organisatorisch nicht abgesichert wird, entstehen typische Projektrisiken: Entscheidungen werden verzögert, Tests bleiben oberflächlich, Widerstände werden zu spät sichtbar und die neue Arbeitsweise wird in der Organisation nicht sauber verankert.

Das ist keine Nebensache. BCG beschreibt für Transformations- und AI-Vorhaben die bekannte 10-20-70-Logik: Wert entsteht nicht nur aus Technologie, sondern zu einem großen Teil aus Menschen, Prozessen und kultureller Veränderung. Diese Logik ist zwar nicht exklusiv für ERP formuliert, passt aber sehr gut auf ERP-Projekte, weil auch dort der Erfolg wesentlich von organisatorischer Umsetzung und gelebter Arbeitsweise abhängt. [1][2]

Key-User tragen im ERP-Projekt nicht nur Fachwissen bei, sondern prägen Akzeptanz, Prozessqualität und Go-Live-Readiness.

Warum Key-User im ERP-Projekt so wichtig sind

Ein ERP-Projekt verändert die operative Arbeit. Prozesse werden standardisiert oder neu zugeschnitten, Verantwortlichkeiten verschieben sich, Ausnahmen werden sichtbar, Medienbrüche werden hinterfragt und informelle Routinen geraten unter Druck. Genau deshalb reicht es nicht, wenn das Projektteam nur technisch oder konzeptionell sauber arbeitet. Es braucht Personen aus den Fachbereichen, die beurteilen können, ob eine geplante Lösung im Alltag tragfähig ist.

Key-User übernehmen dabei eine besondere Rolle. Sie kennen nicht nur Soll-Prozesse aus der Präsentation, sondern auch die reale Arbeitsweise mit allen Sonderfällen, Umgehungslösungen und impliziten Abhängigkeiten. Sie helfen damit, Projektentscheidungen auf Praxistauglichkeit zu prüfen. Gleichzeitig sind sie oft die ersten glaubwürdigen Ansprechpartner im Bereich, wenn Unsicherheit oder Skepsis gegenüber dem neuen System entsteht. Eure Präsentation fasst diese Logik sauber zusammen: Key-User wirken als Wissens- und Prozessexperten, als Change-Multiplikatoren und als Qualitätssicherer im Test.

Gerade für mittelständische Unternehmen ist das relevant. Dort hängt der Projekterfolg oft an wenigen Personen, die fachlich stark sind, intern akzeptiert werden und gleichzeitig das Tagesgeschäft kennen. Wenn diese Personen im Projekt tragfähig eingebunden sind, steigt die Wahrscheinlichkeit, dass das ERP nicht nur eingeführt, sondern auch organisatorisch angenommen wird. Panorama betont in seinen Beiträgen zu ERP-Adoption und Change Management, dass geringe Nutzerakzeptanz häufig mit schwachem Change Management zusammenhängt und Stakeholder früh und sinnvoll eingebunden werden müssen. [3][4]

Die drei Rollen von Key-Usern: Prozessexperte, Change-Multiplikator und Qualitätssicherer

Wissens- und Prozessexperte

Key-User kennen die Ist-Prozesse aus der Praxis. Sie wissen, wo Standardabläufe funktionieren, wo Ausnahmen entscheidend sind und welche Prozessschritte in der Realität anders laufen als in offiziellen Beschreibungen. Genau deshalb können sie neue Systemlösungen nicht nur funktional, sondern betrieblich bewerten. In eurer Folie ist das sehr treffend beschrieben: Sie kennen Ist-Prozesse und Ausnahmen aus dem Alltag, bewerten Systemlösungen auf Praxistauglichkeit und tragen die Prozessfreigabe vor Go-Live mit. [6]

Für das Projekt bedeutet das: Key-User sind keine „Teilnehmer“ im Workshop, sondern fachliche Sparringspartner für Soll-Prozesse, Fit-to-Standard-Entscheidungen und Priorisierung. Wer diese Rolle zu schwach definiert, riskiert, dass Lösungen zwar auf dem Papier funktionieren, aber im späteren Betrieb unnötige Reibung erzeugen.

Change-Multiplikator

Key-User wirken nicht nur fachlich, sondern sozial und organisatorisch. Kolleginnen und Kollegen orientieren sich im Projektalltag oft weniger an Projektfolien als an internen Vertrauenspersonen. Wenn Key-User Veränderungen erklären, Bedenken aufnehmen und Rückmeldungen weitergeben, entsteht ein anderer Qualitätstyp von Akzeptanz: weniger formal, dafür deutlich alltagsnäher.

Eure Folie nennt genau diese Punkte: Key-User sind erste Ansprechpartner im Fachbereich, tragen Veränderung aktiv in den Bereich und helfen, Widerstände durch frühzeitige Einbindung sichtbarer zu machen. Das ist ein zentraler Punkt. Akzeptanz entsteht nicht erst in der Anwenderschulung kurz vor Go-Live, sondern schon viel früher, nämlich in der Frage, ob Mitarbeitende das neue Prozessbild für realistisch, nachvollziehbar und fair halten. Dafür braucht es interne Übersetzer, nicht nur externe Projektkommunikation.

Qualitätssicherer im Test

Ein dritter, oft unterschätzter Teil der Rolle liegt in Test und Abnahme. Key-User führen Integrations- und Abnahmetests mit, melden Abweichungen und geben Rückmeldung dazu, ob Soll-Prozesse fachlich tragfähig umgesetzt wurden. In eurer Präsentation wird diese Funktion ausdrücklich hervorgehoben, bis hin zur formalen Go-Live-Freigabe für den eigenen Bereich und der Absicherung der Nachhaltigkeit nach der Einführung.

Gerade hier zeigt sich, wie riskant eine zu enge Sicht auf Key-User ist. Wer sie nur als spätere Schulungsunterstützung betrachtet, verliert genau die Personen, die im Test fachlich entscheiden könnten, ob das neue Prozessmodell wirklich trägt.

Warum die Rolle in vielen ERP-Projekten trotzdem unterschätzt wird

In vielen Projekten wird die Bedeutung von Key-Usern nicht auf der Folie unterschätzt, sondern in der Realität. Formal gibt es benannte Personen. Organisatorisch fehlen aber Zeit, Mandat, Priorität und Rückendeckung.

Ein typisches Muster ist die Doppelrolle ohne echte Entlastung. Fachbereichsleiter benennen einen Namen, geben aber keine belastbare Kapazität frei. Der Key-User soll dann Projektarbeit und Linienaufgaben parallel tragen. Solange die Belastung moderat ist, bleibt dieses Modell scheinbar stabil. In Kernphasen wie Blueprint, Test oder Go-Live kippt es jedoch häufig. Dann verdrängen operative Anforderungen die Projektarbeit, Entscheidungen werden verschoben und die Qualität leidet.

Hinzu kommt ein zweites Missverständnis: Key-User werden in manchen Organisationen primär mit IT-Schulung oder Toolwissen verbunden. Eure Warnsignal-Folie benennt genau diese Verwechslung: Rollenverständnis fehlt, wenn Key-User sich als Mitmacher statt als Verantwortliche sehen oder wenn die Rolle mit IT-Schulung statt Prozessverantwortung verwechselt wird.

Aus Projektsicht ist das kritisch. Denn damit wird die Rolle in einen späten, eher operativen Abschnitt gedrängt, obwohl sie eigentlich schon in der Phase der Prozessgestaltung und Veränderung wirksam sein muss.

Vier Warnsignale, dass Key-User nicht tragfähig aufgestellt sind

Bestimmte Probleme zeigen sich in ERP-Projekten früh. Sie werden aber oft als individuelles Verhalten einzelner Personen fehlgedeutet, obwohl sie strukturelle Ursachen haben.

1. Zeitliche Verfügbarkeit ist ungeklärt

Das erste Warnsignal ist banal und zugleich hochrelevant: Es ist nicht verbindlich geklärt, wie viel Zeit der Key-User tatsächlich für das Projekt hat. Eure Folie nennt dafür drei sehr typische Punkte: Freistellung ist nicht schriftlich vereinbart, es gibt keine Stellvertreterregelung und die Doppelrolle wird ohne Kapazitätsausgleich akzeptiert. [7]

Das ist mehr als ein Planungsdetail. Wenn Projektarbeit immer nur um die Linie herum organisiert wird, bleibt die Rolle im Konfliktfall strukturell schwach.

2. Das Rollenverständnis fehlt

Ein zweites Warnsignal ist ein zu schwach definiertes Mandat. Wenn Erwartungen nicht klar formuliert sind, sehen sich Key-User leicht als Unterstützer statt als Mitverantwortliche für Prozessgestaltung, Testqualität und organisatorische Verankerung. Auch das spiegelt eure Folie deutlich.

Dann entstehen typische Folgen: Rückmeldungen bleiben unverbindlich, Entscheidungen werden nicht getragen, und im Go-Live wird sichtbar, dass zentrale Prozessfragen nie wirklich im Fachbereich verankert waren.

3. Führungsunterstützung ist zu schwach

Das dritte Warnsignal liegt in der Linie. Eure Präsentation formuliert es sehr klar: Bereichsleiter nennen Namen, geben aber keine Kapazität frei; Prioritätskonflikte werden ausgesessen statt eskaliert; dem Projekt fehlt Rückendeckung in der Linie.

Genau hier wird aus einem vermeintlichen Personenproblem ein Führungsproblem. Wenn die Linienorganisation nicht aktiv mitzieht, ist auch ein engagierter Key-User auf Dauer überfordert.

Weiterführend: In vielen Projekten entscheidet genau hier die tatsächliche Qualität von Management-Unterstützung. Mehr dazu in unserem Beitrag zu Management-Support in ERP-Projekten.

4. Motivation und Vorerfahrung sind niedrig

Nicht jeder Key-User braucht vorherige ERP-Erfahrung. Problematisch wird es aber, wenn Unsicherheit, geringe Motivation und die Haltung „Das mache ich nebenbei“ zusammenkommen. Eure Folie nennt zusätzlich die Angst vor Mehrarbeit oder stillem Kompetenzverlust.

Das ist für ERP-Projekte besonders relevant, weil Veränderungen im Prozess oft auch bestehende Routinen, informelle Expertise und lokale Gestaltungsspielräume infrage stellen. Genau deshalb ist die Rolle nicht nur fachlich, sondern auch emotional und kulturell sensibel.

Key-User sind ein Change-Thema, nicht nur ein Projektdetail

Viele Unternehmen investieren im ERP-Projekt erhebliche Energie in Anbieter, Funktionen, Schnittstellen und Testpläne. Das ist notwendig. Es reicht aber nicht. Der Nutzen eines ERP-Systems entsteht nicht allein aus der technischen Lösung, sondern aus ihrer Einbettung in Arbeitsweisen, Verantwortlichkeiten und bereichsübergreifende Zusammenarbeit.

Genau hier hilft die BCG-Logik. Wenn Transformationswert zu einem großen Teil aus Menschen, Prozessen und kultureller Veränderung entsteht, dann ist es folgerichtig, Key-User nicht nur als operative Hilfsfunktion, sondern als Träger dieser Umsetzung zu behandeln. [1][2]

Panorama argumentiert ähnlich aus ERP-Perspektive: Wirksames Change Management schafft eine gemeinsame Sprache, klare Struktur und messbare Adoptionspfade; schwaches Change Management erhöht dagegen das Risiko geringer Systemnutzung und organisatorischer Reibung. [3][4]

Für ERP-Projekte heißt das praktisch: Key-User sind wichtig, weil sie Veränderungen in die Fachbereiche hinein übersetzen. Sie sehen früh, wo neue Prozesse auf Skepsis stoßen, wo das Prozessdesign an der Realität vorbeigeht oder wo Kollegen Schulung zwar absolvieren, aber die neue Logik innerlich nicht mittragen. Das macht sie zu einem zentralen Change-Baustein.

Gerade weil im ERP-Projekt künftige Arbeitsweisen für Jahre geprägt werden, lohnt sich auch eine strategische Perspektive auf Zielbild, Rollen und organisatorische Tragfähigkeit. Passend dazu: ERP-Strategie und Zukunftsfähigkeit.

Was Unternehmen stattdessen brauchen: ein strukturiertes Key-User-Programm

Ein häufiger Projektfehler ist, Personen zu benennen, ohne ein Programm aufzusetzen. Eure Folie formuliert hier eine starke Leitthese: Das Key-User-Programm ist kein Projekt-Anhang, sondern Projekt-Voraussetzung.

Daraus lassen sich drei praktische Anforderungen ableiten.

Vor Projektstart fixieren

Vor Projektstart sollte nicht nur geklärt sein, wer Key-User wird, sondern auch unter welchen Bedingungen. Dazu gehören:

• formale Benennung,
• Freistellungsvereinbarung,
• Stellvertreterregelung,
• grober Kapazitätsplan über die Projektphasen.

Diese Punkte tauchen in eurer Folie explizit auf und sind fachlich sehr plausibel, weil sie das spätere Konfliktpotenzial in der Linie deutlich reduzieren.

Steuerung ab Tag 1

Ein Key-User-Programm braucht von Beginn an Struktur. Eure Präsentation empfiehlt dafür unter anderem Key-User-Meetings, Bereichsleiter-Updates, eine Verfügbarkeitsampel und klar kommunizierte Eskalationspfade.

Das ist mehr als Reporting. Es schafft Sichtbarkeit darüber, ob die Rolle im Projekt tatsächlich tragfähig gelebt wird. Gerade in mittelständischen Projekten mit knappen Ressourcen ist das wichtig, weil Probleme sonst lange verdeckt bleiben und erst in kritischen Projektphasen eskalieren.

Geschäftsführung aktiv einbinden

Ein weiterer starker Punkt aus euren Folien ist das GF-Backing. Dort wird klar formuliert: Geschäftsführung sollte nicht nur Sponsor im Lenkungsausschuss sein, sondern Priorität direkt in die Linie kommunizieren und bei Engagement-Problemen als Backing-Instanz wirken.

Das ist aus Projektperspektive sehr schlüssig. Viele Prioritätskonflikte lassen sich nicht auf Ebene einzelner Key-User lösen, weil sie strukturell aus der Linienorganisation kommen. Dann braucht das Projekt eine Eskalationsinstanz mit echter Wirkung.

Wenn das Engagement kippt: Ermüdung früh erkennen

Auch gut aufgesetzte Key-User-Rollen können im Projektverlauf an Tragfähigkeit verlieren. Das ist vor allem in längeren ERP-Projekten relevant. Eure Engagement-Folie nennt dafür typische Signale:

• sinkende Meeting-Teilnahme,
• Reaktionszeiten von mehr als 48 Stunden,
• häufigere „Nebenbei“-Aussagen,
• Verdrängung durch Linienaufgaben,
• eine kippende Stimmung im Sinne von „Das wird nie fertig“.

Wichtig ist, diese Symptome nicht zu schnell als individuelles Motivationsproblem zu deuten. In vielen Fällen verweisen sie auf Überlastung, unklare Priorisierung oder fehlende Anerkennung im Projektverlauf.

Ebenso praxisnah sind die vorgeschlagenen Sofortmaßnahmen: 

• 1:1-Gespräch mit Projektleitung,
• aktives Einbinden des Bereichsleiters,
• vorübergehende Reduktion von Projektaufgaben,
• sichtbares Machen kleiner Erfolge,
• Eskalation an die Geschäftsführung, wenn Bereichsleiter nicht reagieren.

Gerade der letzte Punkt zeigt noch einmal, worum es im Kern geht: Key-User-Commitment ist keine reine Motivationsfrage, sondern eine Steuerungsfrage.

Fazit: Ohne tragfähige Key-User scheitert ein ERP-Projekt nicht an der Software, sondern an der Organisation

Key-User sind im ERP-Projekt weit mehr als Tester, Schulungshelfer oder fachliche Ansprechpartner. Sie tragen drei kritische Funktionen zugleich: Sie bewerten Prozesse fachlich, übersetzen Veränderung in die Organisation und sichern die Qualität der Umsetzung im Test und vor Go-Live.

Genau deshalb ist ihre Rolle so wirksam — und so anfällig für Fehlsteuerung. Wenn Freistellung ungeklärt bleibt, Rollenverständnis fehlt oder Linienprioritäten das Projekt ausbremsen, wird aus einer formal benannten Rolle schnell ein strukturelles Risiko. Die Folgen zeigen sich nicht immer sofort, aber fast immer später: in schwacher Akzeptanz, unzureichenden Tests, verzögerten Entscheidungen und einer neuen Arbeitsweise, die im Alltag nicht wirklich trägt.

Für Unternehmen bedeutet das: Ein belastbares ERP-Projekt braucht nicht nur Key-User-Namen auf dem Projektplan. Es braucht ein strukturiertes Key-User-Programm mit Auswahl, Freistellung, Steuerung, Eskalation und echter Management-Rückendeckung. Erst dann können Key-User die Rolle übernehmen, die sie im Projekt tatsächlich haben sollten: nicht Projekt-Anhang, sondern Projekt-Voraussetzung.

Ihr nächster Schritt

Wenn Sie in Ihrem ERP-Projekt merken, dass Key-User formal benannt, aber organisatorisch noch nicht tragfähig aufgestellt sind, lohnt sich eine frühe Strukturierung. Gerade in ERP-Projekten entscheidet sich oft schon vor Blueprint, Test und Go-Live, ob Rollen, Kapazitäten und Verantwortlichkeiten in der Organisation wirklich tragen.

Eine saubere Projektsteuerung auf Fachbereichsseite ist deshalb kein Detail der Einführung, sondern ein wesentlicher Baustein für Projekterfolg, Akzeptanz und Zukunftsfähigkeit.

FAQ

Welche Rolle haben Key-User im ERP-Projekt?

Key-User verbinden Fachbereich und Projektteam. Sie bringen Prozesswissen aus dem Alltag ein, helfen bei der Bewertung neuer Lösungen, tragen Veränderungen in den Bereich und wirken in Tests und Freigaben mit.

Warum sind Key-User für die Akzeptanz eines ERP-Systems so wichtig?

Weil Akzeptanz nicht allein durch Projektkommunikation oder Schulung entsteht. Key-User machen neue Prozesse im Fachbereich greifbar, nehmen Bedenken früh auf und helfen, tragfähige Arbeitsweisen in der Organisation zu verankern.

Welche typischen Fehler machen Unternehmen bei Key-Usern?

Häufig werden Key-User zwar benannt, aber nicht sauber freigestellt, nicht klar mandatiert oder ohne echte Linienunterstützung ins Projekt geschickt. Typisch sind auch fehlende Stellvertreterregelungen und eine Reduktion der Rolle auf Schulung oder Test.

Woran erkennt man früh, dass Key-User im Projekt nicht tragfähig aufgestellt sind?

Frühe Warnsignale sind ungeklärte Verfügbarkeit, unklare Erwartungen, fehlende Rückendeckung aus der Linie und sinkendes Engagement im Projektverlauf.

Wie lässt sich ein Key-User-Programm sinnvoll strukturieren?

Sinnvoll ist ein strukturierter Ansatz mit formaler Benennung, Freistellungsvereinbarung, Stellvertreterregelung, Kapazitätsplanung, regelmäßigem Reporting, Eskalationspfaden und aktivem Management-Backing.

Quellen

1. Boston Consulting Group. (2025). From potential to profit: Closing the AI impact gap. https://www.bcg.com/publications/2025/closing-the-ai-impact-gap
2. Boston Consulting Group. (2025). AI Radar 2025 [Slide deck]. https://web-assets.bcg.com/0b/f6/c2880f9f4472955538567a5bcb6a/ai-radar-2025-slideshow-jan-2025-r.pdf
3. Panorama Consulting Group. (2023). 3 causes of low ERP system adoption among end-users. https://www.panorama-consulting.com/causes-of-low-erp-system-adoption-among-end-users/
4. Panorama Consulting Group. (2024). What is effective change management? https://www.panorama-consulting.com/effective-change-management/
5. Panorama Consulting Group. (2025). How to identify and engage invisible ERP stakeholders. https://www.panorama-consulting.com/how-to-identify-and-engage-invisible-erp-stakeholders/