ERP Health Check
An ERP health check establishes where the current estate actually stands before anyone proposes replacing it. It frequently finds that the system is not the problem, which is the most valuable outcome it can produce.
Why it matters
Replacement is the most expensive available answer. It is the right answer often enough that it gets chosen before the question has been asked properly.
- The symptom is rarely the cause: "The system can't do it" usually means unconfigured, untrained, or a process the system was never told about.
- A replacement inherits the data: Bad master data moves across unless it is fixed, and fixing it is business work either way.
- It sizes the real problem: Customisation, integration count and support model tell you what any replacement is actually up against.
The workflow
- 01
Scope
Which systems, processes and sites are in the assessment.
- 02
Functional assessment
Process by process, what is supported, what is worked around and why.
- 03
Data assessment
Master data quality, duplication, completeness and ownership, measured.
- 04
Technical assessment
Version currency, customisation, integration count and infrastructure.
- 05
Cost and support
Total cost of ownership, support model, and key-person dependency.
- 06
Risk
Security, continuity, compliance and end-of-support exposure.
- 07
Findings
Options — fix, upgrade or replace — with cost and time for each.
Count the spreadsheets. The number of spreadsheets between two systems is the single most reliable indicator of where the estate is actually failing, and it is easier to count than to argue about.
What you need in place
- Access to the people who do the work: Not just to the people who own the systems.
- Measured data quality: Duplicate rates and completeness, sampled, not estimated.
- A customisation inventory: With reasons where they are still known.
- An interface catalogue: Including the undocumented ones.
- Real total cost of ownership: Licence, support, infrastructure and internal effort.
- Three options costed: Fix, upgrade, replace — so replacement is chosen, not defaulted to.
Questions to ask
01Workarounds
Where does work leave the system and come back?
Each one is a requirement nobody wrote down.
02Data
What is our duplicate rate on customer and supplier master?
Measure it; the estimate is always lower.
03Customisation
How much, and does anyone know why?
Unexplained customisation is the upgrade blocker.
04Support
How many people can support this, and what is the bus factor?
Key-person dependency is a risk that reads as stability.
05Cost
What does this actually cost per year, all in?
Including internal effort, which is rarely counted.
06Fixability
Which complaints could be fixed without replacement?
Usually more than expected.
Metrics and KPIs to track
Process coverage
Processes fully supported against worked around.
Master data quality
Duplicate and completeness rates by domain.
Customisation count
By type, and share blocking upgrade.
Interface count
Documented against discovered.
Total cost of ownership
Per year, all components.
Support concentration
Systems with a single capable supporter.
Alongside this