Change Management – A Practical Framework for Mid-Market Businesses

Change management has a bit of an image problem, particularly in the mid-market.

Mention it during an ERP project and you can almost see some people thinking about armies of consultants, stakeholder maps, colourful PowerPoints and a programme of workshops that requires its own programme manager.

The alternative is usually the other extreme. We're only a mid-sized business. We'll communicate it, give everyone some training and they'll be fine.

Neither approach is particularly useful.

Mid-market businesses absolutely need change management when implementing ERP or making another significant operational change. They just need it to be practical and proportionate to the size of the organisation.

You probably don't need a change team bigger than your finance department. You do need to make sure the business is genuinely capable of working differently when the new system goes live.

That is the bit I think gets missed.

I've spent more than twenty years around ERP, finance and transformation from both sides of the fence, as a customer and now as a consultant. The technology has changed enormously during that time. The problems that cause projects grief really haven't changed anywhere near as much.

A system can be configured correctly. The data can migrate. UAT can pass. Training can be completed and everyone can celebrate hitting the go-live date.

Then, three months later, the spreadsheets start creeping back in, managers accept the old process because it's quicker, users develop workarounds and finance is still taking ten days to close the month.

Technically, the implementation may have worked.

The change hasn't.

Change management is not a communications plan

I wrote recently that change management isn't simply some comms and a wee bit of training at the end. I still think that is one of the simplest ways of describing the problem.

Communication and training matter, of course they do. But they have specific jobs. Communication helps people understand what is happening and why. Training helps them learn how to work in the new environment.

Neither one can fix a badly designed process, make an unclear decision clear or persuade a manager to stop accepting the old way of doing something.

That is why I think change management needs to be much more closely connected to the actual ERP implementation than it often is.

For a mid-market business, I would concentrate on seven fairly straightforward things.

No complicated acronym. No pyramid. No trademark required.

Just the things I would want to know were happening if it was my business going through the change.

1. Understand what is actually changing

One of the easiest mistakes in an ERP project is to describe the change as the system.

"We're moving from Sage to NetSuite."

That tells me which software is changing. It tells the person processing invoices very little about what is changing for them.

The real change might be that purchase approvals are becoming controlled through workflow. Project managers might now be responsible for maintaining information that finance used to chase through email. Customer data may have one owner instead of five. Month-end activities may need to happen earlier. Local spreadsheets might disappear. Someone who could previously override something informally may no longer be able to.

Those are the changes people experience.

Before getting too excited about communications plans, I would understand which roles are affected, what those people will do differently, what they will stop doing and whether any authority or responsibility is moving.

I'd also ask one question that sounds obvious but often isn't answered particularly well:

Why are we actually making the change?

If the answer is simply because we're implementing a new ERP, we're already in trouble.

The business problem should be understandable without mentioning the name of the technology. Maybe month end takes too long. Reporting cannot be trusted. People are manually entering the same information into several systems. The business has grown and the current setup no longer works. Controls are inconsistent.

Start there.

Otherwise there is a danger that the project becomes very successful at implementing software without being entirely sure what the software was supposed to improve.

2. Involve people while it can still make a difference

I'm a big believer in involving the people who actually do the work.

I'm slightly less enthusiastic about asking them for their opinion once everything has already been configured.

That happens more often than people admit. A process is designed, most of the configuration is done and then somebody demonstrates it to users and asks for feedback. Everyone can now report that the users were "engaged", although changing anything substantial would require a change request, another three weeks and a difficult conversation about budget.

Technically involved. Practically too late.

People who understand the day-to-day operation should be involved during discovery, design, testing and preparation for go-live. They will know the awkward transactions and exceptions that aren't always obvious in a process diagram.

But involving users doesn't mean rebuilding everything they currently do.

If you ask someone how a process should work, it is perfectly natural that they start by explaining how it works today. They've probably spent years learning how to make it work, including all the odd little steps needed to get around the limitations of the current system.

That doesn't mean every step needs a new home.

