You have invested in an ERP system, trained your employees, and started recording transactions. Yet management still asks for separate spreadsheets. Stock figures remain disputed. Accounts makes frequent adjustments, and employees say the system does not support their work.
It is tempting to conclude that you purchased the wrong ERP.
Before deciding to replace it, investigate where the difficulty begins. A missing feature, an incorrect setting, unreliable data, and an unfinished business process can produce similar symptoms—but require different solutions.
Start with one complaint and follow the evidence
“The ERP is not useful” is difficult to investigate. A specific example gives you a starting point.
Ask your team to identify a recent transaction that produced an unexpected result. Record what they expected, what actually happened, and the documents involved.
For example:
“The system allowed goods to be delivered to a customer whose payment was overdue.”
Before treating this as a software limitation, check:
- Were the customer’s outstanding balances accurate?
- Had the credit terms and limits been maintained?
- Which document was supposed to trigger the restriction?
- Did the user have permission to override it?
- Was that transaction route included in implementation testing?
The answers may point to configuration, permissions, data, or a gap in the agreed process.
When the feature exists, but the result is wrong
A configuration problem becomes more likely when the ERP supports the required function, but your setup does not produce the agreed behaviour.
Consider a business that needs expenses reported by department. The system may support cost centres, yet expenses are regularly posted without them.
The investigation should establish whether:
- The correct cost centres were created.
- Users can select them on the relevant transactions.
- Mandatory entry rules are available and enabled where needed.
- Defaults are appropriate.
- Reports include the correct transactions and dimensions.
Buying another reporting tool will not resolve missing department information at the point of entry.
When employees maintain a second operation outside ERP
Spreadsheets can be useful for analysis. Pay attention when they become the place where essential operational records are maintained.
Perhaps production consumption is recorded in a notebook and entered several days later. Perhaps the warehouse tracks available quantities separately because ERP stock cannot be trusted.
Ask why this happens.
The transaction screen may be inconvenient. Employees may lack access or training. The configured process may require information that is unavailable at that stage. Alternatively, the team may be avoiding an agreed control.
Observe the actual work before prescribing a solution. Each cause calls for a different response.
When reports are technically correct but commercially misleading
A report can calculate accurately and still answer the wrong business question.
For instance, management may ask for branch profitability while some expenses remain unallocated. A sales report may include invoices but exclude credit notes. An inventory report may show physical stock when sales needs stock available after reservations.
Before questioning the figures, agree on the report’s meaning:
What is included, what is excluded, which date is used, and which business decision should it support?
Then trace a few transactions into the report. This helps separate a reporting definition problem from a posting or configuration error.
When a workaround has become permanent
Temporary workarounds deserve review when they become routine.
Examples include reversing and reposting transactions to correct recurring account assignments, sharing a powerful user account to bypass permission issues, or entering the same information in several places.
For each workaround, record its purpose, frequency, owner, and effect on other departments.
Some may be resolved through settings or training. Others may require integration, a controlled extension, or a change to the business process. Repeated manual corrections should have an identified cause and a planned resolution.
When the ERP may genuinely be a poor fit
There are situations where the required business capability is unavailable or cannot be delivered within acceptable cost, performance, support, or control requirements.
That conclusion needs evidence.
Ask the implementation partner to demonstrate the requirement using a realistic example. Establish whether the proposed solution uses standard functionality, configuration, an extension, integration, or manual work.
Evaluate the ongoing consequences as well as the initial fix. A heavily customised solution may introduce maintenance and upgrade obligations that the business must be prepared to manage.
Diagnose before replacing
Use a short issue register to organise the review:
| Problem observed | Evidence to examine |
|---|---|
| Stock figures are unreliable | Opening quantities, transaction timing, units, warehouses, and adjustments |
| Credit controls are ineffective | Customer balances, control settings, document routes, and override permissions |
| Department reports are incomplete | Cost-centre assignments, posting rules, and report filters |
| Employees avoid the system | Actual workflow, access, training, usability, and transaction effort |
| A critical requirement remains unmet | A demonstrated gap and the practical options for addressing it |
Assign each issue an owner, a corrective action, and a test that will show whether it has been resolved.
Before approving a replacement ERP, ask your team to demonstrate three recurring failures from beginning to end. Understanding exactly where those transactions break down will help you decide what to fix—and what a replacement would need to do differently.