Die 10 häufigsten Fehler bei der ERP Auswahl
Jeder Punkt folgt derselben Logik: Warum passiert es? → Woran erkennst du es? → Wie verhinderst du es?
Zu großer Scope: 'Wir machen alles auf einmal'
Warum kritisch: Wenn jede Abteilung alles gleichzeitig will, explodieren Zeitplan, Tests und Change-Aufwand.
Praxisbeispiel
Typisch: Mehrere Standorte, Finance, Lager, Produktion, CRM-Extras – alles im ersten Go-Live. Ergebnis: 9 Monate später ist noch keine Kernkette stabil.
Warnsignale
- Anforderungen-Liste wächst täglich
- Kein MVP, nur 'vollständig'
- Entscheidungen werden verschoben (‘später klären’)
Gegenmaßnahmen (Fix)
- MVP definieren (3–5 Kernprozesse, 1–2 Standorte) und Roadmap v2/v3
- Scope-Change-Prozess mit Impact (Zeit/Kosten/Risiko)
- Fit-to-Standard als Default, Customizing begrenzen
Feature-Shopping statt Use-Case-Auswahl
Warum kritisch: Features klingen gut, aber entscheiden nicht, ob eure Prozesse im Alltag funktionieren.
Praxisbeispiel
Ein Anbieter gewinnt wegen ‘100 Features’. Im Go-Live zeigt sich: eure 10 Kernfälle (Retouren, Teillieferungen, Sammelrechnung) sind nicht sauber getestet.
Warnsignale
- Anforderungskatalog ist eine Feature-Liste
- Keine Demo-Skripte mit echten Szenarien
- Bewertung basiert auf 'Gefühl'
Gegenmaßnahmen (Fix)
- Use-Case Backlog (10–20 Fälle) mit Akzeptanzkriterien
- Demo-Skripte + echte Beispieldaten (nicht Anbieter-Demo)
- Gewichtung nach Business-Impact (nicht Feature-Fairness)
‘Wir passen das ERP an uns an’ (Customizing-Spirale)
Warum kritisch: Customizing ist oft der größte TCO-Treiber – und bindet euch langfristig an Partner/Release-Zyklen.
Praxisbeispiel
Eine Sonderlogik wird ‘schnell gebaut’. Nach einem Jahr existieren 40 Sonderfälle – Updates werden riskant, jedes Problem wird ein Projekt.
Warnsignale
- ‘Das machen wir dann custom’ ist Standardsatz
- Gaps werden nicht priorisiert
- Keine klare No-Go-Liste
Gegenmaßnahmen (Fix)
- Fit-to-Standard Workshops: Prozesse so anpassen, dass Standard funktioniert
- Gaps klassifizieren (Must/Should/Could) + harte No-Gos
- Sonderlogiken in Downstream-Systeme auslagern (wo sinnvoll)
Datenmigration zu spät (oder ohne Ownership)
Warum kritisch: ERP-Projekte sterben nicht an Modulen, sondern an Daten: Dubletten, fehlende Pflichtfelder, falsche Stammsätze.
Praxisbeispiel
Zwei Wochen vor Go-Live beginnt die Bereinigung. Ergebnis: Cutover verschoben, Hypercare überlastet, Vertrauen weg.
Warnsignale
- Kein Data Owner je Objekt (Kunde, Artikel, Lieferant)
- Mapping existiert nur als 'IT-Liste'
- Kein Probelauf (v1/v2/v3)
Gegenmaßnahmen (Fix)
- Data Ownership festlegen + Datenqualität messen
- Migration iterativ (v1/v2/v3) inkl. Validierungsregeln
- Cutover-Runbook früh planen (Freeze, Delta, Smoke Tests)
Integrationen werden als ‘Schnittstelle’ unterschätzt
Warum kritisch: Eine Schnittstelle ist nicht nur API – sie braucht Betrieb: Monitoring, Reprocessing, Ownership.
Praxisbeispiel
Shop-Bestellungen hängen, weil ein Feld falsch gemappt ist. Ohne Monitoring merkt es niemand – bis Kunden anrufen.
Warnsignale
- Kein Monitoring/Alerting geplant
- Punkt-zu-Punkt Integrationen ohne Standards
- ‘Fehlerfälle’ sind nicht getestet
Gegenmaßnahmen (Fix)
- Integration als Produkt: Logging, Alerts, Dead-letter, Reprocessing
- iPaaS/Automatisierung für Wiederverwendung und Betriebssicherheit
- Fehlerfall-Tests als Pflicht im UAT (nicht optional)
Demos ohne Vergleichbarkeit (Anbieter steuert die Show)
Warum kritisch: Wenn Anbieter frei präsentieren, gewinnt der beste Sales-Prozess – nicht das beste System für euch.
Praxisbeispiel
Ein Anbieter zeigt perfekte Standardprozesse, aber nicht eure Sonderfälle. Der andere wird ‘bestraft’, weil er ehrlich über Grenzen spricht.
Warnsignale
- Keine Demo-Agenda pro Use Case
- Keine Bewertungsmatrix
- Wichtige Rollen (Finance/Lager) nicht in Demos
Gegenmaßnahmen (Fix)
- Demo-Skripte aus euren Prozessen + gleiche Zeitbox für alle
- Bewertungsmatrix (1–5) + Gewichtung + dokumentierte Trade-offs
- ‘No-Go’ Fragen fix einbauen (Berechtigungen, Audit, Reporting, Integrationen)
Das Projekt ist ‘IT’ – Fachbereich ist nur Zuschauer
Warum kritisch: ERP ist Prozessveränderung. Ohne Fachbereich-Ownership gibt es keine Adoption – egal wie gut das Tool ist.
Praxisbeispiel
Key User werden nebenbei eingeplant. Im UAT fehlen Entscheidungen, im Go-Live fühlt sich niemand verantwortlich.
Warnsignale
- Key User haben keine Kapazität geblockt
- Steering Committee trifft selten Entscheidungen
- Training wird als ‘nice to have’ behandelt
Gegenmaßnahmen (Fix)
- Rollen & Kapazitäten verbindlich (PO/Key User/Data Owner)
- Entscheidungstermine einplanen (nicht ‘ad hoc’)
- Change Management: Kommunikation, Trainings, Super-User Netzwerk
Kostenfokus nur auf Lizenz – TCO wird ignoriert
Warum kritisch: Lizenz ist selten der größte Block. Betrieb, Integrationen, Customizing und Weiterentwicklung dominieren 3–5 Jahre.
Praxisbeispiel
Günstige Lizenz gewinnt. Danach: hohe Partnerkosten, teure Integrationen, Update-Probleme – TCO kippt.
Warnsignale
- Kein 3–5 Jahres-TCO
- Betrieb/Support nicht durchgerechnet
- Kein Plan für Releases und Weiterentwicklung
Gegenmaßnahmen (Fix)
- TCO-Rechnung: Lizenz + Implementierung + Betrieb + Integrationen + Wachstum
- Sensitivität: Standorte, Nutzer, Volumen, neue Prozesse
- Betriebsmodell als Teil der Entscheidung
Reporting/Controlling kommt ‘später’ – und wird dann teuer
Warum kritisch: Wenn Datenmodell und Buchungslogik stehen, wird BI/Reporting sonst zu Reparaturarbeit.
Praxisbeispiel
Nach Go-Live stellt Finance fest, dass Auswertungen fehlen oder Zahlen anders interpretiert werden. Workarounds entstehen.
Warnsignale
- Finance-Anforderungen sind unklar
- Keine Definition von KPIs/Dimensionen
- Testfälle decken Buchungslogik nicht ab
Gegenmaßnahmen (Fix)
- Finance/Controlling früh einbinden (Definitionen, Kontenlogik, Perioden)
- Berichte als Use Cases behandeln (nicht als ‘Extras’)
- UAT mit Monatsabschluss-Szenario (wenn relevant)
Go-Live ist geplant – Betrieb (Run) nicht
Warum kritisch: Ohne Operating Model wird Hypercare ein Dauerzustand. ERP braucht Ownership, Incident-Prozess, Releases, Datenregeln.
Praxisbeispiel
Nach Go-Live gibt es täglich Tickets, aber niemand priorisiert. Jede Kleinigkeit wird zum Projekt. Frust steigt.
Warnsignale
- Kein Hypercare-Plan (War Room, Priorisierung, SLA)
- Keine Runbooks für Integrationen
- Berechtigungs-/Change-Prozess fehlt
Gegenmaßnahmen (Fix)
- Operating Model definieren (Rollen, Prozesse, Release-Zyklus)
- Hypercare als Phase planen (2–8 Wochen) mit klaren KPIs
- Monitoring & Ownership für Integrationen und Datenregeln
Mini-Checkliste (zum Speichern/Teilen)
- MVP definiert + Roadmap v2/v3
- Use-Case Demo-Skripte + echte Beispieldaten
- Bewertungsmatrix mit Gewichtung + dokumentierte Trade-offs
- Datenowner je Objekt + Migration iterativ (v1/v2/v3)
- Integrationen betriebsfähig: Monitoring, Alerts, Reprocessing, Runbooks
- TCO über 3–5 Jahre (nicht nur Lizenz)
- Change: Key User Netzwerk, Trainings, Kommunikation
- Operating Model für Run (Hypercare, Releases, Ownership)
Erstberatung: ERP Auswahl ‘No-Surprise’-Check
Wenn du willst, machen wir in 45–60 Minuten einen Kurzcheck: Scope/MVP, Demo-Skripte, Integrationen, Datenmigration, TCO und Risiken. Systemunabhängig – ohne Tool-Pitch.