ERP User Adoption: The Human Factor That Determines Whether ERP Succeeds

2026-09-24

Executive Summary

• ERP software does not change human behavior — and if people do not change how they work, ERP does not generate value.
• Employee resistance to ERP is rarely about attitude. It usually reflects legitimate concerns that the organization has not adequately addressed.
• Software training and change management are different things. Most ERP projects only do the first.
• User adoption needs to be prepared for before go-live — not addressed after the problems have already appeared.

When the Software Works But the Organization Doesn’t Change

There is a pattern that many CEOs and operations leaders recognize after ERP go-live:

The system is running. Servers are up. Employees log in. But several months later, the majority of actual work is still being handled through spreadsheets, email, messaging apps, and the same methods people used before ERP existed.

Data in ERP is incomplete or inaccurate. Reports from ERP are not used for decisions. And gradually, the organization settles into an implicit understanding: ERP is something you enter data into to satisfy a requirement — not something that actually helps people do their jobs.

This is not a technical failure. This is a user adoption failure.

And it is far more common than ERP project retrospectives tend to acknowledge publicly.

Why Employees Resist ERP

Before addressing solutions, it is important to understand the problem accurately.

Resistance to ERP is commonly labeled as “negative attitude” or “unwillingness to change.” But on closer examination, most resistance originates from concerns that are entirely legitimate and that the organization has not adequately resolved.

“The new system is more complicated than how I currently work — and I don’t see any benefit for me personally.”

This is the most common and, frankly, most rational concern. For end users, ERP frequently adds steps to tasks they previously performed more quickly in a familiar way. The old method — however poor it was from an organizational standpoint — felt faster and easier.

If the organization cannot articulate clearly what the end user personally gains from following the new system — not what the business gains, but what they gain — resistance is the natural outcome.

“I’m not sure I’m doing this correctly — and I’m worried about making mistakes.”

ERP, particularly for those unfamiliar with enterprise systems, can generate genuine anxiety: what if I enter something wrong, approve something incorrectly, or accidentally affect another department’s workflow? This concern is rarely voiced openly but is far more prevalent than ERP project teams typically see.

When training is insufficient and there is no accessible support when problems arise, the safest strategy is to avoid using the system or enter only the minimum required.

“The data in the system isn’t reliable — so why should I use it?”

This is a self-reinforcing cycle: when not enough users are using the system correctly, ERP data is incomplete and inaccurate → other users do not trust the data → they continue using older methods → ERP data quality deteriorates further.

Once established, this cycle is very difficult to break.

“I don’t have time to do my job and learn a new system simultaneously.”

Employees in manufacturing environments typically operate under significant daily operational pressure. Adding ERP to that context — without temporarily reducing workload or providing adequate transition support — creates a situation where users feel caught between two systems, with no one effectively managing either.

Three Common Patterns of Resistance

Resistance does not always present itself clearly. There are three patterns most commonly encountered:

Passive resistance. Employees use the system at the bare minimum — entering enough data to avoid complaints while maintaining parallel spreadsheets, notebooks, and informal processes alongside. ERP data exists but cannot be relied upon.

Quiet workarounds. Employees find ways to operate outside the system — asking managers to handle things off-system, having colleagues enter data on their behalf, or developing unofficial parallel processes the system is unaware of. This pattern is the hardest to detect precisely because it generates no explicit complaints.

Open resistance. Employees — typically middle managers — complain openly about the system, asserting that it is not suitable, too complex, or inferior to previous methods. This is the most visible pattern but also the one most likely to spread and affect the attitudes of others.

All three patterns have the same consequence: ERP does not reflect operational reality, and the value of the system deteriorates over time.

Common ERP Training Mistakes

Training is typically treated as the solution to user adoption problems. But most training as actually implemented does not address the real problem.

Training happens too late. Many projects train end users immediately before go-live — one or two weeks before the system officially launches. At that point, deadline pressure is high, there is insufficient time for practice, and users have no opportunity for follow-up after training ends.

The result: users go live with low confidence and no clear path for support when they encounter problems.

Training is delivered as a software demonstration. The implementation partner shows how the system works in a demo environment. Users watch and nod. But watching a process being performed in a demo environment is entirely different from performing it yourself in a real work context.

People do not learn by watching. They learn by doing, making mistakes, and receiving correction.

Training is disconnected from actual work. Users are taught how to create a Purchase Order in the demo system, but are not guided through the organization’s specific process — who needs to approve it, when it needs to be created, what documentation needs to be attached.

The result is users who understand the software technically but do not know how to use it in the context of their actual job.

No support after training ends. Even with good training, users will encounter situations not covered in training once they begin using the real system. Without a clear support channel — who to ask, how to reach them, what response time to expect — users resolve problems on their own, which usually means avoiding the system.

Change Management Is Not Software Training

This is the most important distinction that most ERP projects fail to make.

Software training answers the question: “How do I perform action X in the system?”

Change management answers the question: “Why should I change how I work, and what does this change mean for me?”

The second question needs to be answered before the first. If users do not understand why, knowing how is not sufficient to produce lasting behavioral change.

Elements of change management that actually work:

Early, clear communication. Before the project begins, employees need to know how the new system will affect their day-to-day work, what the timeline looks like, and how they will be supported through the transition. Without information, people fill the gap with assumptions — which tend to be more negative than reality.

Benefits explained from the end user’s perspective. “The new system gives the business better reporting” is not a reason for an end user to change how they work. “The new system means you don’t have to wait for email approvals and you can track orders in real time” is different.

Super users — internal champions who know the system well. Identifying and training a small group of internal users to become deep system users who can support colleagues in daily work creates a sustainable support mechanism that is far more effective than relying on the implementation partner.

Leadership uses the system visibly. When the CEO, COO, or department managers request reporting from ERP rather than from spreadsheets — when they ask questions based on system data — that is the strongest signal the organization can send about the seriousness of ERP adoption.

Safe space for practice and mistakes. A sandbox environment or parallel run period — allowing users to practice with real data in a real system without fear of consequences — substantially reduces anxiety about making mistakes and builds confidence before go-live.

Self-Assessment

• Do your employees know where the ERP project stands in the timeline and how it will affect their specific jobs?
• Can you articulate the concrete benefits of the new system from the perspective of each user group?
• Is there a hands-on practice plan — not just a demonstration — before go-live?
• Has a super user been designated for each department?
• Is leadership committed to using ERP as a decision-making tool after go-live — not just treating it as an IT system?
• Is there a clear support channel for users who encounter problems after go-live?

→ Related: When a Key Employee Leaves, What Do They Take With Them? — on knowledge retention

→ Complete the ERP Readiness Assessment

→ Explore ERP Readiness Solutions

For customization impacts on user adoption, see: ERP Customization Risks

To understand accounting readiness after adoption challenges, see: Accounting Readiness for ERP — A CFO’s Preparation Checklist

For the foundational perspective, see: Why ERP Projects Fail

This article is part of a series on ERP readiness for manufacturing SMEs.

Related articles:

• Why ERP Projects Fail — and What the Software Cannot Fix
• Process Standardization Before ERP: The Step Most Companies Skip
• When a Key Employee Leaves, What Do They Take With Them?