Der Begriff „Implementierung“ wird in der Praxis oft auf das technische Aufsetzen der Software verengt. Tatsächlich umfasst eine ERP-Implementierung deutlich mehr: die Aufnahme und Neugestaltung der Geschäftsprozesse, die Konfiguration und gegebenenfalls Erweiterung des Systems, die Migration von Stammdaten und Bewegungsdaten aus den Altsystemen, das Testen, die Schulung der Mitarbeitenden und schließlich die produktive Inbetriebnahme samt Stabilisierung. Die Software ist dabei nur das Werkzeug – das eigentliche Projekt ist die Veränderung der Arbeitsweise.
Genau hier liegt der Grund, warum ERP-Projekte als anspruchsvoll gelten. Sie berühren nahezu jeden Bereich des Unternehmens, sie machen bestehende Prozesse sichtbar und oft schmerzhaft transparent, und sie verlangen Entscheidungen, die jahrelang Bestand haben. Eine ERP-Implementierung ist deshalb immer auch ein Organisationsentwicklungsprojekt.
Studien und Marktbeobachtungen zeichnen seit Jahren ein ernüchterndes Bild: Ein erheblicher Anteil der ERP-Projekte überschreitet Budget oder Zeitplan, bleibt hinter den erwarteten Nutzenzielen zurück oder wird sogar abgebrochen. Die Ursachen sind dabei selten technischer Natur. In den allermeisten Fällen scheitern Projekte an unklaren Zielen, an einer zu späten Einbindung der Fachbereiche, an schlechter Datenqualität oder an einem unterschätzten Change-Aufwand.
Das Risiko ist also gestaltbar. Wer die typischen Stolpersteine kennt und ein methodisch sauberes Vorgehen wählt, kann die Erfolgswahrscheinlichkeit deutlich erhöhen. Nicht das ERP-Produkt entscheidet primär über Erfolg oder Misserfolg, sondern die Qualität des Projekts. Diese Erkenntnis ist die Leitlinie dieses gesamten Leitfadens.
In der Praxis treten drei verwandte Vorhaben auf, die nicht verwechselt werden sollten. Die Neueinführung bringt ein ERP-System in ein Unternehmen, das bisher mit Insellösungen, Tabellenkalkulationen oder einer veralteten Software arbeitet. Die Migration – etwa der Wechsel von einer Altversion auf einen Nachfolger oder von On-Premises in die Cloud – setzt auf vorhandene Strukturen auf und ist häufig technisch geprägt. Die Prozessoptimierung schließlich verbessert ein bereits laufendes System, ohne es zu ersetzen.
Dieser Leitfaden konzentriert sich auf die Neueinführung, weil sie die umfassendste und anspruchsvollste Variante ist. Die meisten Prinzipien – Phasenmodell, Datenqualität, Change Management – gelten jedoch sinngemäß auch für Migrationsprojekte.
Unabhängig vom gewählten Vorgehensmodell – klassisch, agil oder hybrid – durchläuft praktisch jedes ERP-Projekt dieselben sechs Grundphasen: Analyse, Konzept, Customizing, Test, Go-Live und Hypercare. Sie unterscheiden sich nur darin, ob diese Phasen einmalig und sequenziell oder iterativ in mehreren Schleifen durchlaufen werden.
Die ersten beiden Phasen entscheiden über den Verlauf des gesamten Projekts. In der Analyse wird aufgenommen, wie das Unternehmen heute arbeitet – nicht idealisiert, sondern realistisch, inklusive der informellen Workarounds und der „Schatten-IT“ in Form von Tabellen und E-Mail-Listen. Diese ehrliche Bestandsaufnahme ist unbequem, aber unverzichtbar: Nur wer den Ist-Zustand kennt, kann den Soll-Zustand sinnvoll gestalten.
Im Konzept wird daraus die Zukunft entworfen. Die zentrale Frage lautet: Wie sollen die Prozesse im neuen System ablaufen? An dieser Stelle treffen Unternehmen die folgenreichste Entscheidung des gesamten Projekts – nämlich ob sie ihre Prozesse an den Standard des ERP-Systems anpassen oder das System an ihre Prozesse. Dieser Konflikt zieht sich durch das gesamte Vorhaben und wird in Kapitel 05 ausführlich behandelt.
Tests werden in vielen Projekten chronisch unterschätzt. Sie gelten als langweilig, sie binden Fachkräfte, und sie kommen am Ende, wenn der Zeitdruck am höchsten ist. Genau deshalb ist die Versuchung groß, sie abzukürzen – mit fatalen Folgen. Ein ungetesteter Prozess, der erst im Produktivbetrieb auffällt, kostet ein Vielfaches dessen, was ein früher Test gekostet hätte. Erfolgreiche Projekte reservieren ausreichend Zeit für mehrere Testzyklen und binden die Fachbereiche systematisch ein.
Der Go-Live selbst ist weniger ein Knopfdruck als eine choreografierte Operation. Ein detaillierter Cutover-Plan legt minutengenau fest, wer wann was tut: Wann werden die Altsysteme eingefroren, wann läuft die finale Datenmigration, wann erfolgt die Freigabe, und ab wann darf produktiv gebucht werden. Genauso wichtig ist der Plan B: Was passiert, wenn etwas schiefgeht? Ein definierter Rückfall-Punkt nimmt dem Team den Druck und schützt das Geschäft.
Zusätzlich zur Frage des Roll-out-Stils stellt sich die Frage des Projektstils: klassisch-sequenziell, agil-iterativ oder hybrid. Diese beiden Achsen sind unabhängig voneinander, werden in der Praxis aber oft vermengt. Klarheit darüber, welchen Weg man geht, ist eine wichtige Voraussetzung für eine realistische Planung.
Beim Big-Bang-Ansatz wird das alte System zu einem Stichtag abgeschaltet und das neue System für alle Bereiche, Standorte und Module gleichzeitig produktiv gesetzt. Der Reiz liegt in der Eindeutigkeit: Es gibt einen klaren Schnitt, keine langen Parallelbetriebe mit doppelter Datenpflege und keine Übergangslösungen für Schnittstellen zwischen Alt und Neu. Die Gesamtprojektdauer ist tendenziell kürzer.
Der Preis dafür ist ein konzentriertes Risiko. Wenn etwas schiefgeht, betrifft es das gesamte Unternehmen auf einmal. Der Go-Live-Tag erfordert höchste Vorbereitung, der Cutover ist komplex, und die Belastung des Teams ist enorm. Big Bang eignet sich daher eher für kleinere bis mittlere Unternehmen mit überschaubarer Komplexität, für einzelne Standorte oder für Konstellationen, in denen ein Parallelbetrieb technisch oder organisatorisch nicht sinnvoll möglich ist.
Beim phasenweisen Rollout wird das System in Etappen eingeführt – zum Beispiel nach Standorten, nach Gesellschaften, nach Modulen oder nach Geschäftsbereichen. Der erste Bereich dient als Pilot, aus dem gelernt wird, bevor die nächsten folgen. Das Risiko verteilt sich, Fehler bleiben lokal begrenzt, und das Team gewinnt mit jeder Welle an Routine.
Die Kehrseite: Das Projekt dauert insgesamt länger, und während der Übergangszeit müssen Alt- und Neusystem koexistieren. Das bedeutet temporäre Schnittstellen, doppelte Datenpflege an den Übergabepunkten und eine längere Phase der Unsicherheit. Der schrittweise Rollout ist besonders geeignet für größere Unternehmen, für mehrere Standorte oder Landesgesellschaften und für Projekte mit hoher Prozesskomplexität, bei denen ein Big Bang ein untragbares Risiko darstellen würde.
Unabhängig vom Roll-out-Stil stellt sich die Frage nach dem Projektstil. Das klassische, sequenzielle Vorgehen (oft als Wasserfall bezeichnet) plant von Anfang bis Ende durch und arbeitet die Phasen nacheinander ab. Es bietet Planungssicherheit und klare Meilensteine, reagiert aber träge auf Änderungen und birgt das Risiko, dass Fehler im Konzept erst spät auffallen.
Das agile Vorgehen arbeitet iterativ: Das System wird in kurzen Zyklen aufgebaut, früh getestet und laufend angepasst. Fachbereiche sehen schnell funktionierende Teile und können Feedback geben, bevor zu viel festgelegt ist. Der Preis ist eine geringere Vorab-Planbarkeit von Budget und Termin, was im klassischen Festpreis-Denken vieler Mittelständler auf Skepsis stößt.
In der Praxis hat sich für ERP-Projekte häufig ein hybrides Vorgehen bewährt: ein klassisch geplanter Gesamtrahmen mit Meilensteinen und Budget, innerhalb dessen die Konzeptions- und Realisierungsarbeit in iterativen Schleifen erfolgt. So verbindet man Planungssicherheit nach außen mit Flexibilität nach innen.
Beim Übergang ins neue System müssen Daten aus den Altsystemen übernommen werden – Stammdaten wie Artikel, Kunden, Lieferanten und Stücklisten ebenso wie Bewegungsdaten wie offene Posten, Bestände und laufende Aufträge. Was banal klingt, entpuppt sich in der Praxis als Mammutaufgabe, weil die Altdaten über Jahre gewachsen, oft inkonsistent, unvollständig und mit Dubletten durchsetzt sind.
Die Qualität der Stammdaten ist das Fundament, auf dem das gesamte ERP-System steht. Ein falsch gepflegter Artikelstamm führt zu falschen Beständen, fehlerhaften Bestellvorschlägen und falschen Preisen. Doppelte Kundenstammsätze verzerren Auswertungen und führen zu Fehlern in der Fakturierung. Unvollständige Stücklisten machen die Produktionsplanung unmöglich. Die Liste lässt sich beliebig fortsetzen – und jeder dieser Fehler wird im neuen System sichtbar und wirksam.
Das Tückische daran: Schlechte Datenqualität fällt im Altsystem oft gar nicht auf, weil erfahrene Mitarbeitende die Fehler im Kopf korrigieren oder über Workarounds umgehen. Das neue System kennt diese stillen Korrekturen nicht. Es nimmt die Daten so, wie sie sind – und macht damit jahrelang angesammelte Datenschuld auf einen Schlag transparent. Deshalb gilt: Die Datenbereinigung muss vor der Migration erfolgen, nicht danach.
Ein sauberer Migrationsprozess folgt einer klaren Logik. Zunächst werden alle Datenquellen identifiziert und bewertet: Welche Daten gibt es, wo liegen sie, wie aktuell und wie verlässlich sind sie? Anschließend wird entschieden, was überhaupt migriert wird – nicht alle Altdaten gehören ins neue System. Historische Daten lassen sich oft archivieren statt migrieren, was Aufwand spart und das neue System schlank hält.
Es folgt die eigentliche Aufbereitung: Bereinigung von Dubletten, Vervollständigung fehlender Pflichtfelder, Vereinheitlichung von Schreibweisen und das Mapping der alten auf die neuen Datenstrukturen. Dann wird die Migration mehrfach in Testläufen geprobt, jedes Mal mit Plausibilitätskontrollen und Abgleich gegen das Altsystem. Erst wenn mehrere Probeläufe sauber durchlaufen, erfolgt die finale Migration im Rahmen des Cutovers.
Die Migration ist ein einmaliges Ereignis – die Datenqualität ist eine Daueraufgabe. Wer nach dem Go-Live keine klaren Regeln für die Pflege der Stammdaten etabliert, verliert die mühsam erarbeitete Qualität innerhalb weniger Monate wieder. Erfolgreiche Unternehmen definieren deshalb frühzeitig eine Data Governance: Wer darf welche Stammdaten anlegen und ändern, welche Pflichtfelder gelten, welche Namenskonventionen sind verbindlich. So wird aus dem einmaligen Bereinigungsprojekt eine nachhaltige Datenkultur.
Jedes moderne ERP-System bringt umfangreiche vorkonfigurierte Prozesse mit, die sogenannten Standardprozesse oder Best Practices. Diese bilden bewährte Abläufe ab, die in tausenden Unternehmen erprobt wurden. Demgegenüber steht der Wunsch, das System an die individuellen Besonderheiten des eigenen Unternehmens anzupassen – durch Konfiguration, durch Erweiterungen oder durch echte Programmierung.
Wichtig ist zunächst eine begriffliche Unterscheidung, denn nicht jede Anpassung ist gleich riskant. Die Konfiguration nutzt die vom Hersteller vorgesehenen Einstellmöglichkeiten – sie ist unkritisch und gehört zu jedem Projekt. Die Erweiterung ergänzt das System über definierte Schnittstellen, ohne den Kern zu verändern; moderne Systeme sind darauf ausgelegt und bleiben dabei update-fähig. Die Modifikation hingegen greift in den Standardcode ein – sie ist die gefährlichste Form der Anpassung, weil sie die Update-Fähigkeit gefährdet.
Der entscheidende Grundsatz lautet: Konfiguration vor Erweiterung, Erweiterung vor Modifikation. Je tiefer der Eingriff, desto höher die Kosten heute und vor allem morgen.
Die Versuchung zur Überanpassung ist groß. Mitarbeitende wünschen sich das System genau so, wie sie es gewohnt sind. Fachbereiche bestehen auf „unseren Besonderheiten“. Und in fast jedem Workshop fällt der Satz: „Das haben wir aber schon immer so gemacht.“ Wer jedem dieser Wünsche nachgibt, baut Stück für Stück ein hochindividuelles System, das teuer in der Erstellung, fehleranfällig im Betrieb und kaum noch update-fähig ist.
Die Folgen einer Überanpassung wirken jahrelang nach. Jedes Update wird zum Risiko, weil die Modifikationen angepasst und neu getestet werden müssen. Die Wartung wird teuer und schafft Abhängigkeit von wenigen Spezialisten. Der eigentliche Vorteil eines Standardsystems – kontinuierliche Weiterentwicklung durch den Hersteller – geht verloren. Überanpassung ist deshalb einer der häufigsten Gründe, warum ERP-Systeme nach wenigen Jahren als „veraltet“ wahrgenommen werden, obwohl der Hersteller längst neue Funktionen liefert.
Eine bewährte Orientierung ist die 80/20-Regel: Rund 80 Prozent der Prozesse sollten im Standard abgebildet werden, maximal 20 Prozent rechtfertigen eine Anpassung – und auch diese nur nach kritischer Prüfung. Der wichtigste Hebel ist dabei nicht die Technik, sondern die Haltung. Bei jeder Anpassungsanforderung sollte gefragt werden: Ist dieser Prozess wirklich ein Alleinstellungsmerkmal, oder ist er nur historisch gewachsen? In der überwiegenden Zahl der Fälle ist die ehrliche Antwort: Wir können uns anpassen.
Der bewusste Verzicht auf eine Anpassung ist oft die bessere unternehmerische Entscheidung. Wer seine Prozesse an einen bewährten Standard angleicht, gewinnt nicht nur ein günstigeres und stabileres System, sondern häufig auch effizientere Abläufe – denn die Best Practices des ERP-Anbieters sind selten zufällig entstanden.
Eine ERP-Einführung verändert die tägliche Arbeit fast aller Mitarbeitenden. Gewohnte Abläufe ändern sich, vertraute Masken verschwinden, neue Pflichten entstehen. Solche Veränderungen lösen bei Menschen zuverlässig Unsicherheit, manchmal Widerstand aus. Wer das ignoriert und davon ausgeht, dass die Mitarbeitenden das neue System schon irgendwie annehmen werden, riskiert die Akzeptanz – und damit den gesamten Projekterfolg.
Das zentrale Instrument erfolgreicher ERP-Projekte sind die Key User – ausgewählte Mitarbeitende aus den Fachbereichen, die im Projekt eine Schlüsselrolle einnehmen. Sie bringen das fachliche Prozesswissen ein, testen das System aus Anwendersicht, schulen ihre Kolleginnen und Kollegen und sind im Alltag die erste Anlaufstelle bei Fragen. Key User sind die Brücke zwischen Projekt und Belegschaft.
Die Auswahl der Key User entscheidet mit über den Erfolg. Gute Key User sind nicht zwingend die IT-affinsten, sondern die fachlich anerkannten und kommunikativ starken Mitarbeitenden, denen die Kollegen vertrauen. Entscheidend ist außerdem, dass sie für ihre Projektrolle echte Zeit bekommen – ein Key User, der die Projektarbeit zusätzlich zum vollen Tagesgeschäft erledigen soll, ist zum Scheitern verurteilt. Die Freistellung der Key User ist eine Investition, kein Kostenfaktor.
Klassische Schulungen konzentrieren sich auf die Bedienung: Wo klicke ich, welches Feld fülle ich aus. Das ist notwendig, aber nicht hinreichend. Mindestens ebenso wichtig ist die Vermittlung des Warum: Warum ändert sich der Prozess, welchen Nutzen bringt das neue System, wie hängt die eigene Tätigkeit mit dem Gesamtbild zusammen. Mitarbeitende, die den Sinn verstehen, machen Fehler seltener und tragen die Veränderung mit, statt sie zu unterlaufen.
Bewährt haben sich praxisnahe Schulungen anhand realer Arbeitssituationen statt abstrakter Klickanleitungen, gestaffelt nach Rollen und mit ausreichend Übungszeit am System. Genauso wichtig wie die Schulung vor dem Go-Live ist die kontinuierliche Begleitung danach: Anlaufstellen, kurze Auffrischungen und ein lebendiges Wissensangebot. Schulung ist kein einmaliges Ereignis, sondern ein fortlaufender Prozess.
Widerstand gegen Veränderung ist normal und kein Zeichen von Böswilligkeit. Hinter Skepsis stecken meist nachvollziehbare Sorgen: Angst vor Überforderung, Sorge um den Arbeitsplatz, schlechte Erfahrungen mit früheren Projekten oder schlicht die Last des zusätzlichen Lernaufwands. Erfolgreiches Change Management nimmt diese Sorgen ernst, statt sie wegzudiskutieren. Wer die Gründe für Widerstand versteht, kann gezielt gegensteuern – durch Information, durch Beteiligung und durch sichtbare frühe Erfolge.
In ERP-Projekten kommen unterschiedliche Akteure zusammen, die jeweils eine spezifische Rolle und Verantwortung tragen. Werden diese Rollen nicht klar definiert, entstehen Lücken und Überschneidungen: Entscheidungen bleiben liegen, weil sich niemand zuständig fühlt, oder mehrere Beteiligte ziehen in unterschiedliche Richtungen. Eine saubere Rollenklärung zu Projektbeginn beugt diesen Problemen vor.
Auf Unternehmensseite sind mehrere Rollen zentral. Der Projekt-Sponsor, meist aus der Geschäftsführung, trägt die Gesamtverantwortung, sichert Ressourcen und trifft die strategischen Entscheidungen. Die Projektleitung steuert das Projekt operativ, koordiniert die Beteiligten und behält Zeit, Budget und Qualität im Blick. Die Key User bringen das fachliche Wissen ein und sind die Schnittstelle zur Belegschaft. Die IT verantwortet Infrastruktur, Schnittstellen und technischen Betrieb. Und die Endanwender schließlich sind diejenigen, für die das System letztlich gebaut wird.
Besonders kritisch ist die Rolle der internen Projektleitung. Sie sollte mit ausreichend Zeit, Kompetenz und Mandat ausgestattet sein. Ein Projektleiter, der das ERP-Projekt nebenbei zum Tagesgeschäft führen soll, ist eine der häufigsten Ursachen für scheiternde Projekte. Die Projektleitung ist eine Vollzeitaufgabe – zumindest in den intensiven Projektphasen.
Die wenigsten Mittelständler verfügen über die Erfahrung, ein ERP-Projekt allein zu stemmen. Der Implementierungspartner – sei es der Softwarehersteller selbst, ein zertifizierter Vertriebspartner oder ein unabhängiges Beratungshaus – bringt Produktwissen, Methodenkompetenz und die Erfahrung aus zahlreichen vergleichbaren Projekten mit. Ein guter Partner kennt die typischen Fallstricke, bevor das Unternehmen in sie hineinläuft.
Entscheidend ist jedoch das richtige Verständnis dieser Zusammenarbeit: Der Partner unterstützt und befähigt, aber er trägt nicht die Verantwortung für den Projekterfolg. Diese liegt immer beim Unternehmen selbst. Wer glaubt, das Projekt vollständig an einen Dienstleister delegieren zu können und sich selbst herauszuhalten, wird enttäuscht. Die besten Ergebnisse entstehen in einer echten Partnerschaft, in der internes Fachwissen und externe Erfahrung zusammenkommen.
Bei der Auswahl des Partners zählt mehr als der Preis. Wichtig sind nachweisbare Erfahrung in der eigenen Branche und Unternehmensgröße, eine überzeugende Methodik, die Qualität und Verfügbarkeit der konkret eingesetzten Berater sowie die persönliche Chemie. Referenzgespräche mit vergleichbaren Kunden sind dabei aufschlussreicher als jede Hochglanzpräsentation. Da die Zusammenarbeit oft über Jahre besteht, sollte der Partner nicht nur fachlich, sondern auch menschlich passen.
Diese drei Probleme hängen eng zusammen und verstärken sich gegenseitig. Ein wachsender Projektumfang treibt den Zeitbedarf, ein gerissener Zeitplan kostet zusätzliches Geld, und Budgetdruck führt wiederum dazu, dass an den falschen Stellen gespart wird – etwa bei Tests oder Schulungen. Es entsteht eine Abwärtsspirale, die schwer zu durchbrechen ist, wenn sie einmal in Gang gekommen ist.
Scope Creep bezeichnet das schleichende Anwachsen des Projektumfangs durch viele kleine, scheinbar harmlose Zusatzwünsche. Jeder einzelne Wunsch klingt vernünftig: ein zusätzliches Feld hier, eine Sonderauswertung dort, eine kleine Anpassung an einem Prozess. In der Summe aber sprengen diese Erweiterungen den ursprünglichen Rahmen – ohne dass jemand eine bewusste Entscheidung darüber getroffen hätte.
Das Gegenmittel ist ein konsequentes Anforderungs- und Änderungsmanagement. Jede Änderung am ursprünglich vereinbarten Umfang wird dokumentiert, hinsichtlich Aufwand und Nutzen bewertet und nur nach einer expliziten Entscheidung freigegeben. Dieser geordnete Change-Request-Prozess ist keine Bürokratie, sondern der wirksamste Schutz vor dem unkontrollierten Aufblähen des Projekts. Genauso wichtig ist eine klare Definition des Projektumfangs zu Beginn – nur was klar abgegrenzt ist, kann gegen Verwässerung verteidigt werden.
Viele ERP-Projekte starten mit zu optimistischen Annahmen. Der Zeitplan ist zu eng, weil unter Vertriebsdruck oder aus Wunschdenken Puffer eingespart werden. Das Budget ist zu knapp, weil interne Aufwände – die Zeit der eigenen Mitarbeitenden, der Schulungsaufwand, die Datenbereinigung – systematisch unterschätzt werden. Wenn dann die ersten Verzögerungen auftreten, gerät das gesamte Projekt unter Druck.
Realistische Planung bedeutet, ausreichende Puffer einzuplanen, interne Aufwände ehrlich zu kalkulieren und sich nicht von künstlichen Stichtagen treiben zu lassen. Besonders die Aufwände auf Unternehmensseite werden in Angeboten häufig kleingerechnet, weil sie nicht in der Rechnung des Dienstleisters auftauchen. Sie sind aber real und oft erheblich. Wer sie ignoriert, plant ein Projekt, das von Anfang an unterfinanziert ist.
Gescheiterte Projekte kündigen sich meist an. Typische Frühwarnzeichen sind verschobene Meilensteine ohne klare Ursache, eine wachsende Liste offener Punkte, sinkende Beteiligung der Fachbereiche an Workshops, häufige Diskussionen über den Projektumfang und ein zunehmend angespanntes Verhältnis zwischen Team und Partner. Wer diese Signale ernst nimmt und früh gegensteuert – notfalls mit einem ehrlichen Projekt-Reset – kann ein Projekt oft noch retten. Wer sie ignoriert, erlebt das böse Erwachen meist kurz vor dem geplanten Go-Live.
Ein wirksames Instrument ist das regelmäßige, ehrliche Statusgespräch auf Lenkungsebene. Es lebt davon, dass Probleme offen benannt werden dürfen, ohne dass der Überbringer der schlechten Nachricht abgestraft wird. Eine Projektkultur, in der Risiken früh ausgesprochen werden, ist einer der stärksten Schutzmechanismen überhaupt.
Der Mittelstand hat im ERP-Projekt spezifische Stärken und Herausforderungen. Kurze Entscheidungswege und flache Hierarchien sind ein Vorteil, knappe Personalressourcen und fehlende Projekterfahrung eine Herausforderung. Erfolgreiche mittelständische ERP-Projekte spielen ihre Stärken aus und kompensieren ihre Schwächen durch gute Vorbereitung und die richtige externe Unterstützung.
An erster Stelle steht das sichtbare und dauerhafte Engagement der Geschäftsführung. Ein ERP-Projekt ist eine strategische Investition, die das ganze Unternehmen betrifft – entsprechend muss die Unternehmensleitung es als Chefsache behandeln. Das bedeutet weit mehr, als das Budget zu genehmigen und ein Grußwort beim Kick-off zu sprechen. Es bedeutet, regelmäßig präsent zu sein, Entscheidungen zu treffen, Ressourcen freizugeben und dem Projekt im Konflikt mit dem Tagesgeschäft den Rücken zu stärken.
Wenn die Mitarbeitenden spüren, dass die Geschäftsführung hinter dem Projekt steht, steigt die Bereitschaft, sich einzubringen und die Veränderung mitzutragen. Zieht sich die Leitung dagegen zurück, sobald der Vertrag unterschrieben ist, sinkt die Priorität im ganzen Unternehmen – mit absehbaren Folgen. Management-Buy-in ist nach übereinstimmender Erfahrung der mit Abstand wichtigste Erfolgsfaktor.
Erfolgreiche Projekte beginnen mit klaren, messbaren Zielen. Was genau soll das neue System leisten, welche Probleme soll es lösen, woran wird der Erfolg gemessen? Ohne diese Klarheit wird das Projekt zur Reise ohne Ziel, bei der jeder Beteiligte etwas anderes erwartet. Klare Ziele sind außerdem die Grundlage, um Anforderungen zu priorisieren und Scope Creep abzuwehren.
Realistische Planung ergänzt klare Ziele um ehrliche Annahmen über Zeit, Budget und interne Aufwände. Lieber ein konservativer Plan, der eingehalten wird, als ein ambitionierter Plan, der von Beginn an Makulatur ist. Gerade im Mittelstand, wo die internen Ressourcen ohnehin knapp sind, ist eine ehrliche Aufwandsschätzung überlebenswichtig.
Schließlich braucht ein ERP-Projekt realistische Erwartungen. Ein neues System ist kein Selbstläufer und kein Wundermittel. In den ersten Wochen nach dem Go-Live ist die Produktivität oft niedriger als vorher, weil die Mitarbeitenden sich umgewöhnen müssen. Das ist normal und kein Grund zur Panik. Der eigentliche Nutzen entfaltet sich über Monate und Jahre, wenn die neuen Prozesse eingespielt sind und das Unternehmen lernt, die Möglichkeiten des Systems auszuschöpfen.
Wer dies versteht, plant nicht nur die Einführung, sondern auch die Zeit danach: kontinuierliche Verbesserung, weitere Schulungen, das schrittweise Erschließen zusätzlicher Funktionen. Eine ERP-Implementierung ist kein Projekt mit Enddatum, sondern der Beginn einer langfristigen digitalen Entwicklung des Unternehmens.
