ERP Resistance to Change Is a Capacity Problem

BusinessHub is an Australian ERP consulting and implementation partner specialising in MYOB Acumatica, Wiise and Microsoft Dynamics 365 Business Central. We help manufacturers, distributors, construction, food and beverage, not-for profits and project-based businesses select, implement and optimise cloud ERP systems.

One of the most common explanations for a struggling ERP project is “resistance to change”.

Finance isn’t engaging enough. People keep missing workshops. Testing is behind. And training attendance is patchy at best. Then there's the key users aren't contributing like they did at the beginning.

So the response is predictable. More communication. Another workshop. A champion network. More reminders about why the project matters. 

Sometimes that's exactly what's needed.

But after more than 20 years implementing ERP and payroll systems across Australian mid-market businesses, we believe that a lot of what gets labelled resistance isn't resistance at all. It's capacity. The people aren't necessarily unwilling to change. They simply have no room left in their working week to do it.

And that's a very different problem.

What “resistance” looks like when you get closer

Take the project status report out of the equation for a moment and look at what's actually happening inside the business.

Your payroll officer has a fortnightly pay run due. They also have user acceptance testing scheduled for the same week. One of those activities can move. The other can't.

People still need to be paid correctly and on time, so testing gets pushed into whatever gaps remain. A couple of hours here. An hour there. Perhaps some testing after everyone else has gone home.

Then defects are missed, and the project results in  incomplete testing. 

Or consider the accounts payable lead. She's processing 200 invoices, answering supplier queries and dealing with the exceptions that never quite fit the documented process.

At the same time, she's been asked to map approval workflows for the new ERP. She knows those workflows better than anyone. But the workshop doesn't stop the invoices arriving.

So the process gets mapped quickly, often from memory, and the edge cases that matter most are exactly the things most likely to be forgotten.

Then there's the financial controller.

They're in nearly every design workshop because they're one of the few people who truly understands how the chart of accounts, reporting structure and month-end processes fit together.

The ERP project takes their afternoons and their existing role takes the rest of the day.

The reality is that month-end hasn't disappeared because there's an ERP implementation happening. So they finish it at 9pm.

Do that for eight weeks and something predictable happens. They stop challenging decisions. They contribute less in workshops. They miss a session.

The project report calls it declining engagement. They call it exhaustion.

The irony is that your “resistors” may be the people who wanted ERP most

This is the part most businesses often miss. The people who appear most resistant during an ERP project are often the people who were most frustrated with the old system.

They're the ones who know the workarounds. They're exporting spreadsheets. They're reconciling things manually. They're entering information twice.

They're fixing the reporting at month-end.

They wanted the new system because they understand better than anyone why the old way of working isn't sustainable.

Then the ERP project arrives and we effectively say:

Keep doing all of that. Now help us replace it as well.

And when they struggle, it gets called resistance to change, and from our experience, it's not a particularly fair diagnosis.

The project plan sees availability. The business experiences workload.

Part of the problem is that the day job is largely invisible on an ERP project plan. The plan shows:

• discovery
• design workshops
• data migration
• user acceptance testing
• training
• cutover
• go-live.

What it often doesn't show is:

• payroll next Thursday
• month-end close
• BAS preparation
• year-end
• the auditor's questions
• 200 invoices waiting for approval
• the supplier who needs to be called back
• today's customer issue.

On paper, someone might only have six hours of ERP workshops that week. But in reality, those six hours might be the six hours that previously kept their ordinary workload manageable.

To the project, the finance team has capacity. To the finance team, they've just been given a second job.

Why do we call it resistance?

Because “resistance” is a surprisingly convenient diagnosis. If employees are resisting change, the solution sits with the employees.

Train them. Communicate better. Engage them. Motivate them. Appoint champions.

But if the problem is capacity, the conversation becomes less comfortable. Now we have to ask whether the project was realistically resourced in the first place.

Did we actually allocate enough internal time? What work was supposed to stop? Who was supposed to pick it up?

Why did we approve $X for implementation but assume hundreds of hours of internal effort would somehow appear for free?

Calling it resistance creates a people problem. Calling it capacity creates a management problem. And this may be the one reason we don't talk about it enough.

There is another issue: overloaded people don't always say they're overloaded

This is particularly relevant in mid-market businesses.

In a company of 80, 150 or 300 people, there often isn't another financial controller sitting nearby who can take over for a few months.

