Change Management bei ERP-Einführung: Organisation, Rollen und Akzeptanz

Change Management bei ERP-Einführung entscheidet häufiger über Erfolg oder Scheitern eines Projekts als die Auswahl der Software selbst. Wenn ein ERP-Vorhaben im Mittelstand aus dem Ruder läuft, liegt die Ursache selten in fehlenden Systemfunktionen. Sie liegt in Prozessentscheidungen, die niemand treffen wollte, in Stammdaten, deren Qualität erst beim Testlauf sichtbar wurde, und in Fachbereichen, die das neue System als Bedrohung ihrer eingeübten Arbeitsweise erleben. Ein ERP-System berührt nahezu jeden operativen Ablauf gleichzeitig, von der Angebotserstellung über die Disposition bis zur Rechnungsstellung. Damit unterscheidet es sich grundlegend von der Einführung einer Fachanwendung, die nur einen Bereich betrifft. Wer diese Breite unterschätzt und die Einführung als IT-Projekt behandelt, produziert eine technisch korrekte Installation ohne organisatorische Wirkung. Dieser Beitrag beschreibt, wie die Veränderungsarbeit parallel zur technischen Umsetzung organisiert wird, welche Rollen dafür erforderlich sind und woran sich der Fortschritt messen lässt.

Titelbild: Foto von Annie Spratt auf Unsplash.

Warum ERP-Projekte organisatorisch anders gelagert sind

Drei Eigenschaften unterscheiden ERP-Vorhaben von anderen Digitalisierungsprojekten und begründen den erhöhten Aufwand für die Veränderungsbegleitung.

Die erste ist die Gleichzeitigkeit. Ein neues System löst in der Regel nicht ein einzelnes Werkzeug ab, sondern eine über Jahre gewachsene Landschaft aus Altsystem, Tabellenkalkulationen, Nebenlisten und informellen Absprachen. Diese Schattensysteme sind selten dokumentiert, tragen aber erhebliche Teile der operativen Steuerung. Ihre Ablösung erzeugt Unsicherheit bei genau den Beschäftigten, die bislang als besonders leistungsfähig galten, weil ihre Kompetenz an diesen Werkzeugen hing.

Die zweite ist die Standardisierungsfrage. Jede ERP-Einführung zwingt zu einer Entscheidung zwischen der Anpassung des Systems an bestehende Abläufe und der Anpassung der Abläufe an den Systemstandard. Diese Entscheidung ist keine technische, sondern eine unternehmerische. Sie wird jedoch häufig implizit auf Projektebene getroffen, weil auf Leitungsebene niemand sie ausdrücklich verantworten will.

Die dritte ist die Sichtbarkeit von Datenqualität. Altsysteme tolerieren unvollständige Stammdaten, weil erfahrene Mitarbeiter Lücken im Kopf schließen. Ein integriertes System tut das nicht. Fehlende Materialstammdaten oder inkonsistente Kundenkonditionen führen unmittelbar zu Prozessabbrüchen, die als Systemfehler wahrgenommen werden, obwohl sie Datenfehler sind.

Das Rollenmodell: wer welche Entscheidung trägt

Ein tragfähiges Rollenmodell verhindert die häufigste Verzögerungsursache, nämlich offene Prozessfragen ohne benannten Entscheider. Bewährt hat sich eine Struktur mit fünf klar abgegrenzten Rollen.

Rolle	Verantwortung	Zeitanteil im Projekt	Typische Besetzung
Auftraggeber	Zielbild, Budget, Eskalationsinstanz, Standardisierungsentscheidung	2 bis 4 Stunden je Woche	Geschäftsführung
Projektleitung	Steuerung, Termine, Abstimmung mit dem Implementierungspartner	60 bis 100 Prozent	erfahrene Führungskraft, nicht zwingend aus der IT
Prozessverantwortliche	fachliche Entscheidung je Hauptprozess, Abnahme der Konfiguration	20 bis 40 Prozent	Bereichsleitungen
Key User	Detailwissen, Testfälle, Schulung der Kollegen, Rückmeldung aus der Praxis	20 bis 30 Prozent	anerkannte Fachkräfte aus dem Tagesgeschäft
Datenverantwortliche	Bereinigung und Migration der Stammdaten je Datenobjekt	30 bis 50 Prozent in der Migrationsphase	Sachbearbeitung mit Bestandskenntnis

