ERP Health Check

When an ERP health check makes sense

An ERP health check is useful whenever you need an objective picture before making a decision. The most common situations I see are:

• A live system that feels underused, with spreadsheets, manual reports and email approvals running alongside it.
• Before a major upgrade or version migration, to understand which customizations and integrations will be affected.
• Before adding new modules, entities or countries, to check that the foundations can support them.
• After a change of leadership, when a new CFO, COO or IT head wants to understand what they have inherited.
• During an implementation, as a mid-project checkpoint before testing or go-live.
• When considering replacement, to test whether the problems come from the platform or from how it was set up.

The value of a health check lies in its independence. Your implementation partner may be very capable, but they are naturally reviewing their own work. Your internal team is often too close to the day-to-day issues to see the patterns. As an independent ERP consultant, I can look across the system, the processes and the people with fresh eyes and report what I find without a commercial interest in the answer.

If your project is already in serious difficulty, the more focused ERP recovery service may be the better starting point. If the system is broadly sound but underperforming, the health check usually leads into ERP optimization.

How the ERP review is carried out

A health check combines conversations with people and evidence from the system. Opinions tell me where to look; data tells me whether the problem is real and how big it is.

The typical sequence:

1. Kick-off with leadership to agree the questions the review must answer and what decisions it will inform.
2. Document review of any requirements, BRDs, design documents, process maps, test results and support logs that exist.
3. Stakeholder interviews with process owners and power users in finance, sales, purchasing, operations and IT.
4. System walkthroughs where users show real tasks, so I can see the friction they describe.
5. Configuration and data review, including roles and permissions, custom objects, integration logs, open documents and master data samples.
6. Analysis and validation, checking draft findings with the relevant owners to avoid misunderstandings.

I work remotely with read-only access wherever possible and keep disruption low: most people spend an hour or two in interviews and walkthroughs. The review uses the same artifacts I use on new projects, such as process maps and a fit-gap matrix, so findings can feed straight into future work. If documentation is missing, that becomes a finding too, because undocumented systems are harder to support, upgrade and audit.

What the health check report contains

The report is written for decision-makers, not just for technical teams. Every finding answers four questions: what is happening, why it matters to the business, what is causing it and what should be done.

I present the findings in a readout session with leadership and key stakeholders, so questions can be answered and priorities agreed in the room. Where findings relate to your implementation partner's work, I phrase them factually and constructively, because the goal is a better system rather than blame. The recommendations are deliberately practical: what can be fixed through configuration or training, what needs development, and what requires a broader business decision.

Security roles, customizations and integration risks

Three areas deserve special attention because their problems are often invisible until something goes wrong.

Security and roles. Over time, permissions tend to accumulate. People change jobs but keep old access, shared logins appear for convenience and approval limits are bypassed. I check whether users can create and approve the same transaction, whether sensitive data such as payroll or pricing is properly restricted, and whether dormant accounts remain active. These findings matter for audit, fraud prevention and data protection.

Customizations. Custom code solves immediate problems but creates long-term cost. I list each customization, check whether it is documented and still used, and assess whether newer standard features could replace it. Heavily customized systems are harder to upgrade, so this part of the review is especially useful before a version change.

Integrations. Many integrations work until they quietly stop. I review how each connection handles errors, who is alerted when a sync fails, which system owns each record and how often people correct data by hand. Weak integrations are a common source of duplicate records and reports that do not match.

Fixes in these areas often link to ERP integration and system integration work. If you would like an independent view of your ERP, get in touch to agree the scope.