ERP Einführung: Projektplan, Zeitplan & Meilensteine (Phasenmodell)

Laut Studien von Gartner und Panorama Consulting verfehlen zwischen 55 und 75 Prozent aller ERP-Projekte ihre ursprünglichen Ziele – sei es beim Budget, beim Zeitplan oder bei der tatsächlich erreichten Funktionalität. Im Mittelstand liegt die Ursache fast nie an der Software selbst. Es sind strukturelle Fehler in der Projektanlage, die sich über Monate aufschaukeln und irgendwann nicht mehr korrigierbar sind.

Der häufigste Fehler ist ein unklarer Scope. Wenn in Phase 1 gleichzeitig Order-to-Cash, Purchase-to-Pay, Lagerverwaltung, Finanzbuchhaltung, Controlling, HR und eine E-Commerce-Integration umgesetzt werden sollen, entsteht ein Projektumfang, der weder zeitlich noch personell realistisch ist. Im Mittelstand fehlen in der Regel die internen Ressourcen, um ein solches Mammutprojekt parallel zum Tagesgeschäft zu stemmen. Die Folge: Das Projekt wird ausgedünnt, Abstriche passieren ad hoc statt strategisch, und am Ende ist niemand zufrieden.

Der zweite systemische Fehler betrifft die Datenmigration. In vielen Unternehmen liegen Stammdaten verteilt über Excel-Listen, Altsysteme und Insellösungen. Die Migration wird oft als „technische Aufgabe" verstanden und erst spät adressiert. In der Realität ist Datenmigration jedoch ein fachliches Thema: Welche Daten sind überhaupt noch aktuell? Wie werden Duplikate bereinigt? Wer definiert die Datenhoheit im neuen System? Ohne Antworten auf diese Fragen wird das neue ERP-System mit denselben Altlasten befüllt, die das alte System ineffizient gemacht haben.

Drittens wird Change Management systematisch unterschätzt. Ein neues ERP verändert Arbeitsabläufe, Zuständigkeiten und Gewohnheiten. Wenn Mitarbeitende erst am Tag des Go-Live erfahren, dass sich ihr Tagesablauf ändert, entsteht Widerstand. Key-User-Programme, rollenbasierte Schulungen und transparente Kommunikation ab Projektstart sind keine „Soft Skills" – sie sind erfolgskritische Arbeitspakete, die im Projektplan mit Aufwänden und Verantwortlichkeiten hinterlegt werden müssen.

Die Frage „Standard oder Customizing?" durchzieht jede ERP-Einführung. Die Antwort bestimmt nicht nur den Projektumfang, sondern auch die langfristigen Betriebskosten. Fit-to-Standard bedeutet: Das Unternehmen passt seine Prozesse an die Best Practices des ERP-Systems an, anstatt das System an jeden bestehenden Prozess anzupassen.

Im Mittelstand gibt es fast immer Prozesse, die historisch gewachsen und nie hinterfragt worden sind. Ein typisches Beispiel: Ein Unternehmen hat drei verschiedene Freigabeprozesse für Bestellungen – je nach Standort. Im Altsystem wurde das durch individuelle Workflows abgebildet. Die Versuchung bei der ERP-Einführung ist groß, diese drei Varianten auch im neuen System per Customizing abzubilden. Der Fit-to-Standard-Ansatz fragt stattdessen: Brauchen wir wirklich drei Varianten? Oder können wir uns auf einen einheitlichen Prozess einigen, der für alle Standorte funktioniert?

Die Faustformel lautet: 80 Prozent Standard, 20 Prozent bewusste Gaps. Die 20 Prozent sind Prozesse, die ein echtes Differenzierungsmerkmal darstellen oder regulatorisch erforderlich sind. Diese Gaps werden dokumentiert, priorisiert und entweder als Konfiguration (nicht Customizing) gelöst oder als bewusste „Phase 2"-Themen auf die Roadmap gesetzt.

Jede Customizing-Entscheidung hat Folgekosten: Upgrades werden komplex, weil angepasste Module separat getestet und nachgezogen werden müssen. Support-Tickets landen beim internen Team statt beim Hersteller. Und bei einem späteren Systemwechsel ist der Migrationsaufwand deutlich höher. Ein Fit-to-Standard-Ansatz reduziert diese technische Schuld systematisch.

Datenmigration ist in der Regel der am meisten unterschätzte Arbeitsblock einer ERP-Einführung. Die technische Übertragung von Daten aus dem Altsystem ins neue System ist vergleichsweise trivial – die fachliche Aufarbeitung der Daten ist das eigentliche Problem.

Ein bewährter Ansatz ist die iterative Migration in drei Zyklen: In Zyklus 1 (v1) werden Struktur und Mapping definiert – welche Felder des Altsystems entsprechen welchen Feldern im neuen System? In Zyklus 2 (v2) werden die Daten bereinigt: Duplikate zusammengeführt, veraltete Datensätze archiviert, fehlende Pflichtfelder ergänzt. In Zyklus 3 (v3) findet die finale Migration unter realen Bedingungen statt, inklusive Zeitfenster-Messung und Validierung.

Dieser iterative Ansatz hat zwei entscheidende Vorteile: Erstens werden Probleme früh sichtbar – nicht erst am Cutover-Wochenende, wenn der Zeitdruck maximal ist. Zweitens zwingt er das Projektteam, Datenqualität als fachliche Aufgabe zu behandeln. Die Frage „Sind unsere Kundenstammdaten vollständig und korrekt?" kann kein IT-Abteilung beantworten – das muss der Vertrieb oder das Auftragsmanagement tun.

Praxis-Tipp: Plane für die Datenmigration 20 bis 30 Prozent des gesamten Projektbudgets ein. In jedem zweiten Projekt, das ich begleite, wird dieser Anteil unterschätzt – mit direkten Auswirkungen auf den Go-Live-Termin.

Die meisten Projektpläne enden beim Go-Live. Das ist ein Fehler. Ein ERP-System ist keine Einmalprojektleistung, sondern eine Betriebsplattform, die über Jahre funktionieren, gewartet und weiterentwickelt werden muss. Das Operating Model beschreibt, wie das System nach dem Go-Live betrieben wird – und sollte spätestens in Phase 2 (Build) definiert werden.

Ein Operating Model umfasst vier Dimensionen: Rollen (Wer ist für Administration, Releases, Support zuständig?), Prozesse (Wie werden Changes, Incidents und Optimierungen gehandhabt?), Monitoring (Welche KPIs werden gemessen? Wie werden Integrationsfehler erkannt?) und Weiterentwicklung (Wie sieht die Roadmap für Phase 2/v2 aus?).

Ohne Operating Model entstehen typische Post-Go-Live-Probleme: Niemand fühlt sich für das System verantwortlich, Änderungen werden ad hoc durchgeführt, und nach sechs Monaten ist das System genauso fragmentiert wie das Altsystem. Besonders im Mittelstand, wo es selten ein dediziertes ERP-Team gibt, muss die Betriebsverantwortung klar zugeordnet und mit Kapazitäten hinterlegt werden.

Die Hypercare-Phase nach dem Go-Live dauert typischerweise 4 bis 8 Wochen. In dieser Zeit sollte das Projektteam noch aktiv sein, ein erhöhtes Support-Level bereitstehen und ein klarer Eskalationspfad definiert sein. Das ist keine „Nachspielzeit" – es ist ein geplanter Projektbestandteil mit eigenem Budget und eigenen Erfolgskriterien.