Entscheidend ist die tatsächliche Freistellung. Eine Key-User-Rolle, die zusätzlich zum vollen Tagesgeschäft ausgeübt werden soll, wird regelmäßig zugunsten des Tagesgeschäfts vernachlässigt. Die Konsequenz zeigt sich erst im Test, wenn Abweichungen zwischen Konfiguration und Praxis auffallen und Nacharbeiten erzwingen. Wer die Freistellung nicht organisatorisch absichert, etwa durch befristete Aushilfen oder bewusst zurückgestellte Aufgaben, verschiebt den Aufwand lediglich in eine spätere und teurere Projektphase.

Die Standardisierungsentscheidung früh und ausdrücklich treffen

Vor Konfigurationsbeginn sollte die Geschäftsführung eine Grundsatzentscheidung dokumentieren, in welchem Umfang vom Systemstandard abgewichen werden darf. Ohne diese Vorgabe entsteht in jedem Workshop dieselbe Diskussion neu, mit unterschiedlichen Ergebnissen je nach Durchsetzungskraft der Beteiligten.

Praktikabel ist eine Klassifizierung der Prozesse in drei Gruppen. Prozesse ohne Wettbewerbsrelevanz, etwa Buchhaltung oder Reisekostenabrechnung, folgen ausnahmslos dem Standard. Prozesse mit mittlerer Relevanz werden im Standard umgesetzt, sofern der Mehraufwand für Beschäftigte vertretbar bleibt. Nur Prozesse, die den Marktvorteil des Unternehmens unmittelbar tragen, etwa eine besondere Variantenkonfiguration oder eine spezifische Serviceleistung, rechtfertigen eine Anpassung.

Jede Systemanpassung ist eine Entscheidung, die bei jedem künftigen Versionswechsel erneut Aufwand erzeugt. Sie ist deshalb nicht mit dem Aufwand ihrer Programmierung bezahlt, sondern mit dem Aufwand ihrer Pflege über die gesamte Nutzungsdauer.

Die Erfahrung zeigt, dass Anpassungswünsche in Workshops regelmäßig mit dem Argument begründet werden, ein Ablauf sei historisch so gewachsen. Eine wirksame Gegenfrage lautet, welcher wirtschaftliche Nachteil entstünde, wenn der Standard verwendet würde. Lässt sich dieser Nachteil nicht beziffern, ist der Anpassungswunsch in der Regel eine Gewohnheit und keine Anforderung.

Das Key-User-Konzept als Kern der Veränderungsarbeit

Key User sind der wichtigste Übertragungsweg zwischen Projekt und Organisation. Ihre Auswahl entscheidet über die Akzeptanz im Fachbereich stärker als jede Kommunikationsmaßnahme.

• Auswahlkriterium ist fachliche Anerkennung, nicht Verfügbarkeit. Wer benannt wird, weil er gerade Kapazität hat, überträgt keine Glaubwürdigkeit in den Bereich.
• Frühe Einbindung. Key User gehören bereits in die Prozessaufnahme, nicht erst in den Test. Wer nur prüfen darf, was andere entschieden haben, entwickelt keine Mitverantwortung.
• Eigene Qualifizierung vor der Schulungsphase. Ein Key User, der die Kollegen schulen soll, benötigt einen zeitlichen Vorlauf von mehreren Wochen im System, nicht eine Einweisung eine Woche vor dem Start.
• Sichtbare Rolle nach dem Start. Die Rolle endet nicht mit dem Produktivstart. In den ersten Monaten ist der Key User erste Anlaufstelle für Fragen und filtert echte Fehler von Bedienungsunsicherheit.
• Anerkennung der Mehrbelastung. Die Rolle bedeutet über Monate zusätzliche Arbeit. Wird sie weder in der Zielvereinbarung noch in der Arbeitsverteilung berücksichtigt, entsteht Frustration bei denjenigen, die das Projekt am dringendsten braucht.

