Ein neues ERP-System sieht im Präsentationsdeck oft nach Ordnung aus: Prozesse werden sauber, Daten laufen, Entscheidungen werden „datenbasiert“. In der Praxis entscheidet jedoch selten das System allein, sondern der Mensch drumherum. Die Umstellung zieht sich durch Planung, Buchhaltung, Einkauf, Produktion und Vertrieb – und jeder dieser Bereiche hat eigene Abläufe, Gewohnheiten und Bilder davon, was „richtig“ ist.
Aus Beratungsperspektive habe ich erlebt, dass ERP-Projekte weniger an Technik scheitern als an Übergängen: an der Frage, wer ab wann welche Entscheidungen trifft, wie Fehler sichtbar werden und was mit Widerständen passiert, wenn der Go-live plötzlich vor der Tür steht. Genau hier setzt Change Management bei der Einführung neuer ERP-Systemen an – nicht als Schicht über dem Projekt, sondern als Arbeitsweise, die mit den Realitäten der Fachbereiche Schritt hält.
Warum ERP-Projekte im Alltag anders verlaufen als im Projektplan
ERP-Einführungen sind gern „Big Bang“-Vorhaben: ein Datum, ein System, viele Erwartungen. Doch selbst wenn die IT sauber liefert, rutschen an diesem Datum all die Kleinigkeiten zusammen: Stammdaten sind unvollständig, Schnittstellen verhalten sich anders als im Test und manche Prozesse wurden nur „ähnlich“ abgebildet. Dann wird das ERP zur täglichen Baustelle statt zur Lösung.
In solchen Phasen zeigt sich ein Muster: Das Projektteam arbeitet nach Meilensteinen, die Fachbereiche arbeiten nach Tagesgeschäft. Wer morgens eine Störung in der Produktion lösen muss, hat keine Kapazität für zusätzliche Schulungsfolien. Das führt zu stillen Umstellungen im Hinterzimmer: Workarounds, Excel-Schichten und doppelte Eingaben. Diese Ausweichbewegungen sind verständlich – und gleichzeitig Gift für Datenqualität und Steuerungslogik.
Ich erinnere mich an ein mittelständisches Produktionsunternehmen, das kurz vor dem Go-live eine sehr gute Schulungskampagne aufgesetzt hatte. In den ersten drei Wochen lief auch viel erstaunlich gut. Dann kam ein Auftragsspitzenmonat, die Abteilungen wurden wieder „voll ausgelastet“ und plötzlich verschob sich die Nutzung des Systems zurück in die alte Logik. Der entscheidende Unterschied war nicht die Trainingsqualität, sondern die fehlenden Freiräume für die Umstellung im operativen Betrieb.
Die häufigsten operativen Fehler – und was sie mit Verhalten zu tun haben
Ein häufiger Fehler ist, Change als Kommunikationsprogramm zu behandeln. Es gibt Mails, Intranet-Beiträge und ein paar Workshops. Aber sobald der erste Sachbearbeiter eine Rückfrage hat, zeigt sich, ob die Organisation wirklich vorbereitet ist. Wenn es keine klare Regel gibt, wie und wo man Hilfe bekommt, wird Kommunikation zur Verzögerungsmaschine.
Ein zweiter Stolperstein ist die „One-Size“-Prozesslogik. ERP zwingt Standardlogik oft stärker auf als erwartet. Wenn Ausnahmen nur im Projekt diskutiert werden und im Betrieb niemand weiß, wie man sie korrekt beantragt, entsteht ein Graubereich. Teams fangen dann an, Risiken zu minimieren, indem sie weniger im System tun – oder Informationen anders erfassen, als es die Zielprozesse vorsehen.
Drittens wird oft unterschätzt, wie viel Koordination nötig ist, bis Daten verlässlich fließen. Stammdatenpflege ist nicht nur ein Datenproblem. Sie ist ein Abstimmungsproblem zwischen Einkauf, Technik, Vertrieb und Buchhaltung. Wenn Rollen unklar sind, übernimmt am Ende jemand „irgendwie“ alles. Das funktioniert eine Weile – und bricht dann, wenn die Last steigt.
Typische Symptome im Betrieb
Man erkennt früh, ob die Organisation die Umstellung wirklich trägt. Besonders aussagekräftig sind nicht die Kennzahlen aus dem Projektbericht, sondern die Signale aus dem Alltag. Wenn Eskalationen zunehmen, wenn Freigaben länger dauern oder wenn Teams informelle Umwege schaffen, ist das ein Hinweis auf fehlende Prozess- und Rollenklärung.
Für die Diagnose helfen Beobachtungen, die jeder Projektleiter machen kann: Wie schnell werden Tickets beantwortet? Wie oft müssen Datensätze nachgepflegt werden? Welche Abteilungen liefern Ergebnisse, die andere Abteilungen wieder „aufräumen“ müssen? Aus solchen Mustern lässt sich ableiten, wo Change Management praktisch ansetzen muss.
| Symptom | Wahrscheinliche Ursache | Typischer Hebel |
|---|---|---|
| Viele manuelle Nacharbeiten nach dem Erfassen | Unklare Datenverantwortung oder fehlende Plausibilitäten | Rollen für Stammdaten + Regeln für Korrekturen |
| Freigaben dauern länger als geplant | Rollen, Eskalationswege oder Entscheidungskompetenz unklar | RACI + Schichtbetrieb für Go-live-Zeiten |
| Excel bleibt im Schattenbetrieb bestehen | System verhindert nicht, sondern ersetzt alte Arbeitsweisen nicht sauber | Prozess-Design nach Tagesrealität + klare Übergangsregeln |
| Schulungen verpuffen nach wenigen Tagen | Kein Coaching im Moment der Arbeit | „Super-User“ mit kurzer Feedbackschleife |
Change mit System: Rollen, Entscheidungen und Verantwortlichkeit
ERP ist ein Orchestrator für Prozesse. Damit er im Betrieb funktioniert, braucht die Organisation einen passenden Ordnungsrahmen. In der Praxis sind dabei drei Fragen entscheidend: Wer darf was ändern, wer entscheidet bei Abweichungen und wie wird gelernt, wenn die Realität anders ist als im Test.
Rollenklärung klingt banal, ist aber in ERP-Projekten ein echter Kostenblock. Wenn Fachbereichsexperten zwar im Projektteam sitzen, aber im Tagesgeschäft keine Entscheidungskompetenz haben, entsteht ein „Hängepunkt“. Das Ergebnis sind Schleifen aus Rückfragen und verspäteten Freigaben. Wer das vermeiden will, muss Entscheidungspfade definieren, bevor der Go-live Druck erzeugt.
Eine praxistaugliche Methode ist, Verantwortlichkeiten über ein RACI-Modell zu schärfen: Responsible, Accountable, Consulted, Informed. Entscheidend ist dabei nicht das Modell selbst, sondern die Umsetzung im Alltag. Jede Abteilung sollte am Ende genau wissen, wo sie eine Änderung anstößt und wer im Zweifel das letzte Wort hat.
Super-User statt Wissensmuseum
Super-User sind mehr als „Personen, die es können“. Sie sind schnelle Kontaktpunkte, wenn im Betrieb Fragen auftauchen. In einem guten Setup sitzen Super-User nicht nur im Schulungsraum, sondern sind in den ersten Wochen direkt dort, wo gearbeitet wird. So kann ein falscher Datensatz, der sich sonst über Tage fortpflanzt, innerhalb von Minuten korrigiert werden.
Ich habe einmal erlebt, wie ein Projektteam zu spät begriff, dass die besten Ansprechpartner nicht die Projektmanager waren, sondern jene Mitarbeitenden, die jeden Tag mit den Ergebnissen arbeiten. Sobald diese Super-User aktiv in die Schichtplanung eingebunden wurden, sank die Zahl der Eskalationen deutlich. Es ging nicht um mehr Kontrolle, sondern um schnellere Rückkopplung.
Stammdaten als Change-Anker: Qualität entsteht durch Ownership
Stammdaten wirken wie „Hintergrundarbeit“. Aber sie sind die Basis für alles: Lieferanten, Artikel, Stücklisten, Preise, Strukturen, Konten. Wenn Stammdaten vor dem Go-live nur „irgendwie“ migriert wurden, zeigt sich das später nicht als einzelne Fehlermeldung, sondern als Kettenreaktion in Berichten, Abgrenzungen und Planungslogik.
Stammdaten sind außerdem ein Macht- und Interessenthema. Jede Abteilung hat eigene Sichtweisen darauf, welche Felder wichtig sind. Einkauf denkt anders als Produktion, Buchhaltung anders als Vertrieb. Change Management wird hier konkret: Wer darf welche Felder pflegen? Wie werden Datenregeln definiert? Was passiert bei widersprüchlichen Anforderungen?
In erfolgreichen Projekten werden Stammdaten nicht nur bereinigt, sondern mit Verantwortungsmodellen dauerhaft abgesichert. Dazu gehören klare Workflows für Neuanlagen, die Regeln für Pflichtfelder und eine Plausibilitätslogik, die Fehler früh sichtbar macht. So wird Datenqualität zu einem operativen Standard und nicht zu einer einmaligen Migration.
Schulung, die im Moment hilft: Vom Kurs zur operativen Befähigung
Ein ERP-System ändert nicht nur Masken. Es verändert Routinen. Darum reicht es selten, Mitarbeitende einmalig zu schulen. Entscheidend ist, dass Lernmomente mit echten Arbeitsaufgaben verknüpft sind: Ein Einkaufsvorgang wird nicht in der Theorie geübt, sondern in einem Training, das einem realen Szenario entspricht.
Noch besser funktioniert ein zweistufiges Vorgehen. Zuerst lernen Teams die Zielprozesse und die Systemlogik, dann üben sie in kurzen Zyklen direkt vor und nach dem Go-live. So entsteht ein Kompetenzaufbau, der sich an der Belastung der Organisation orientiert. Wer das nicht macht, bekommt Schulungsberichte ohne Effekt.
Wichtig ist auch die Sprache. Je näher Schulungsunterlagen an den Begriffen des Fachbereichs sind, desto weniger entsteht Widerstand. „Warum heißt das Feld so?“ ist keine akademische Frage, sondern eine Frage nach dem Gefühl, dass das System die Realität versteht. Wenn die Schulung dagegen in IT-Sprache bleibt, werden Lerninhalte als Fremdkörper empfunden.
Kommunikation ohne Theater
Kommunikation kann helfen, aber sie kann auch Türen zuschlagen. Zu optimistische Botschaften erzeugen später Frust, wenn die Realität komplexer ist. Besser ist eine klare, ehrliche Kommunikation über Übergänge: Was ändert sich ab wann? Welche Prozesse laufen parallel? Welche Regeln gelten bei Abweichungen?
Für die Praxis lohnt sich ein „Übergangsplan“ als Kommunikationsartefakt, der nicht nur Termine enthält, sondern konkrete Arbeitsanweisungen. So wissen Teams, ob sie einen Auftrag noch im alten System abschließen dürfen oder ob es klare Stichtage für bestimmte Buchungsarten gibt. Das spart Konflikte, weil Missverständnisse weniger Raum haben.
Messbar machen: Indikatoren für Akzeptanz und Stabilität
Akzeptanz entsteht nicht aus Umfragen. Sie zeigt sich in der Nutzung, in der Qualität der Daten und in der Geschwindigkeit, mit der das System im Alltag läuft. Trotzdem sollte das Projekt Monitoring einbauen, das nicht nur technische Fehler erfasst, sondern auch Prozesswirkungen.
Typische Messpunkte sind etwa die Ticketlast in den ersten Wochen, die Anzahl der Korrekturschleifen bei Stammdaten, die Durchlaufzeit für Freigaben und die Quote der Vorgänge, die „straight through“ durchlaufen. Bei all dem gilt: Nicht jede Schwankung ist ein Scheitern. Aber wenn Trends kippen, braucht es eine Entscheidung, ob Training nachgezogen wird, Prozesse angepasst oder Rollen geschärft werden müssen.
Bei einem Projekt habe ich gesehen, wie ein simples Ampelsystem im Shopfloor-Bereich Wirkung hatte: grün für stabile Abläufe, gelb für häufige Nacharbeiten, rot wenn ein Prozessabschnitt wieder in den Schattenbetrieb rutschte. Das sorgte für eine gemeinsame Lageeinschätzung, statt für Meinungsduelle zwischen IT und Fachbereichen.
Ein tragfähiger Go-live: Vorbereitung auf den Tag danach
Viele ERP-Projekte planen den Go-live wie einen Startschuss. Was sie stärker berücksichtigen sollten, ist der „Tag danach“. Das heißt: Es braucht eine klare Betriebsorganisation für Probleme, ein Support-Modell mit Reaktionszeiten und eine Eskalationskette, die nicht erst gesucht wird, wenn es brennt.
Ebenso wichtig ist ein Übergangsfenster, in dem parallel gearbeitet werden darf, ohne Chaos zu erzeugen. Parallelität ist oft nötig, um Übergaben zwischen Teams zu sichern. Aber sie muss begrenzt und geregelt sein: Welche Aktionen sind erlaubt, welche sind gesperrt? Sonst entsteht doppelte Buchung oder widersprüchliche Versionierung.
Erfahrene Projektteams planen außerdem gezielt „Peak-Zeiten“. Wenn in der Umstellungsphase Monatsabschluss oder saisonale Auftragswellen anstehen, müssen Ressourcen entsprechend verschoben werden. Change Management bei der Einführung neuer ERP-Systemen bedeutet dann nicht nur Begleitung, sondern auch Kapazitätslogik: Der Betrieb wird nicht weniger anspruchsvoll, nur weil ein neues System eingeführt wurde.
Widerstände nutzen: Wo Skepsis produktiv wird
Skepsis ist im ERP-Kontext oft rational. Mitarbeitende sehen, dass zusätzliche Schritte entstehen, dass Freigaben strenger werden oder dass bisherige Spielräume wegfallen. Wer Widerstand ignoriert, bekommt verdeckte Umgehungen. Wer ihn sammelt und strukturiert, gewinnt wertvolle Hinweise für Prozessanpassungen oder für die Reihenfolge im Rollout.
Ein guter Ansatz ist, Widerstand als Datenquelle zu behandeln. In Workshops und im Support-Betrieb sollten die häufigsten Beschwerden kategorisiert werden: Bedienbarkeit, Prozesslogik, Stammdaten, Rechte oder Reporting. Dann lässt sich entscheiden, ob es sich um ein einmaliges Missverständnis handelt oder um ein strukturelles Designproblem.
So werden Gespräche produktiver. Statt „Die Leute wollen nicht“ entsteht „Wo genau hakt der Prozess, und welche Regel brauchen wir, damit die Arbeit im Alltag schneller wird?“. Diese Perspektive verändert die Tonalität im Projekt und reduziert die Distanz zwischen IT und Fachbereichen.
Rollout und Nachhaltigkeit: Verbesserung nach dem Betriebseintritt
Nach dem Go-live endet das Projekt nicht. Es beginnt die Phase, in der reale Arbeit das System stabilisieren muss. Gerade in Rollouts über mehrere Standorte oder Module ist die Reihenfolge entscheidend. Häufig ist es klüger, zuerst jene Bereiche zu schalten, bei denen die Datenqualität am schnellsten nutzbar wird und die Prozesslogik am klarsten ist.
Für Nachhaltigkeit braucht es eine Routine zur kontinuierlichen Verbesserung. Dazu gehören regelmäßige Auswertungen der Systemnutzung, ein klarer Prozess für Änderungsanforderungen und ein „Lernregister“ aus Fehlern. Dieses Register sollte nicht als Schuldensammlung funktionieren, sondern als Gedächtnis der Organisation: Welche Fehler treten wiederholt auf, und warum?
Wenn Unternehmen das hinbekommen, wird aus der ERP-Einführung eine Kompetenz. Neue Standards sind dann nicht nur IT-Thema, sondern Teil der Betriebsführung. Und genau dort wird der Unterschied sichtbar zwischen „ERP ist eingeführt“ und „ERP arbeitet im Unternehmen“.
Ein praktisches Schlussmuster für das Projektteam
Am Ende entscheidet ein einfaches Zusammenspiel: klare Rollen, saubere Stammdaten-Ownership, Schulung mit unmittelbarer Arbeitshilfe, ein Support, der nicht im Vagen bleibt, und messbare Indikatoren für Stabilität. Wer diese Bausteine ernst nimmt, reduziert das Risiko, dass aus dem neuen System ein Schattennetz aus Umwegen wird.
Wenn ich auf frühere Projekte zurückblicke, ist mir vor allem eines hängen geblieben: Teams akzeptieren Veränderungen schneller, wenn sie merken, dass das Management die Folgen trägt. Das bedeutet Ressourcen, klare Regeln und schnelle Entscheidungen. Dann wird ERP nicht zur Belastung, sondern zum Werkzeug, das den Alltag tatsächlich entlastet.