This is where our adopt before you adapt philosophy comes from. Start with the standard process, understand the real business requirement and only change it when there is a good reason.

Sometimes there absolutely is a good reason. Regulation, customer commitments, competitive advantage and genuinely different operating requirements don't disappear because the ERP has a standard workflow.

But we've always done it this way isn't quite in the same category.

The difficult bit is separating the two.

3. Managers need to manage the change

I think managers are one of the most underestimated parts of change management.

You can have a very good change manager, an experienced implementation partner and a project team producing excellent communications. None of them replaces the employee's manager.

People notice what their managers actually do.

If the business announces that purchase orders must now go through the new approval process but one director continues approving things by email because they're busy, everyone learns something fairly quickly about how mandatory the new process really is.

If users are told UAT is a priority but their manager will not release them from their day job to test, they learn something else.

This is where leadership becomes visible.

Managers need to understand why the change is happening, what it means for their team, what problems people are likely to encounter and which old behaviours they are expected to stop accepting.

They also need to make people genuinely available.

One of my favourites on ERP plans is the subject matter expert who is somehow expected to attend design workshops, validate migrated data, complete UAT, support training and still perform 100% of their normal role.

The project plan says they're available. Their diary appears not to have been consulted.

If someone is important enough to the programme that you need their knowledge, something usually needs to give elsewhere.

That isn't a project-management problem. It is a management decision.

4. Communicate what people actually care about

Telling everyone that the ERP programme remains on track for a Q2 deployment is information.

I'm not sure I would call it change management.

Most employees have much more basic questions.

What does this mean for me? What will I have to do differently? What am I no longer responsible for? Is this going to make part of my job harder? Why are we changing something that works perfectly well from my perspective? Who decided this? What happens when I get stuck?

The answers will also be different depending on who you ask.

A CFO might see stronger controls and better reporting. An accounts payable clerk might see an additional approval step and a greater chance of an invoice getting stuck. Operations might want better stock accuracy while someone in the warehouse sees less freedom to correct something immediately.

Both perspectives can be entirely reasonable.

Good communication doesn't pretend every change is wonderful for everybody. Some changes genuinely make one person's task slightly harder because the organisation wants better control somewhere else.

Explain that.

People are generally more capable of dealing with an inconvenient truth than a polished message that doesn't match what happens when they sit down at their desk.

5. Use UAT to test the business, not just the software

I've always thought UAT is one of the most underused change-management opportunities in an ERP project.

Too often it becomes a fairly mechanical process. There are scripts, somebody clicks through them, results are recorded and eventually a percentage appears on a steering committee slide.

That's useful, but I want to know something more important.

Can the business actually operate?

Give users proper scenarios.

Not only the nice clean transaction used in the demonstration. Give them the disputed invoice, the partial delivery, the customer over their credit limit, the damaged stock, the missing project information and the month-end adjustment that crosses three departments.

Then resist the temptation to stand over their shoulder telling them exactly where to click.

Watch what happens.

If they struggle, understand why. Is the system wrong? Is the process unclear? Is the data poor? Is ownership missing? Was the training inadequate? Is it simply unfamiliarity?

Those are very different problems and they require different responses.

A project can report 95% UAT completion and still not have proven that people can run the business without the project team beside them.

Percentages are lovely things. They fit beautifully on dashboards.

Reality tends to be slightly less cooperative.

6. Train people to do their job, not just use the software

I've sat through plenty of software training that technically covers everything and somehow prepares people for very little.

Click here. Select this. Enter that. Press save.

Useful, but it isn't enough.

Someone in accounts payable doesn't just need to know how to enter an invoice. They need to understand how the invoice process now works.

Where does the information come from? What happens if the purchase order is wrong? Who fixes it? What if the invoice is disputed? What happens next? Who owns the exception? What needs to be complete before month end?

That is the difference between:

Here's how the software works

and

Here's how you now do your job.

For me, training should be role-based and built around the real work people are going to perform. It also needs to happen at the right time.