Datenmigration als organisatorische Aufgabe

Die Migration wird häufig als technischer Vorgang eingeplant und erweist sich regelmäßig als der zeitkritischste Teil des Projekts. Der Grund liegt darin, dass die eigentliche Arbeit nicht im Transport der Daten besteht, sondern in Entscheidungen über deren Inhalt.

1. Bestandsaufnahme je Datenobjekt. Kunden, Lieferanten, Artikel, Stücklisten, Arbeitspläne, offene Posten. Für jedes Objekt wird Umfang, Quelle und Verantwortlicher festgelegt.
2. Abgrenzungsentscheidung. Welche Datensätze werden überhaupt übernommen? Ein Artikelstamm mit vierzigtausend Positionen, von denen dreitausend in den letzten drei Jahren bewegt wurden, gehört nicht vollständig migriert.
3. Qualitätsregeln definieren. Pflichtfelder, zulässige Wertebereiche, Dublettenkriterien. Diese Regeln entstehen fachlich, nicht technisch.
4. Bereinigung im Altsystem, nicht während der Migration. Wer Daten erst im Zielsystem korrigiert, verliert die Vergleichsbasis und kann Migrationsfehler nicht mehr von Altfehlern unterscheiden.
5. Mehrere Probeläufe. Drei Durchgänge sind ein realistischer Ansatz, der erste zur Fehlererkennung, der zweite zur Verifikation der Korrekturen, der dritte als Generalprobe unter Zeitbedingungen des Produktivstarts.
6. Abnahme durch die Fachbereiche. Nach dem letzten Probelauf prüfen die Datenverantwortlichen anhand definierter Stichproben und zeichnen die Freigabe.

Für die Aufbewahrung der Altdaten ist zusätzlich die steuerliche Perspektive zu berücksichtigen. Aufzeichnungs- und Aufbewahrungspflichten nach Paragraf 147 Abgabenordnung verlangen, dass steuerrelevante Daten über die gesamte Frist maschinell auswertbar bleiben. Wird das Altsystem abgeschaltet, ist eine revisionssichere Archivierungslösung erforderlich. Die einschlägigen Vorschriften sind auf gesetze-im-internet.de nachlesbar.

Kommunikation über den Projektverlauf

Die Kommunikationsarbeit folgt dem Projektverlauf und verändert ihren Charakter mit jeder Phase. In der Vorbereitungsphase geht es um Einordnung: Warum wird das Vorhaben angestoßen, welche konkreten Probleme sollen verschwinden, welche Erwartungen sind unrealistisch. Gerade der letzte Punkt wird häufig ausgespart, obwohl er später den größten Enttäuschungsdruck erzeugt.

In der Konfigurationsphase steht die Beteiligung im Vordergrund. Beschäftigte, die in Workshops erlebt haben, dass ihre Einwände dokumentiert und beantwortet wurden, tragen die Entscheidung auch dann mit, wenn sie anders ausfällt als gewünscht. Entscheidend ist die Rückmeldung, nicht die Zustimmung.

In der Phase kurz vor dem Produktivstart verschiebt sich der Schwerpunkt auf Handlungssicherheit. Beschäftigte wollen wissen, was am ersten Arbeitstag konkret anders sein wird, wen sie bei Problemen erreichen und welche Aufgaben in den ersten Wochen zurückgestellt werden dürfen. Eine ausdrückliche Ansage der Geschäftsführung, dass in den ersten vier Wochen mit reduzierter Durchsatzleistung gerechnet wird, entlastet spürbar und verhindert, dass Beschäftigte Bedienungsprobleme verschweigen.

Umgang mit Widerstand und typischen Konfliktlinien

