An ERP project often begins with high expectations.
Management expects better visibility. Finance wants more reliable information. Operations wants fewer manual processes. Different departments expect the new system to finally connect the business.
Then the implementation begins.
Teams disagree about how processes should work. Data requires more cleaning than expected. Reports produce numbers that people still question. Users continue relying on spreadsheets. Decisions that should have been settled early in the project keep being escalated.
Eventually, the ERP system becomes the easiest thing to blame.
But the software may not be where the problem started.
In many transformations, ERP does something uncomfortable but valuable: it exposes business problems that the organization has learned to work around.
The real question for management is therefore not simply:
“Is our ERP system good enough?”
It is:
“Is the business clear enough about how it wants to operate for any ERP system to succeed?”
ERP does not fix an unclear business
ERP systems require companies to translate the way they operate into processes, rules, responsibilities and data.
That means decisions need to be made.
Who owns a process?
Who approves what?
Which steps should be standardized?
Which exceptions are genuinely necessary?
When does responsibility move from one department to another?
Which information should management rely on?
If the organization has never clearly answered these questions, the ERP implementation often becomes the place where those unresolved issues finally surface.
A disagreement between Sales, Finance and Operations about when an order is considered confirmed, for example, may initially appear to be a workflow configuration problem.
It is not.
The software is asking the company to define a business rule that the company itself has never fully agreed upon.
A configuration decision should not become a substitute for a management decision.
This is consistent with long-standing academic research into ERP implementation. A broad review of ERP studies across multiple countries identified factors such as business vision, business-process redesign, change management, top-management support, data management and fit between the ERP and business processes among the critical factors associated with successful implementation. ScienceDirect
The technology matters. But so does the organization surrounding it.
Technology often exposes problems that were already there
Many inefficient business processes survive because experienced employees know how to compensate for them.
A finance employee maintains an additional spreadsheet because certain numbers need manual reconciliation.
A warehouse supervisor knows which inventory quantities should not be trusted.
Sales contacts Operations directly whenever the standard process becomes too slow.
Managers receive reports but verify important numbers separately before making decisions.
These workarounds can keep the organization functioning.
They can also hide weaknesses in the operating model.
ERP makes many of these informal arrangements more visible because processes that previously depended on individual knowledge must now become explicit.
The implementation suddenly forces questions such as:
What is the correct process?
Which system contains the authoritative data?
Who is responsible for maintaining it?
Which exceptions should continue?
Who has authority to make the final decision?
What appears to be resistance to an ERP system may therefore sometimes be the organization discovering how heavily its previous way of working depended on individual knowledge, manual intervention and undocumented exceptions.
Start with business outcomes, not software requirements
ERP projects frequently begin with requirements.
“We need better inventory functionality.”
“We need purchasing automation.”
“We need more dashboards.”
Those requests may be valid, but they are one level too early.
A transformation-oriented conversation asks why the capability is needed.
Instead of:
“We need a better inventory module.”
Ask:
“Why can management not reliably determine what inventory is actually available?”
Instead of:
“We need more automated purchasing.”
Ask:
“Why are purchasing decisions currently slow, inconsistent or difficult to control?”
Instead of:
“We need better dashboards.”
Ask:
“Which important decisions are managers unable to make because the information they receive is late, inconsistent or unreliable?”
This distinction matters because implementing functionality is not the same as delivering business value.
Deloitte's 2025 research with 26 CFOs and finance-transformation teams found a similar challenge: broad transformation ambitions can become secondary as implementation progresses and go-live itself becomes the dominant milestone, rather than the meaningful improvements the investment was intended to create. Deloitte
PwC has made a related observation around cloud ERP: organizations may embark on ERP transformation expecting improved processes and productivity, yet uncertainty about ROI and the benefits being pursued can become a significant barrier. PwC
The implication is important:
ERP objectives should be expressed as business outcomes before they are translated into system requirements.
Five signs the problem may not be your ERP
1. Different departments describe the same process differently
Ask Finance, Sales and Operations to explain the complete order-to-cash process.
If you receive three significantly different answers, the implementation team will eventually have to reconcile them.
That is not primarily a software issue.
It is a process-alignment issue.
2. Nobody owns the complete process
Businesses are often managed department by department.
But many important processes are not departmental.
Order-to-cash crosses Sales, Operations, Logistics and Finance.
Procure-to-pay crosses requesting departments, Purchasing, Warehouse and Finance.
Inventory accuracy can involve Procurement, Warehouse, Production, Sales and Finance.
When responsibility ends at departmental boundaries, problems between those departments can remain unresolved.
ERP does not automatically create process ownership.
Management does.
3. Every existing exception must be preserved
One of the most dangerous implementation requirements is:
“The new system must work exactly like our current process.”
Sometimes that is necessary.
Sometimes it means the organization is reproducing historical complexity inside a new system.
If every exception, approval path, workaround and special case becomes a customization requirement, the company should ask why those exceptions exist before deciding that they must continue.
Digitizing an inefficient process simply creates a digital inefficient process.
4. Data is considered an IT responsibility
Customer information, product structures, suppliers, prices, units of measure, inventory definitions and accounting structures may live inside technology.
But their meaning belongs to the business.
IT can manage the platform.
It cannot independently decide which customer record is correct, how products should be categorized or which commercial rule management intends to follow.
Poor business-data ownership therefore becomes an ERP problem only after the system begins exposing it.
5. Success means “we went live”
Going live matters.
But it is a project milestone—not necessarily a business result.
A stronger definition of success might include:
- improved inventory accuracy
- faster month-end closing
- fewer manual reconciliations
- shorter order-processing times
- more reliable management information
- fewer process exceptions
- stronger control and accountability.
This is also why change management matters beyond training people where to click.
Prosci's research reports that projects with excellent change-management practices are substantially more likely to meet or exceed their objectives than projects with poor change management. The research emphasizes adoption, sponsorship and the ability of people to use the new way of working—not simply deployment of the technology. Prosci
Successful ERP transformation starts before implementation
A useful way to think about ERP transformation is:
Direction → Process → Ownership → Data → Technology → Adoption → Business Outcome
Deloitte's business-led ERP transformation approach reflects a similar principle, emphasizing operating-model and process alignment throughout the ERP journey rather than treating them as separate activities surrounding the technology. Deloitte
When is the software actually the problem?
None of this means ERP software is never responsible for implementation difficulties.
Sometimes the technology genuinely is wrong for the business.
For example:
- important industry requirements cannot reasonably be supported
- integrations are unstable
- the architecture cannot support expected scale
- extensive customization has made the environment difficult to maintain
- localization or regulatory requirements are inadequate
- poor system performance disrupts normal operations.
These are legitimate technology concerns.
The difficulty for management is distinguishing them from problems that would exist regardless of which ERP product was installed.
A useful diagnostic question is:
“If we replaced the ERP tomorrow, which of our current problems would still remain?”
If departments would still disagree about processes, ownership would remain unclear, data would still be inconsistent and managers would still rely on manual workarounds, replacing technology alone may simply move the same problems into a different system.
Seven questions leaders should ask before investing more in ERP
Before replacing an ERP, significantly customizing it or committing to another major implementation, leadership teams should be able to answer seven questions.
1. What business outcome are we expecting ERP to improve?
Not which module is being implemented. What should become measurably better?
2. Which processes currently depend on workarounds or individual knowledge?
Those are likely to become transformation risks.
3. Do departments agree on how important cross-functional processes should work?
If not, alignment needs to happen before configuration becomes the battleground.
4. Who owns each end-to-end process?
There should be someone capable of making decisions across functional boundaries.
5. Which data does management trust today?
And where does the organization maintain competing versions of the truth?
6. Are we improving our processes or reproducing them?
Existing practices should not automatically become future-state requirements.
7. How will we measure success six or twelve months after go-live?
If the answer is simply “the system is running,” the business case may not yet be clear enough.
ERP should support transformation, not define it
ERP can provide a powerful foundation for control, scalability, visibility and growth.
But technology cannot independently resolve unclear responsibilities, conflicting business rules, poor-quality data or inconsistent processes.
In many organizations, the ERP implementation does not create these problems.
It simply makes them harder to ignore.
That is why the strongest ERP programs should not begin solely by asking:
“Which system should we implement?”
They should begin by asking:
“How should our business work—and what needs to change for technology to support it effectively?”
When that question has been answered properly, ERP becomes an enabler of transformation rather than an expensive attempt to compensate for issues elsewhere in the organization.
References
Ngai, Law & Wat, “Examining the critical success factors in the adoption of enterprise resource planning,” Computers in Industry. ScienceDirect
Deloitte, “Bridging the gap in ERP implementation,” 2025. Deloitte CFO Insights
PwC, “Go beyond the tech: How value-based cloud ERP can help drive greater business performance,” 2024. PwC ERP perspective
Prosci, Change Management Research. Prosci change-management research