The payroll officer might be the payroll officer.

The finance manager might hold years of institutional knowledge that has never been fully documented. These people are used to making things work.

So when the ERP implementation lands on top of their existing responsibilities, they don't necessarily walk into the MD's office and announce that the plan is unrealistic.

They compensate. They work later. They move things around. They skip something. They turn up to the workshop anyway. Until eventually they can't.

From the steering committee's perspective, engagement has mysteriously declined. From their perspective, they've been quietly absorbing an unrealistic plan for three months.

You don't fix a capacity problem with another workshop

Change management absolutely has a role in ERP implementation. People need to understand why processes are changing. They need training. Communication matters. Leadership matters.

But there comes a point where another PowerPoint deck isn't going to create another six hours in someone's week.

If capacity is the problem, something has to come off the desk.

Before an ERP project starts, critical project participants should be able to answer one deceptively simple question:

What will I stop doing while I'm working on this project?

If the answer is nothing, there's a problem. If the answer is someone else will pick it up, ask who.

If the answer is we'll just make it work, that's not a resourcing strategy. That's goodwill.

And from our experience, ERP implementations can burn through goodwill surprisingly quickly.

Fund the capacity, not just the software

When businesses construct an ERP business case, most of the visible numbers are easy to identify. Software. Implementation. Integration. Migration. Consulting. Training. Perhaps contingency.

Internal capacity is harder to put on a purchase order, which means it's also easier to underestimate.

But your own people's time is a real implementation cost.

If your financial controller is spending a day or two each week on the project, that capacity has to come from somewhere.

Sometimes the answer is temporary backfill.

For example, a payroll contractor, an additional AP resource, or a short-term finance resource.

Sometimes responsibilities can be redistributed internally.

Other times, project activities simply need to be scheduled more intelligently around the finance calendar.

The specific solution matters less than acknowledging the constraint.

Because there is a strange economics to ERP projects where businesses will protect the implementation budget while being reluctant to spend comparatively modest amounts creating the internal capacity required to make that investment successful.

That's backwards.

Put the finance calendar into the ERP plan

There's another practical suggestion we make to almost every implementation plan. Overlay the project plan with the finance calendar. Not afterwards.

Before the main project schedule is agreed.

Mark:

• payroll cycles
• month-end
• quarter-end
• BAS periods
• annual audit commitments
• financial year-end
• major operational peaks.

Then look at where your workshops, testing and cutover actually sit.

User acceptance testing in payroll week? Move it.

Critical design workshops during month-end? Move them.

A major finance milestone immediately before year-end? At least acknowledge what you're asking of the team.

An ERP implementation happens inside a functioning business. So the implementation plan needs to recognise that.

Three questions to ask before approving an ERP budget

1. Who are the five people this project cannot succeed without?

Not the project team generally. The actual people whose knowledge, testing and decisions are critical.

2. What is coming off each of their desks?

Be specific. If the answer is nothing, you haven't created capacity.

3. Where is the cost of creating that capacity in the business case?

If everyone agrees these people are critical but there is no provision for backfill, workload reduction or additional support, there's a disconnect. The ERP budget may have been approved, but the ERP project hasn't really been funded.

Maybe “low engagement” should trigger a different question

So the next time an ERP steering committee sees that engagement is medium, perhaps the first response shouldn't be "how do we get the team more engaged?", maybe it should be how much capacity do they actually have?

Look at their calendars. Look at payroll. Look at month-end. Look at what else they're responsible for. Look at their hours. Then decide whether you're dealing with resistance.

Because if someone wanted the new ERP, understands why it's necessary and is working until 9pm trying to make the implementation succeed, another change-management session probably isn't the intervention they need.

They need Tuesday afternoon back.

The real commitment isn't the budget

Approving an ERP budget feels like the big decision. But in our experience, it isn't.

Creating the organisational capacity to implement it is the real commitment. The businesses that get this right aren't necessarily the ones with the biggest transformation teams or the most elaborate change programmes.

They're the ones prepared to make an uncomfortable decision before the project begins:

If we're asking our best people to help build the next version of the business, what are we going to stop asking them to do while they build it?

Planning an ERP project? Talk to BusinessHub

If you're planning an ERP project and want a second opinion on whether your implementation plan reflects the capacity of the people who actually have to deliver it, talk to the BusinessHub team.

We can help you work out what the project will really require before a capacity problem starts appearing in steering committee reports as “resistance to change”.