Widerstand in ERP-Projekten äußert sich selten als offene Ablehnung. Er zeigt sich in verschobenen Terminen, in Rückfragen, die bereits beantwortet wurden, und in der beharrlichen Weiterführung paralleler Nebenlisten. Diese Formen sind schwerer zu adressieren als eine ausgesprochene Kritik, weil sie sich nicht diskutieren lassen.

Hilfreich ist die Unterscheidung dreier Ursachen. Die erste ist Kompetenzsorge: Beschäftigte, deren Erfahrungsvorsprung an das Altsystem gebunden war, befürchten einen Statusverlust. Wirksam ist hier eine frühe und sichtbare Rolle im Projekt, etwa als Key User oder als Verantwortlicher für ein Datenobjekt. Die zweite Ursache ist Mehrarbeitsangst, häufig begründet, weil integrierte Systeme Erfassungsaufwand an die Stelle verlagern, an der die Information entsteht. Hier hilft nur Ehrlichkeit über den Aufwand, verbunden mit dem Nachweis, wo an anderer Stelle Doppelarbeit entfällt. Die dritte Ursache ist Vertrauensverlust aus früheren Projekten. Wo eine vorangegangene Einführung ohne Nachbetreuung abgebrochen wurde, wirkt dieses Erlebnis über Jahre nach und lässt sich nur durch verlässliches Verhalten im laufenden Vorhaben abbauen.

Eine häufige Konfliktlinie verläuft zwischen Vertrieb und Fertigung, weil integrierte Systeme Zusagen an Termin- und Kapazitätsdaten binden, die zuvor informell gehandhabt wurden. Diese Auseinandersetzung ist kein Projektproblem, sondern eine unternehmerische Grundsatzfrage, die im Projekt lediglich sichtbar wird. Sie gehört ausdrücklich auf die Ebene der Geschäftsführung und darf nicht in der Konfiguration verhandelt werden.

Fortschritt messbar machen

Change-Arbeit gilt als schwer messbar, was häufig als Begründung dient, sie gar nicht zu steuern. Tatsächlich lassen sich einige belastbare Indikatoren mit geringem Aufwand erheben.

Indikator	Erhebung	Aussagekraft
Anteil offener Prozessentscheidungen	Entscheidungsliste, wöchentlich	Frühindikator für Terminverzug
Testabdeckung je Hauptprozess	Testfallverwaltung	Reifegrad der Konfiguration
Fehlerquote der Migrationsläufe	Abgleichprotokoll je Datenobjekt	Belastbarkeit der Datenbasis
Schulungsteilnahme und Wissensabfrage	Teilnahmeliste, kurzer Test	Vorbereitungsgrad der Anwender
Ticketaufkommen nach dem Start	Servicedesk, wöchentlich	Trennung von Systemfehlern und Bedienungsunsicherheit

Aufschlussreich ist besonders die Entwicklung des Ticketaufkommens in den ersten acht Wochen. Ein hoher Anfangswert mit deutlichem Rückgang ist normal. Bleibt das Niveau stabil, deutet das auf unzureichende Schulung oder auf einen Prozess hin, der in der Praxis anders funktioniert als konfiguriert.

Häufige Fehler und wie sie vermieden werden

• Projektleitung aus der IT ohne fachliche Autorität. Prozessentscheidungen erfordern Durchsetzungsfähigkeit gegenüber Bereichsleitungen. Eine rein technische Besetzung überfordert die Rolle.
• Termindruck durch ein politisch gesetztes Startdatum. Wird der Produktivstart auf einen Termin fixiert, bevor Umfang und Datenlage bekannt sind, wird regelmäßig an Test und Schulung gespart, also an genau den Bestandteilen mit der größten Wirkung auf die Akzeptanz.
• Schulung als Systemeinweisung statt als Prozessschulung. Beschäftigte müssen nicht lernen, welche Schaltfläche wo liegt, sondern wie ihr Arbeitsablauf künftig aussieht. Schulungsunterlagen sollten deshalb an Prozessen entlang aufgebaut sein, nicht an Menüpunkten.
• Fehlende Entscheidung über Schattensysteme. Wenn nicht ausdrücklich geregelt wird, welche Tabellenkalkulationen abgeschaltet werden, laufen sie parallel weiter und untergraben die Datenintegrität des neuen Systems.
• Kein definiertes Ende der Hochlaufphase. Ohne festgelegten Zeitpunkt, ab dem der Regelbetrieb gilt, bleibt das Projekt organisatorisch unabgeschlossen und die Sonderrollen binden dauerhaft Kapazität.

