People and Process Risks That Can Derail an ERP Implementation

Even with a solid plan in place, ERP implementations don’t succeed (or fail) on strategy alone but how people show up to execute it.

ERP changes how work gets done across the entire business. It introduces structure where there used to be flexibility, forces decisions that were once informal, and makes data visible in ways that can feel uncomfortable. Without strong leadership, engaged users and a clear approach to change, that shift can create friction fast.

Here are four people-driven risks that can determine whether an ERP system actually works on the shop floor.

1. WEAK EXECUTIVE SPONSORSHIP

ERP implementations cut across every department, and that means they generate conflict. Production wants one thing, accounting wants another and without someone with the authority and willingness to make a call, decisions stall for weeks.

When executives approve the budget and then disappear, they’re essentially delegating the project to people who don’t have the power to resolve cross-departmental disputes. That’s how implementations drag on and lose momentum.

Common causes:

• Executives approve the budget but do not stay involved. 
• The project is delegated entirely to IT. 
• Department leaders disagree but no one has authority to resolve conflicts.
• The company underestimates how much operational change is required. 

What to watch for:

• Decisions take weeks to get resolved.
• Department heads are protecting their own workflows instead of thinking about the business as a whole.
• Employees treat ERP participation as optional.
• Managers are still running off old reports and side systems.

• Assign an executive sponsor who stays engaged, not just one who signs off.
• Form a steering committee with leaders from key departments.
• Hold department managers accountable for data cleanup, testing and adoption – not just attendance in meetings.
• Communicate regularly about why this project matters.

Example:  When production and accounting disagree on how inventory should flow, that’s a business decision, not a technical one. Someone with executive authority needs to make the call and own the outcome.

2. Limited Frontline User Involvement

The people who use the system every day are the ones who know whether it’ll actually work. Operators, buyers, planners, quality inspectors and shipping staff understand the details that make or break a workflow. Leaving them out of the process guarantees surprises at go live.

A system can look perfect in a conference room and fail completely on the shop floor. The gap between what makes sense on paper and what works in practice is where implementations quietly come apart.

Common causes:

• The project team is made up only of managers, IT and consultants.
• Daily users are brought in only for training at the end.
• Shop floor constraints are not understood during configuration.
• Testing does not include real user scenarios.

What to watch for:

• Operators say the screens don’t match how the work actually gets done.
• Planners are back on spreadsheets within a week of go live.
• Inventory staff don’t trust system quantities.
• Employees avoid the ERP because it slows them down.

What to do instead:

• Build a cross-functional implementation team that includes frontline users, not just managers and IT.
• Select power users who understand daily operations and can train their peers.
• Have real users test real transactions outside of the demo environment.
• Use feedback from the floor to refine workflows before you go live.

Example:  A material handler who knows that rush jobs get staged differently than standard jobs holds information that will affect inventory accuracy. If that detail doesn’t make it into configuration, the system will be wrong from day one. 

3. Poor Master Data Quality

This one deserves a direct statement: if your data is bad, your ERP will be bad.

Inaccurate BOMs generate wrong purchase suggestions. Bad routings produce unrealistic schedules. Outdated inventory balances make MRP untrustworthy. Even the best configuration cannot overcome bad data.

Data cleanup is also the task that frequently gets pushed to the end of the project. It’s unglamorous, time-consuming and requires decisions from people who are already stretched thin. But rushing through it, or putting it off entirely, can quickly undermine the rest of the implementation.

Common causes:

• BOMs have not been reviewed.
• Routings do not match actual production.
• Inventory balances are inaccurate.
• Lead times are outdated.
• Units of measure are inconsistent.
• Customer, vendor and part records contain duplicates.
• Data migration is treated as an IT task instead of an operational task.

What to watch for:

• MRP recommendations that buyers automatically ignore.
• Jobs scheduled with run times nobody believes.
• Inventory counts that don’t match what’s on the floor.
• Users blaming the system for issues that are actually caused by bad input data.

What to do instead:

• Start data cleanup early, not during the final weeks before go live.
• Assign data owners for inventory, BOMs, routings, vendors, customers and costing.
• Run multiple test migrations and compare results against source records.

Example: If a routing says an operation takes 30 minutes but it consistently takes 90, scheduling will overload the workcenter and delivery dates will become a running joke. That’s a data problem, not a software problem. 

4. Underestimating Change Management

ERP changes how people do their jobs. It replaces informal methods with defined processes, real-time transactions and greater accountability. For a lot of employees, that feels threatening, not liberating.

Training that covers what to click without explaining why the process matters produces users who follow steps without understanding them. This results in users who fall back on old habits the moment something doesn’t go as expected.

Common causes:

• Training is scheduled too close to go live.
• Training is generic instead of role-based.
• Employees are told what to click but not why the process matters.
• Managers underestimate how much behavior must change.
• The company does not explain how accurate transactions help the whole business.

What to watch for:

• Employees who continue to use spreadsheets alongside the ERP.
• Transactions entered late, skipped or entered incorrectly.
• Supervisors who don’t trust the dashboards.
• Departments blaming the system for problems caused by inconsistent use.

What to do instead:

• Start change management conversations early, explaining the why, not just the what.
• Train by role, with real scenarios from that person’s actual work.
• Give users time to practice in a test environment before go live.
• Reinforce training after go live, not just before.
• Measure adoption through transaction accuracy, system usage and process compliance.

Example:  An operator who doesn’t understand why labor reporting matters may skip clocking into the correct job. That single missed transaction ripples into job costing, capacity planning, schedule accuracy and performance reports.

When leadership is engaged, users are involved early and the organization understands why change matters, ERP has a chance to take hold. But alignment alone doesn’t guarantee success.

In the third part of this series, we’ll shift to the execution side of implementation – where governance, scope control, timelines and testing determine whether all that planning and alignment actually hold together under pressure.