ERP failure usually starts before coding
ERP projects fail when software is asked to resolve unresolved business ownership, inconsistent master data, contradictory processes, and unprepared users. Custom code can automate a decision; it cannot decide which department owns the process or which duplicate customer record is correct.
Process ownership and data quality are first-class work
- Assign a business owner for every end-to-end process before configuration.
- Clean and govern master data before migration.
- Distinguish legal/competitive requirements from habits that should adopt the standard workflow.
- Prototype critical processes with real users and representative data.
- Train by role and scenario, then measure adoption and exception volume after go-live.
Failure chain from vague requirement to rejected rollout
Vague ownership produces conflicting configuration, then custom workarounds, dirty migration, training confusion, and finally operational rejection.
How unresolved business ambiguity becomes ERP failure
Vague ownership produces conflicting configuration, then custom workarounds, dirty migration, training confusion, and finally operational rejection.
1
No process ownerStart
2
Conflicting requirementsStep
3
Excess customizationStep
4
Dirty migrationStep
5
User confusionStep
6
Manual workaround returnsOutcome
A finance workflow that never got standardized
What “more customization” cannot fix
ERP recovery checklist
- Name business owners and decision rights.
- Clean master data with measurable acceptance rules.
- Classify requirements as standard/config/custom/integration.
- Pilot end-to-end scenarios before mass rollout.
- Track exceptions, manual workarounds, and adoption after go-live.