Realistische Aufwandsplanung

Für die Veränderungsarbeit ist ein eigenes Budget einzuplanen, das getrennt vom Implementierungsaufwand geführt wird. In mittelständischen Projekten liegt der interne Aufwand für Prozessarbeit, Datenbereinigung, Test und Schulung erfahrungsgemäß in derselben Größenordnung wie das externe Beratungsvolumen, teilweise darüber. Wer diesen Anteil nicht in der Kapazitätsplanung abbildet, finanziert ihn faktisch über Überstunden und liegengebliebenes Tagesgeschäft.

Sinnvoll ist zudem eine bewusste Entscheidung über den Zeitpunkt des Produktivstarts im Geschäftsjahr. Ein Start zu Beginn eines Geschäftsjahres vereinfacht die buchhalterische Abgrenzung erheblich, kollidiert aber in vielen Branchen mit saisonalen Spitzen. Die Abwägung zwischen buchhalterischer Sauberkeit und operativer Belastbarkeit gehört auf die Leitungsebene und sollte dokumentiert werden, weil sie im Projektverlauf regelmäßig hinterfragt wird.

Ebenso wichtig ist eine bewusste Entscheidung über den Umgang mit Anforderungen, die während des Projekts zusätzlich aufkommen. Ohne definierten Änderungsprozess mit Bewertung von Aufwand, Terminwirkung und fachlicher Notwendigkeit wächst der Umfang schleichend, ohne dass dies an einer Stelle sichtbar wird. Ein einfaches Verfahren mit schriftlichem Antrag, Bewertung durch die Projektleitung und Entscheidung durch den Auftraggeber genügt und schützt zugleich die Beteiligten vor der Erwartung, jeden Wunsch unmittelbar umsetzen zu müssen.

FAQ

Wer sollte ein ERP-Projekt im Mittelstand leiten?
Eine Führungskraft mit fachlicher Autorität und Prozessverständnis, nicht zwingend jemand aus der IT. Entscheidend ist die Fähigkeit, Prozessentscheidungen gegenüber Bereichsleitungen durchzusetzen und offene Punkte zügig zu klären.

Wie viele Key User werden benötigt?
Als Orientierung dient ein Key User je Hauptprozess und je Standort, bei größeren Abteilungen zusätzlich ein Stellvertreter. Wichtiger als die Anzahl ist die tatsächliche Freistellung von einem Teil des Tagesgeschäfts.

Sollte das System an bestehende Abläufe angepasst werden?
Nur dort, wo der Ablauf einen belegbaren Wettbewerbsvorteil trägt. Anpassungen erzeugen bei jedem Versionswechsel erneut Aufwand und sollten deshalb über die gesamte Nutzungsdauer bewertet werden, nicht über die Programmierkosten.

Wann beginnt die Datenbereinigung?
So früh wie möglich, idealerweise parallel zur Systemauswahl. Die Bereinigung erfolgt im Altsystem, weil nur so eine Vergleichsbasis erhalten bleibt und Migrationsfehler von Altfehlern unterschieden werden können.

Wie lange dauert die Hochlaufphase nach dem Produktivstart?
In der Praxis sind acht bis zwölf Wochen mit erhöhtem Betreuungsbedarf üblich. Wichtig ist ein definierter Endzeitpunkt, ab dem der Regelbetrieb gilt und die Sonderrollen aufgelöst werden.

Was passiert mit den Daten des Altsystems?
Steuerrelevante Daten müssen über die gesamte Aufbewahrungsfrist maschinell auswertbar bleiben. Wird das Altsystem abgeschaltet, ist eine revisionssichere Archivierung erforderlich, deren Einrichtung frühzeitig eingeplant werden sollte.