What is change management in a system implementation?

Change management is the discipline of getting people to actually adopt a new system — through stakeholder engagement, communication, training, early involvement and support — so the organization uses it as intended rather than resisting it, working around it, or reverting to old ways. It's the 'people side' of a project, distinct from the technical build, and it's what turns a delivered system into a used one. A technically excellent system with no adoption delivers none of its expected benefit.

Why is change management important for finance systems specifically?

Because finance teams are often deeply attached to established processes and spreadsheets, work under hard period-end deadlines that make disruption risky, and are professionally risk-averse — all of which raise resistance to a new system. On top of that, the benefit of a finance system only materializes if people use it correctly and consistently; a treasury team that quietly keeps its old spreadsheet defeats the whole investment. Winning genuine adoption is therefore as important as building the system right.

How do you get people to adopt a new finance system?

Involve the actual users early so they shape the system and own it, communicate clearly why the change is happening and what's in it for them, train properly and close to go-live so the skills stick, support intensively through go-live and the first period-end, and recruit respected team members as champions. The goal is for users to understand the reason, feel heard, be competent, and have help when they hit trouble — which is what converts reluctant compliance into real adoption.

Change Management for Finance System Rollouts

A technically perfect finance system fails if the accountants and treasury team don't actually use it. Change management is the discipline of winning that adoption — the communication, training, involvement and support that get people using the new system as intended, rather than resisting it, working around it, or quietly reverting to the old spreadsheet. It's the "people side" of a project, and it's routinely under-resourced next to the technical build — which is exactly why so many technically sound finance systems deliver a fraction of their promised value. You don't get the benefit from a system that's built; you get it from a system that's used.

What it is (and what it isn't)

Change management is about people adopting change. It's easy to confuse with change control — the process for handling scope changes — but they're different disciplines. Change control governs what the project builds; change management governs whether the organization takes it up. This article is about the second.

Why it matters

The benefit case for any finance system assumes people use it correctly and consistently. Every user who resists, works around, or reverts is a hole in that case:

The most expensive finance-system failure isn't a system that doesn't work. It's a system that works perfectly and sits unused while the team keeps running the old spreadsheet in secret.

Adoption is the benefit. A system nobody trusts or uses properly delivers nothing, however elegant the build.

Why finance is especially resistant

Finance rollouts face resistance that many other systems don't:

Attachment to process and spreadsheets. Finance teams often own carefully-built spreadsheets and hard-won processes, and giving them up feels like losing control and expertise.
Period-end pressure. Hard, unmovable deadlines make any disruption genuinely risky — "we can't experiment during close" is a legitimate fear, not just obstinacy.
Professional risk-aversion. Finance people are paid to be careful with numbers; a healthy scepticism of a new system that produces the figures they're accountable for is rational.

Take these seriously. Dismissing them as mere resistance guarantees you'll trigger more of it.

Why people resist

Resistance usually isn't stubbornness — it's a rational response to something real: a loss of control or status, fear of not being able to do the job in the new tool, or the simple fact that the transition period means extra work on top of the day job. Name those honestly and you can address them. Pretend they don't exist and they harden.

How to win adoption

Involve users early. People support what they helped shape. Bring the actual users into the process — requirements, testing, design decisions — so it's their system, not one done to them.
Communicate the why. Explain the reason for the change and, crucially, what's in it for them — less manual drudgery, fewer late nights at close. "Because we're told to" earns compliance, not adoption.
Train properly, and close to go-live. Real training on realistic scenarios, timed so the skills are fresh at go-live — not a rushed session months before or a PDF nobody reads.
Support intensively through go-live. Heavy hypercare, especially through the first period-end — the real test, and the moment doubt either resolves or calcifies.
Recruit champions. Respected team members who adopt early and help peers are worth more than any amount of top-down mandate.

Ownership underpins it

Adoption needs an owner — someone accountable for the organization actually using the system, not just for it being delivered. Without that, change management becomes nobody's job, gets cut under deadline pressure, and the project ships a system into a team that never truly takes it up.

What usually goes wrong

Afterthought. Change management bolted on at the end, when resistance has already set — instead of built in from the start.
Training too late or too little. A token session that leaves users unable to do their job on day one, so they retreat to the old way.
No "why." The change mandated without explaining the reason or the benefit, earning grudging compliance at best.
Ignoring resistance. Treating legitimate concerns as obstruction, which deepens them.
No champions. Relying on top-down instruction with no respected peers modelling adoption.

Involve people early, tell them the why, train them properly, support them through the first hard close, and give adoption a real owner — and change management turns a system that's merely delivered into one that's genuinely used. That's where a finance system's benefit actually lives: not in the go-live, but in the quiet moment months later when nobody's opened the old spreadsheet in weeks.

Part of the Finance Systems Delivery guide. See also cutover and go-live and the cost of unclear ownership. The newsletter sends one finance-systems pattern every two weeks.