Why Your Field Workforce Will Resist Your ERP Implementation
- Jun 7
- 6 min read
And why that resistance has nothing to do with the system.
There is a belief that runs through almost every ERP implementation. It is rarely stated out loud, but it shapes every decision about change management, training, and communication.
The belief is this, once the workforce sees how good the system is, they will come around.
It sounds reasonable. The system is better. The processes are cleaner. The data is more accurate. Why would anyone resist something that makes their job easier?
Here is why. Because that is not how people experience change. And the organizations that build their adoption strategy around "they'll see the value eventually" are the ones six months after go-live wondering why their team is still running spreadsheets.
Workforce resistance is not a technology problem. It is not a training problem. And it is almost never a personality problem. It is an organizational signal and most implementation teams are not reading it correctly.
Resistance Is a Signal, Not a Personality Trait
When a technician pushes back on a new work order process, the instinct is to categorize it. Difficult employee. Change resistant. Not a team player.
That categorization is wrong and it is expensive.
Experience working across defense, energy, government, and field service operations, resistance compounds from three directions simultaneously. Most project teams only see one of them usually the most visible one and address it in isolation. The other two keep building.
The personal why was never answered. Not the project why. Not the business case. The personal why. Why does this change make this specific technician's job better? What does it do for the person who shows up at 6 AM, manages a work order backlog, and has been doing this job the same way for years?
If that question was never asked and, in most implementations, it never is the system will always feel like something happening to the workforce rather than something built for them. Awareness of the change is not the same as understanding the personal impact. And understanding the personal impact is not the same as believing it.
The workflow was never questioned. ERP systems get configured around existing processes. The assumption is that the process is correct and the system needs to support it. But operations accumulate workarounds over years informal fixes, manual steps, Excel trackers that nobody officially sanctioned but everyone depends on. By the time an implementation arrives those workarounds have become the process.
When the system replaces the workaround without addressing what the workaround was solving, the workforce loses something that was actually working. Their resistance is not stubbornness. It is institutional knowledge trying to surface. The people closest to the work often know something the project team does not and resistance is how that knowledge shows up when nobody asked for it directly.
Leadership assumed buy-in without earning it. A go-live announcement is not a prepared workforce. A town hall is not engagement. When field teams learn about significant process changes the same week their training starts, they have not been given time to process. They have been given a reason to distrust the entire initiative.
Buy-in is not something that can be communicated into existence. It is built through early involvement, honest conversation, and demonstrating that the people doing the work had genuine input into how the work gets done. When that foundation is skipped because the timeline is tight, because leadership assumed the workforce would follow the resistance that surfaces later is not irrational. It is the predictable outcome of a process that never included them.
These three things do not show up separately. They compound. And by the time resistance becomes visible in your data low system utilization, rising help desk tickets, workarounds multiplying all three have typically been building for months.
What It Looks Like Before Anyone Flags It
The costliest form of field resistance is the kind that has not been named yet.
Before a single ticket gets logged. Before a supervisor escalates to the project team. Before anyone uses the word resistance at all the signals are already there in how people engage with the project in its earliest stages.
Watch who asks questions in early project meetings and who goes quiet. The technician or supervisor who stops engaging is not disinterested. They have already made a private assessment about whether their voice matters in this process. That assessment was formed quickly and it will take deliberate effort to reverse.
Watch the language people use when they talk about the project. Whether they describe the system as something the organization is building or something being done to them. Language reflects ownership and ownership reflects whether the personal why was ever answered.
Watch what happens when a concern gets raised and leadership moves past it. Every person in that room notices. Every time. And they recalibrate their willingness to raise the next concern accordingly.
These are not soft observations. They are leading indicators of adoption outcomes. Organizations that catch them early have options. Organizations that catch them at go-live are in recovery mode.
What Leaders Get Wrong When They See It
When resistance becomes visible most leadership teams respond in one of three ways.
They add training. More sessions, simplified materials, additional support resources. Training has its place but it does not address why people are resistant. It addresses whether people know how to use the system. Those are different problems with different solutions.
They increase communication. More updates, more town halls, more project status emails. Communication volume is not the same as communication quality. Telling people more about a change they did not feel included in does not build trust. It confirms that the process is being done to them.
They wait it out. This is the most common and most damaging response. The belief that resistance is a phase that people will come around once they experience the system leads organizations to defer the real work until it becomes a crisis. Resistance that is not addressed early does not resolve itself. It hardens. It becomes the culture of how the system gets used. Or more accurately how it does not get used.
The workforce was never going to come around on its own. That was never a strategy. It was an assumption that substituted for one.
What Actually Works
The organizations that navigate resistance successfully do not wait for it to surface. They go looking for it early before the first workshop, before the system is configured, before the training plan is written.
They start with the personal why. Not as a communication exercise but as a genuine question. What does this change mean for the people doing this specific job? Where will it make their work harder before it makes it easier? What are they worried about that nobody has asked them yet? The answers to those questions shape every subsequent decision about how the implementation gets rolled out.
They treat the field workforce as a source of intelligence. The technicians and supervisors who have been running operations for years carry institutional knowledge that no requirements document captures. Engaging them early genuinely, not performatively surfaces the workarounds, the informal processes, the real requirements that the formal process missed. It also builds the ownership that no amount of post-go-live communication can manufacture.
They name the short-term pain honestly. The organizations that handle upgrade friction best are the ones that told their teams to expect it. Not as a warning but as a plan. Here is where it will be hard, here is why, here is how long it will last, here is what we are doing to support you through it. When friction arrives and leadership already named it, the team moves through it. When it is a surprise they build workarounds.
They close the loop on concerns. When a field supervisor raises an issue and sees it addressed even if the answer is we considered it and decided not to change it for this reason trust builds. When concerns disappear into the project team and never come back, the message received is that the input was not real. That perception is nearly impossible to reverse after go-live.
The Compounding Return of Getting This Right
Field resistance is not inevitable. It is predictable. And because it is predictable it is addressable but only if you are looking for it before it becomes visible in your adoption metrics.
The organizations that get this right do not just avoid adoption failure. They build something more valuable. A workforce that has been through real change, moved through the friction, and came out on the other side with ownership of the system. When the next process improvement arrives when the next IFS Cloud release brings new capabilities, when the next initiative asks them to change again the conversation is easier. Because the organization has already proven to itself that it can do this.
That compounding return does not come from a better training program or a more detailed communication plan.
It comes from asking the right questions before anyone opens a requirements document.