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.
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
- Projektleiter intern und beim Implementierungspartner namentlich festlegen
- 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.
Bestandsaufnahme der Quelldaten
- Liste aller Quellsysteme und -tabellen erstellen
- Datenqualitätsanalyse: Dubletten, fehlende Pflichtfelder, inkonsistente Formate
- 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
- Stammdatenstrukturen (Artikel, Lieferanten, Kunden) festlegen
- Vertriebs- und Einkaufsprozesse abbilden
- Lagerstrategie, Buchungslogik, Inventurverfahren definieren
- Berechtigungs- und Rollenkonzept aufbauen
- 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.
- Train-the-Trainer-Konzept für Key-User aufsetzen
- Schulungsmaterialien erstellen: Handbücher, Lernvideos, E-Learning
- 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.
Regulierte Branchen wie Pharma oder Lebensmittelindustrie haben zusätzliche Anforderungen wie GxP-Validierung, Chargenrückverfolgung und Audit-Trails. Diese Themen gehören in die ersten 30 Tage – nicht in die letzten 30.
Stakeholder-Kommunikation in den ersten 90 Tagen
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.
| Risikokategorie | Typische Beispiele | Mitigationsstrategie |
|---|---|---|
| Technisch | Migrationsfehler, Performance, Schnittstellen | frühe Trockenläufe, Lasttests, Pilotphasen |
| Organisatorisch | Personalwechsel, Key-User-Verfügbarkeit | Stellvertreter, Wissenssicherung, Ressourcenplanung |
| Kommerziell | Lizenzaudits, Kostenüberschreitungen | klare Verträge, Budgetreserve 15-20 % |
| Regulatorisch | GoBD, DSGVO, Audit-Trails | Compliance-Review in den ersten 30 Tagen |
| Strategisch | Übernahmen, Marktveränderungen | Lenkungskreis-Sponsoring, flexible Architektur |
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
- Performance-Tests: Lastprofile, Antwortzeiten, Skalierung
- 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.
- 30-Tage-Review: Stabilität, Tickets, Performance, Schulungsbedarf
- 90-Tage-Review: Prozessperformance, KPI-Erreichung, Workarounds
- 12-Monats-Review: strategische Retrospektive, Lessons Learned, Roadmap
- 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.
Häufige Fragen
- Wie viele interne Personentage müssen wir in den ersten 90 Tagen einplanen?
- Für ein mittelständisches Projekt mit 80 Anwendern realistisch 250–400 interne Personentage in den ersten 90 Tagen. Davon entfallen etwa 60 Tage auf den Projektleiter, 120 Tage auf Key-User und der Rest auf IT, Datenbereinigung und Tests.
- Wer sollte den Projektleiter stellen – wir oder der Implementierungspartner?
- Beides. Setzen Sie zwingend einen internen Projektleiter ein, der die fachliche Führung hat, ergänzt durch einen Projektleiter beim Implementierungspartner für die externe Steuerung. Ein rein externer Projektleiter ist riskant, weil interne Akzeptanz und Wissenstransfer leiden.
- Wann sollte die Datenbereinigung starten?
- Spätestens in Woche zwei. Stammdatenbereinigung dauert typischerweise länger als geplant und blockiert sonst die Migration. Definieren Sie früh Datenowner in den Fachbereichen und etablieren Sie eine wöchentliche Statusmessung der Datenqualität.
- Was tun, wenn das Projekt nach 90 Tagen aus dem Ruder läuft?
- Klar eskalieren statt aussitzen. Lenkungskreis einberufen, Status ehrlich kommunizieren, Scope, Zeit oder Budget anpassen. Externe Auswahlbegleitung oder Projekt-Audits durch unabhängige Spezialisten helfen oft, blinde Flecken zu identifizieren und Gegenmaßnahmen zu definieren.
