ERP-Implementierungs-Checkliste: Die ersten 90 Tage
Die ersten 90 Tage nach Vertragsunterzeichnung entscheiden über Erfolg oder Scheitern eines ERP-Projekts. Wer in dieser Phase Fundamentarbeit leistet – klare Governance, sauber aufgesetzte Datenmigration, methodisches Anforderungsmanagement und konsequentes Stakeholder-Management – legt die Basis für einen reibungsarmen Go-Live. Wer dagegen die ersten Wochen verstreichen lässt, holt das später nur unter erheblichen Mehrkosten wieder auf.
ERP-Implementierungs-Checkliste — die ersten 90 Tage strukturiert managen · Quelle: erp-software.org Redaktion
Video: Die ersten 90 Tage: Checkliste für den Start – einfach erklärt · Quelle: erp-software.org auf YouTube
Diese Checkliste strukturiert die ersten 90 Tage Ihrer ERP-Implementierung in drei Phasen zu je 30 Tagen, listet konkrete Arbeitspakete und benennt typische Verantwortlichkeiten. Sie ergänzt unseren Leitfaden ERP-Auswahl in 7 Schritten und ist auf Mittelständler und Konzerne gleichermaßen anwendbar – die Größenordnung der Aufgaben skaliert, das Vorgehen bleibt.
Tage 1–30: Projekt-Setup und Foundation
Die erste Phase legt das Fundament. Drei Bereiche müssen jetzt sauber aufgesetzt werden: Governance, Methodik und Kick-off. Vermeiden Sie den Fehler, in der Euphorie nach Vertragsabschluss direkt in die Konfiguration zu springen – ohne saubere Foundation rächt sich das später vielfach.
Governance und Projektorganisation
Lenkungskreis aufstellen mit klar benannten Mitgliedern und Tagungsturnus
Teilprojektleiter für Finance, SCM, Produktion, IT, HR benennen
RACI-Matrix erstellen und allen Stakeholdern kommunizieren
Eskalationspfade definieren – Wer entscheidet was bis zu welchem Volumen?
Projekt-Charta verabschieden und veröffentlichen
Methodik festlegen
Klären Sie die Vorgehensweise: klassisch wasserfallartig, agil-iterativ oder hybrid. Bei kleineren Mittelstandsprojekten dominiert eine schlanke Hybrid-Methode – grobes Wasserfall-Phasenmodell mit agilen Sprints in den Konfigurationsphasen. Die methodische Disziplin entscheidet später über die Reaktionsfähigkeit bei Änderungswünschen.
Tooling und Kommunikation
Projekt-Wiki und Dokumentationsplattform aufsetzen
Issue-Tracker konfigurieren (Jira, Azure DevOps oder vergleichbar)
Testmanagement-Tool auswählen und Testfallstruktur anlegen
Wöchentlichen Status-Termin etablieren
Datenmigration: Frühzeitig beginnen, nicht zum Schluss
Die Datenmigration ist der Posten, der in nahezu jedem Projekt unterschätzt wird. Sie sollten in den ersten 30 Tagen damit beginnen – nicht zwei Wochen vor dem Cutover.
Verantwortliche pro Datenobjekt benennen (Data Owner)
Bereinigungsverantwortung an die Fachbereiche übergeben
Migrationstrategie festlegen: Greenfield mit Stichtag, schrittweise oder mit Historie
Migrationsmechanik aufsetzen
Klären Sie früh, ob Migration über Standard-Importtools, ETL-Strecken oder anbieterseitige Migrationspakete erfolgt. Planen Sie mindestens drei Trockenläufe vor dem Cutover – jeweils mit Validierung durch die Fachbereiche. Die Erfahrung zeigt: Die Datenqualität ist niemals so gut, wie der Fachbereich behauptet.
Tage 31–60: Konfiguration, Customizing und Testen
In Phase zwei wird das System konfiguriert und erste Funktionsblöcke werden getestet. Halten Sie sich konsequent an den Standard – jedes Customizing sollte schriftlich begründet, geschätzt und vom Lenkungskreis genehmigt werden.
Konfiguration nach Modulen
Mandanten- und Buchungskreis-Struktur einrichten
Kontenrahmen, Steuerkennzeichen und Buchungsschlüssel konfigurieren
Workflow-Regeln und Genehmigungslogiken einrichten
Schnittstellen und Integration
Schnittstellen sind im Mittelstand oft der zeitkritischste Pfad. Die DATEV-Anbindung, die EDI-Prozesse zu Großkunden, die E-Commerce-Anbindung sowie Lohnsoftware-Schnittstellen müssen früh getestet werden. Integrationspartner mit branchenspezifischer Erfahrung sparen hier deutlich Zeit.
Testen, Testen, Testen
Testen ist keine Endphase, sondern ein begleitender Prozess. Etablieren Sie Komponententests, Integrationstests, Anwendertests und Performance-Tests. Schreiben Sie Testfälle, dokumentieren Sie Ergebnisse und tracken Sie Bugs konsequent im Issue-Tracker.
Schulung und Change-Management
Schulung und Change-Management beginnen ebenfalls in Phase zwei – nicht erst zwei Wochen vor Go-Live. Anwender müssen das neue System nicht nur bedienen, sondern auch verstehen, warum es eingeführt wird und welche Vorteile es bietet.
Schulungsplan mit konkreten Zeitfenstern erstellen
Kommunikationsplan an alle Mitarbeitenden ausrollen
Multiplikatoren in Fachbereichen identifizieren und einbinden
Spezialisierte ERP-Schulungsdienstleister bieten standardisierte Trainings, die intern Kapazitäten schonen.
Tage 61–90: Cutover-Vorbereitung und Hypercare
In den letzten 30 Tagen vor Go-Live verschiebt sich der Fokus auf Cutover-Planung, Final-Tests und Hypercare-Vorbereitung. Diese Phase entscheidet, ob der Go-Live ruhig oder turbulent verläuft.
Cutover-Planung
Cutover-Plan mit Stundengenauigkeit erstellen
Go/No-Go-Kriterien schriftlich definieren
Mindestens einen Cutover-Trockenlauf am Wochenende durchführen
Rollback-Plan vorbereiten und kommunizieren
Hotline und Hypercare-Team aufstellen
Notfall-Eskalationskette definieren
Final-Tests und Anwenderakzeptanz
User Acceptance Tests (UAT) durch die Fachbereiche sind der letzte Härtetest. Schaffen Sie eine produktionsnahe Testumgebung mit migrierten Daten. Definieren Sie eine klare Akzeptanzkriterien-Liste und lassen Sie diese formal abnehmen. Ohne UAT-Abnahme kein Go-Live – diese Disziplin verhindert nachträgliche Diskussionen.
Hypercare-Phase planen
Die ersten zwei bis vier Wochen nach Go-Live sind die kritischste Phase. Stellen Sie ein Hypercare-Team aus internen Key-Usern und externen Beratern zusammen, das täglich tagt, Tickets priorisiert und schnell entscheidet. Planen Sie mindestens 30 Prozent zusätzliche Beraterkapazität für diese Phase ein.
Risiken und typische Stolperfallen
Aus zahlreichen Implementierungen kennen wir die wiederkehrenden Risiken. Die wichtigsten:
Scope Creep: Anforderungen wachsen unkontrolliert, das Projekt verzögert sich. Gegenmittel: Change-Request-Verfahren mit Lenkungskreis-Eskalation.
Datenqualität: Stammdaten sind schlechter als angenommen. Gegenmittel: Frühzeitige Bereinigungsphase mit Fachbereichs-Verantwortung.
Customizing-Spirale: Jeder Sonderwunsch wird programmiert. Gegenmittel: Strikter Standard-First-Ansatz.
Schwacher Implementierungspartner: Berater mit fehlender Branchenerfahrung. Gegenmittel: In der Auswahlphase Referenzen prüfen, Partner explizit benennen lassen.
Anwenderakzeptanz: Mitarbeitende boykottieren das System. Gegenmittel: Frühe Einbindung, Kommunikation und Erfolgsstories.
Wer schon in der Auswahlphase auf diese Risiken achtet – siehe Leitfaden ERP-Auswahl in 7 Schritten – startet die Implementierung mit deutlich besseren Voraussetzungen.
Compliance und regulatorische Anforderungen
Vergessen Sie die regulatorische Seite nicht. Die GoBD verlangt revisionssichere Verfahrensdokumentation, Unveränderbarkeit gebuchter Belege und nachvollziehbare Änderungshistorien. Die DSGVO erfordert Berechtigungskonzepte, Löschkonzepte und Auftragsverarbeitungsverträge mit Cloud-Anbietern. eRechnung ab 2025 bzw. 2027 muss berücksichtigt werden.
Kommunikation ist im ERP-Projekt der unsichtbare Erfolgsfaktor. Etablieren Sie einen klaren Kommunikationsplan mit unterschiedlichen Zielgruppen: Geschäftsführung, Fachbereichsleitung, Key-User, Endanwender, Betriebsrat, Externe. Jede Gruppe braucht andere Inhalte in anderer Frequenz. Für die Geschäftsführung reicht ein monatlicher Status mit Ampelkennzahlen, für Key-User sind wöchentliche Workshops sinnvoll, Endanwender informieren Sie über monatliche Newsletter mit konkreten Veränderungen, die sie betreffen.
Ein häufig unterschätzter Stakeholder ist der Betriebsrat, falls vorhanden. Bei der Einführung eines ERP-Systems sind oft Mitbestimmungsrechte berührt – etwa bei Leistungs- und Verhaltenskontrolle, neuen Berechtigungskonzepten oder veränderten Arbeitsabläufen. Binden Sie den Betriebsrat in den ersten 30 Tagen aktiv ein, schließen Sie eine Betriebsvereinbarung über das ERP-Projekt ab und vermeiden Sie damit spätere Verzögerungen durch formale Einsprüche. Auch Datenschutzbeauftragte und Compliance-Funktionen gehören in den ersten 30 Tagen an den Tisch.
Schnittstellen und Integrationsplanung
Schnittstellen sind der häufigste Grund für Verzögerungen am Ende des Projekts. Beginnen Sie deshalb in den ersten 30 Tagen mit einer detaillierten Schnittstellen-Inventarisierung. Listen Sie alle bestehenden Schnittstellen auf, dokumentieren Sie deren Funktion, Datenvolumen, Frequenz und Kritikalität. Identifizieren Sie, welche im neuen ERP nativ verfügbar sind, welche neu programmiert werden müssen und welche eventuell entfallen können.
Typische Schnittstellen im Mittelstand: DATEV für die Steuerberatung, EDI für Großkunden und Lieferanten, E-Commerce-Plattformen wie Shopify, Shopware oder Magento, CRM-Systeme wie Salesforce oder HubSpot, BI-Tools wie Power BI oder Qlik, DMS-Systeme wie d.velop oder ELO, Lohn- und Gehaltsabrechnungen wie SAP HR oder Sage HR. Jede dieser Schnittstellen erfordert detaillierte Mapping-Spezifikationen, Tests und Monitoring.
Spezialisierte ERP-Integrationspartner bringen vorgefertigte Konnektoren mit und beschleunigen die Implementierung deutlich. Achten Sie bei der Auswahl auf Erfahrung mit Ihrem konkreten ERP und den anzubindenden Drittsystemen. Eine Integrationsstrategie sollte zudem die zukünftige Erweiterbarkeit berücksichtigen – etwa durch eine zentrale Integrationsplattform (iPaaS) statt Punkt-zu-Punkt-Schnittstellen.
Branchenspezifische Implementierungsthemen
Je nach Branche gibt es spezifische Implementierungsthemen, die in den ersten 90 Tagen adressiert werden müssen. Maschinenbauer investieren früh in Variantenkonfiguratoren, Stücklistenstrukturen und MES-Integrationen. Großhändler fokussieren auf Lagerlogistik, Kommissionierung und EDI-Anbindung an Großkunden. Handwerksbetriebe setzen früh auf mobile Zeiterfassung und Auftragsabwicklung. Bauunternehmen integrieren Projektmanagement, Bautagebuch und Subunternehmer-Abrechnung.
Auch die Branchenstandards prägen die Implementierung. Automotive-Zulieferer müssen VDA-Standards umsetzen, Chemieunternehmen berücksichtigen Sicherheitsdatenblätter und Gefahrgutverwaltung, Möbelindustrie arbeitet mit komplexen Konfigurationen und Variantenstücklisten. Achten Sie darauf, dass Ihr Implementierungspartner die branchenspezifischen Anforderungen kennt und nicht erst während des Projekts erlernt – das verlängert die Einführung erheblich.
Nach 90 Tagen: Wie geht es weiter?
Nach 90 Tagen sollten Foundation, Konfiguration und ein erster Testzyklus stehen. Der eigentliche Go-Live folgt typischerweise nach weiteren 90 bis 180 Tagen. Wichtig ist, das Tempo zu halten und nicht in eine Routine-Phase abzudriften. Wöchentliche Steuerung, monatliche Lenkungskreise und transparente KPIs sind Pflicht bis zum Go-Live und darüber hinaus.
Nach erfolgreichem Go-Live beginnt die kontinuierliche Verbesserung. Releasewechsel, neue Funktionen, Prozessoptimierungen und Anwender-Feedback sollten in einem strukturierten Anforderungsprozess gebündelt werden. Ein ERP-System ist niemals "fertig" – es wächst mit dem Unternehmen. Etablieren Sie einen Steering-Prozess für laufende Anforderungen, bei dem Fachbereiche neue Wünsche dokumentieren, IT diese auf Machbarkeit prüft und das Lenkungsgremium über Priorisierung und Budget entscheidet.
Auch nach dem Go-Live empfiehlt sich der Aufbau einer kleinen Inhouse-Kompetenz. Ein bis zwei interne Power-User mit tiefem Systemwissen sind Gold wert. Sie übernehmen einfache Konfigurationsaufgaben, bilden den First-Level-Support und sorgen dafür, dass das Unternehmen nicht für jede Kleinigkeit externe Berater bezahlen muss. Investieren Sie in Schulung und Zertifizierung dieser Personen – die Investition amortisiert sich innerhalb von 12 Monaten. Größere Schulungsprogramme bieten spezialisierte ERP-Schulungsdienstleister.
Schließlich sollten Sie nach 12 Monaten eine ehrliche Projektretrospektive durchführen. Was lief gut? Was würden wir heute anders machen? Welche Erfahrungen tragen wir in das nächste Releaseprojekt? Diese Lerneffekte fließen in die Roadmap des Systems und in die Weiterentwicklung Ihrer Projektmethodik. Ein gutes ERP-Projekt ist der Beginn einer mehrjährigen Reise, kein abgeschlossener Bauabschnitt.
Risikomanagement-Framework für ERP-Projekte
Ein professionelles Risikomanagement gehört in die ersten 30 Tage jedes ERP-Projekts. Anders als bei kleineren IT-Projekten reichen Bauchgefühl und sporadische Reviews nicht aus. Etablieren Sie ein strukturiertes Framework mit vier Bestandteilen: Risikoregister, regelmäßige Bewertung, Mitigationsmaßnahmen und Eskalationsmechanismen. Das Risikoregister enthält für jedes identifizierte Risiko fünf Pflichtfelder: Beschreibung, Eintrittswahrscheinlichkeit (1-5), Auswirkung (1-5), kombinierter Risiko-Score (Produkt aus beidem) und verantwortliche Person.
Typische Risiken in ERP-Projekten lassen sich in fünf Kategorien gruppieren: Erstens technische Risiken wie unerwartete Performance-Probleme, fehlende Schnittstellen-Reife oder Migrationsfehler. Zweitens organisatorische Risiken wie Personalwechsel, mangelnde Verfügbarkeit von Key-Usern oder Konflikte zwischen Fachbereichen. Drittens kommerzielle Risiken wie Lizenzaudits, Kostenüberschreitungen oder Insolvenz des Implementierungspartners. Viertens regulatorische Risiken wie GoBD-Probleme, DSGVO-Verstöße oder fehlende Audit-Trails. Fünftens strategische Risiken wie Veränderungen im Geschäftsmodell, Übernahmen oder Marktrückgänge während der Projektlaufzeit.
Bewerten Sie das Risikoregister mindestens monatlich, eskalieren Sie Risiken mit Score 16 oder höher (z.B. Wahrscheinlichkeit 4 mal Auswirkung 4) sofort an den Lenkungskreis. Nutzen Sie die Risikobewertung auch proaktiv: Definieren Sie für die Top-5-Risiken konkrete Frühwarnindikatoren, die kontinuierlich gemessen werden. Steigt etwa die Bug-Rate in den Anwendertests über zehn Prozent, ist das ein klares Frühwarnsignal für Qualitätsprobleme. Eine externe Projekt-Auditierung durch unabhängige Spezialisten – siehe ERP-Auswahlbegleitung – nach jeder Phase bietet zusätzliche Risikotransparenz.
Testmanagement-Strategie über alle Phasen
Testen ist im ERP-Projekt keine Endphase, sondern ein durchgängiger Prozess von der Konfiguration bis zum Hypercare. Eine professionelle Teststrategie umfasst sechs Testarten: Komponententests prüfen einzelne Funktionen wie Buchungslogik oder Preisermittlung. Integrationstests validieren das Zusammenspiel mehrerer Module, etwa Auftragsabwicklung von Angebot bis Rechnung. Schnittstellentests prüfen die Anbindung an Drittsysteme wie DATEV, EDI oder E-Commerce-Plattformen. Performance-Tests prüfen Antwortzeiten unter realistischer Last. Regressionstests stellen sicher, dass neue Konfigurationen bestehende Funktionen nicht brechen. User Acceptance Tests (UAT) sind die finale Abnahme durch die Fachbereiche.
Für jede Testart definieren Sie klare Eintritts- und Austrittskriterien, Verantwortlichkeiten und Zeiträume. Erstellen Sie eine Testfall-Bibliothek mit mindestens 200–500 Testfällen für ein typisches Mittelstandsprojekt, abgedeckt nach den Hauptprozessen Order-to-Cash, Procure-to-Pay, Plan-to-Produce und Record-to-Report. Jeder Testfall hat klare Eingaben, erwartete Ausgaben und Akzeptanzkriterien. Dokumentieren Sie alle Testdurchführungen im Testmanagement-Tool und tracken Sie gefundene Bugs mit Schweregrad und Lösungsstatus.
Komponententests: einzelne Funktionen, durch Konfigurations-Team
Integrationstests: Modul-übergreifend, durch Testteam
Schnittstellentests: mit echten Drittsystemen, gegen Sandbox-Umgebungen
Regressionstests: automatisiert wo möglich, vor jedem Release
UAT: durch Fachbereiche, mit Abnahmekriterien
Pilottests: mit ausgewählten Anwendern, vor Go-Live
Investieren Sie in eine produktionsnahe Testumgebung mit migrierten Realdaten – synthetische Testdaten reichen für UAT nicht aus. Anonymisieren Sie sensitive Daten wie Personaldaten oder Geschäftsgeheimnisse, halten Sie aber Volumen und Komplexität der Echtdaten bei. Etablieren Sie Testautomatisierung für Regressionstests – manuelle Regressionstests sind in komplexen ERP-Landschaften nicht mehr leistbar. Eine grobe Faustregel: Investieren Sie 15–20 Prozent des Implementierungsbudgets in Test und Qualitätssicherung. Das klingt viel, ist aber im Vergleich zu den Kosten eines fehlgeschlagenen Go-Lives eine günstige Versicherung.
Cutover-Wochenende: Stundengenaue Planung
Der Cutover ist der Moment der Wahrheit. In wenigen Stunden oder Tagen müssen Daten migriert, Anwender umgestellt und das alte System abgeschaltet werden – während das Tagesgeschäft am Montag wieder anlaufen soll. Eine stundengenaue Cutover-Planung ist deshalb Pflicht. Beginnen Sie mit der Cutover-Planung mindestens 60 Tage vor Go-Live, etablieren Sie wöchentliche Cutover-Runden und führen Sie mindestens einen vollständigen Trockenlauf an einem Wochenende vor dem geplanten Termin durch.
Ein typischer Cutover für ein Mittelstandsprojekt verläuft über ein verlängertes Wochenende von Freitag 18 Uhr bis Montag 8 Uhr. In dieser Zeit werden folgende Aktivitäten in fester Reihenfolge ausgeführt: Abschaltung der schreibenden Zugriffe im Altsystem, finale Datenextraktion, Datenbereinigung, Migration in das neue System, Validierung der migrierten Daten, Schnittstellenaktivierung, Berechtigungsverteilung, Smoke-Tests durch Key-User, Freigabe durch den Cutover-Manager, Information der Endanwender und schließlich Produktivsetzung am Montagmorgen.
Zeitfenster
Aktivität
Verantwortlich
Fr 18:00-19:00
Abschaltung Altsystem (read-only)
IT-Betrieb
Fr 19:00-22:00
Finale Datenextraktion und Bereinigung
Migrationsteam
Fr 22:00-Sa 06:00
Datenmigration ins neue System
Implementierungspartner
Sa 06:00-12:00
Validierung migrierter Daten
Key-User Finanzen, Vertrieb
Sa 12:00-18:00
Schnittstellenaktivierung und Tests
Integrationspartner
Sa 18:00-So 08:00
Berechtigungsverteilung, Smoke-Tests
IT, Key-User
So 08:00-18:00
Go/No-Go-Entscheidung, Final-Tests
Cutover-Manager, Lenkungskreis
So 18:00-Mo 06:00
Anwender-Information, Bereitstellung
Change-Team, Hotline
Mo 06:00-08:00
Bereitstellung der Hypercare-Hotline
Hypercare-Team
Definieren Sie schriftliche Go/No-Go-Kriterien vorab. Beispiele: Daten vollständig migriert (Differenz unter 0,1 Prozent), kritische Schnittstellen (DATEV, EDI) funktionsfähig, Smoke-Tests in allen Hauptprozessen erfolgreich, Hypercare-Team bereit. Werden Kriterien nicht erfüllt, greift der Rollback-Plan – dieser muss vorab dokumentiert und mit dem Lenkungskreis abgestimmt sein. Ein abgebrochener Cutover ist deutlich besser als ein gescheiterter Go-Live.
Post-Go-Live-Reviews und kontinuierliche Verbesserung
Nach dem Go-Live ist vor dem nächsten Releasezyklus. Etablieren Sie deshalb eine strukturierte Post-Go-Live-Routine mit drei Reviews: 30-Tage-Review nach Go-Live, 90-Tage-Review und 12-Monats-Review. Jeder Review hat eine andere Zielsetzung. Der 30-Tage-Review fokussiert auf Stabilität: Welche Tickets sind offen, wo gibt es Performance-Probleme, welche Anwender brauchen zusätzliche Schulung? Der 90-Tage-Review bewertet die Geschäftsergebnisse: Werden die Prozesse wie geplant durchgeführt, sind die Effizienzziele erreicht, gibt es unerwartete Workarounds? Der 12-Monats-Review ist die strategische Retrospektive: Welche Lessons Learned tragen wir in die nächste Phase, welche Erweiterungen sind sinnvoll, wie steuern wir die kontinuierliche Verbesserung?
Strukturieren Sie jeden Review nach einem festen Schema: Zielerreichung im Vergleich zum Soll-Konzept, KPI-Performance gegenüber dem Business Case, offene Themen und Risiken, neue Anforderungen aus den Fachbereichen, Empfehlungen für die nächste Phase. Dokumentieren Sie alle Reviews in einem zentralen Projekt-Wiki, das auch nach Projektabschluss als Wissensbasis dient. Beteiligen Sie an den Reviews neben Projektleitung und IT auch die Fachbereichsleitungen, damit die Geschäftssicht im Mittelpunkt steht.
Anforderungsmanagement: strukturierter Backlog für neue Wünsche
Power-User-Programm: 1-2 interne Spezialisten pro Hauptmodul
Releaseplanung: halbjährliche Updates mit Anwender-Information
Aufbauend auf den Reviews entsteht ein kontinuierlicher Verbesserungsprozess. Etablieren Sie einen halbjährlichen Releasezyklus mit klaren Inhalten, kommunizieren Sie jede Änderung transparent an die Anwender. Investieren Sie in interne Power-User mit tiefem Systemwissen – sie übernehmen den First-Level-Support und reduzieren die Abhängigkeit von externen Beratern. Spezialisierte ERP-Schulungsdienstleister qualifizieren Power-User systematisch. Für strategische Weichenstellungen wie Cloud-Migration, KI-Integration oder Architekturwechsel lohnt sich alle zwei bis drei Jahre eine externe Standortbestimmung – siehe ERP-Auswahl in 7 Schritten als methodischer Rahmen für solche Re-Evaluierungen.
Wie viele interne Personentage müssen wir in den ersten 90 Tagen einplanen?
Für ein mittelständisches Projekt mit rund 80 Anwendern sind in den ersten 90 Tagen realistisch 250 bis 400 interne Personentage einzuplanen. Davon entfallen grob etwa 60 Tage auf den Projektleiter, rund 120 Tage auf die Key-User und der Rest auf IT, Datenbereinigung und Tests. Diese Größenordnung ist ein Erfahrungswert und keine feste Norm; die genaue Ausgestaltung variiert je nach Branche, Größenklasse und Customizing-Tiefe des konkreten ERP-Setups. Wichtig ist vor allem, diese internen Aufwände früh sichtbar zu machen und gegen das Tagesgeschäft abzusichern, da unterschätzte Eigenleistung zu den häufigsten Projektrisiken zählt.
Wer sollte den Projektleiter stellen – wir oder der Implementierungspartner?
In der Praxis bewährt sich eine Doppelbesetzung: ein interner Projektleiter, der die fachliche Führung und Entscheidungshoheit hat, ergänzt durch einen Projektleiter beim Implementierungspartner für die externe Steuerung. Ein rein extern besetzter Projektleiter gilt als riskant, weil interne Akzeptanz, Wissenstransfer und Verantwortungsübernahme darunter leiden. Der interne Projektleiter sollte ausreichend von operativen Aufgaben freigestellt sein und über ein klares Mandat des Lenkungskreises verfügen. Die optimale Konstellation hängt von Unternehmensgröße, Prozesskomplexität und der strategischen IT-Roadmap ab.
Wann sollte die Datenmigration und Stammdatenbereinigung starten?
Spätestens in den ersten beiden Projektwochen, also klar innerhalb der ersten 30 Tage und nicht erst kurz vor dem Cutover. Die Stammdatenbereinigung dauert nahezu immer länger als geplant und blockiert sonst die gesamte Migration auf dem kritischen Pfad. Definieren Sie früh Data Owner in den Fachbereichen, übergeben Sie die Bereinigungsverantwortung dorthin und etablieren Sie eine wöchentliche Messung der Datenqualität. Planen Sie zudem mindestens drei Migrations-Trockenläufe mit Validierung durch die Fachbereiche ein, denn die Datenqualität ist erfahrungsgemäß selten so gut, wie sie zunächst eingeschätzt wird.
Wie lange dauert eine ERP-Einführung im Mittelstand insgesamt bis zum Go-Live?
Die hier beschriebene 90-Tage-Checkliste deckt nur die Foundation-, Konfigurations- und erste Testphase ab; der eigentliche Go-Live folgt typischerweise weitere 90 bis 180 Tage später. Branchenüblich liegt die Gesamtdauer einer ERP-Einführung im Mittelstand meist zwischen sechs und achtzehn Monaten, je nach Komplexität, Customizing-Tiefe und Datenmigration. Cloud- beziehungsweise SaaS-Einführungen verkürzen die Laufzeit spürbar und werden teils in drei bis neun Monaten umgesetzt, während stark angepasste On-Premise-Projekte deutlich länger laufen können. Entscheidend ist, das Tempo nach den ersten 90 Tagen über wöchentliche Steuerung und monatliche Lenkungskreise konsequent zu halten.
Welche regulatorischen Pflichten – etwa GoBD und eRechnung – müssen wir bei der Implementierung berücksichtigen?
Regulatorische Themen gehören in die ersten 30 Tage und nicht ans Projektende. Die GoBD verlangt eine revisionssichere Verfahrensdokumentation, die Unveränderbarkeit gebuchter Belege und nachvollziehbare Änderungshistorien, während die DSGVO Berechtigungs- und Löschkonzepte sowie Auftragsverarbeitungsverträge mit Cloud-Anbietern erfordert. Bei der elektronischen Rechnung gilt: Der Empfang strukturierter E-Rechnungen im inländischen B2B-Bereich ist in Deutschland bereits seit dem 1. Januar 2025 verpflichtend, beim Versand greifen Übergangsfristen – ab 2027 zunächst für Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz und spätestens ab 2028 für alle inländischen B2B-Unternehmen. Regulierte Branchen wie Pharma oder Lebensmittelindustrie haben mit GxP-Validierung, Chargenrückverfolgung und Audit-Trails zusätzliche Anforderungen, die früh in die Konfiguration einfließen müssen.
Müssen wir den Betriebsrat bei der ERP-Einführung einbinden?
Falls ein Betriebsrat besteht, ist eine frühe Einbindung in den ersten 30 Tagen dringend zu empfehlen. ERP-Systeme gelten arbeitsrechtlich regelmäßig als technische Einrichtungen im Sinne des § 87 Abs. 1 Nr. 6 BetrVG, weil sie geeignet sind, Leistung und Verhalten von Beschäftigten zu erfassen – dadurch entsteht ein Mitbestimmungsrecht, das sich auf den gesamten Einführungsprozess bis zum Go-Live erstreckt. Üblich und sinnvoll ist der Abschluss einer Betriebsvereinbarung, die den zulässigen Umfang von Auswertungen, das Berechtigungskonzept und veränderte Arbeitsabläufe regelt. Wird der Betriebsrat zu spät beteiligt, drohen formale Einsprüche und erhebliche Verzögerungen; eine konkrete rechtliche Bewertung sollte stets mit der eigenen Personal- oder Rechtsabteilung erfolgen.
Was tun, wenn das Projekt nach 90 Tagen aus dem Ruder läuft?
Frühzeitig und transparent eskalieren statt aussitzen. Berufen Sie den Lenkungskreis ein, kommunizieren Sie den Status ehrlich und passen Sie eine der drei Stellgrößen Scope, Zeit oder Budget bewusst an, statt alle drei gleichzeitig schleifen zu lassen. Hintergrund ist, dass ein erheblicher Anteil von ERP-Projekten Budget- oder Terminziele verfehlt, häufig wegen unterschätzter Aufwände, nachträglich benötigter Technik oder organisatorischer Probleme. Eine unabhängige Auswahlbegleitung oder ein externes Projekt-Audit hilft oft, blinde Flecken zu identifizieren und wirksame Gegenmaßnahmen zu definieren, bevor sich kleinere Abweichungen zu einem gescheiterten Go-Live aufschaukeln.