Train too early and half of it is forgotten by go-live. Train people while the design is still moving and you create confusion. Train them two days before launch and you've given them just enough time to realise how much they don't know.

There is no perfect answer, but there should be a deliberate one.

And please don't treat training attendance as readiness.

If 100% of your users attended training, what you have proven is that 100% of your users attended training.

You haven't proven they can do their jobs.

7. Go-live is where adoption really starts

ERP programmes put enormous emphasis on the go-live date, which makes sense. It's a major milestone and usually the date the board remembers.

But go-live proves that the system has been switched on.

It doesn't prove the business has changed.

The first few weeks are where reality starts properly testing the design. Real invoices arrive, customers behave inconveniently, people forget steps, reporting deadlines appear and all the little exceptions that looked manageable in workshops suddenly turn up at once.

Some issues will be genuine defects. Some will be data. Some will be training. Some will be poor process design and some will simply be people learning.

The important thing is to understand which is which.

If every complaint becomes a system change, you'll quickly customise the system back towards the business you were supposedly trying to change.

If every complaint gets labelled "resistance" or "training", you can leave genuine design problems sitting there indefinitely.

Neither is particularly clever.

You also need to watch for the return of old processes.

Spreadsheets have an astonishing survival instinct. You can remove one during implementation and find three of its cousins living quietly on a shared drive by month two.

Sometimes a temporary spreadsheet or workaround genuinely is needed after go-live. That's fine. Give it an owner, understand the risk and put a date against removing it.

The danger is when the temporary workaround becomes comfortable.

Finance starts reconciling the spreadsheet to the ERP. Managers accept both versions. Nobody wants to switch the old route off because "we'll just keep it for another month".

Six months later you've implemented a new ERP and somehow managed to keep the old operating model as well.

That's quite an expensive way to run two processes.

So what does practical change management look like?

For a mid-market business, I don't think this needs to be complicated.

You need somebody making sure the people side of the programme is connected to design, testing, training and go-live. You need a sponsor who remains genuinely involved. You need managers who understand that they have a role beyond forwarding project emails. You need experienced users who have enough time to contribute properly.

Most importantly, you need to keep asking whether the business is getting ready, rather than simply whether the project is completing activities.

There is a difference.

I would rather see a mid-sized company do those basics properly than implement a perfect enterprise change methodology with 40 deliverables that nobody outside the project team ever looks at again.

A few questions I'd ask before go-live

If I was sitting with a CFO, COO or project sponsor a few weeks before launch, I wouldn't only ask whether configuration was complete, UAT had passed and training was on schedule.

I'd want to know what people will stop doing once the new system goes live. I'd ask which responsibilities have moved and whether the people affected actually understand that. I'd want to know whether users can complete the difficult end-to-end processes without someone from the project team talking them through them.

I'd ask whether managers are genuinely prepared to stop accepting the old processes when pressure arrives, because that is normally when the real test comes.

I'd also want to know what success should look like three or six months later.

Has month end reduced from ten days to five? Have manual reconciliations disappeared? Is stock information more reliable? Are approvals quicker? Has the spreadsheet the project was supposed to remove actually gone?

Because that is ultimately what the investment was for.

Not a successful go-live.

A better business.

Keep it practical

Change management shouldn't become bureaucracy for the sake of bureaucracy.

But dismissing it because you're a £20m, £50m or £100m business rather than a multinational doesn't make the underlying problem disappear.

People still need to understand what is changing. Managers still need to lead it. Processes still need owners. Users still need proper involvement and training. The business still has to stop doing some things it has probably done for years.

ERP can support all of that.

It can't make those decisions for you.

That is why I think practical change management in the mid-market comes down to something fairly simple: understand the change, involve the right people, prepare managers, communicate honestly, test the real business, train people for their jobs and keep managing adoption after go-live.

You just need to actually do it.

Because the shiny new system is rarely the hardest bit.

Getting everyone to stop using the spreadsheet they've trusted since 2017?

That's usually where things get interesting.