ERP change management: how to bring your people along before go-live

Most ERP implementations focus on configuration, data and planning. Understandably so, because those elements determine whether the technical go-live succeeds. What still produces unwelcome surprises after the launch is something else: the people.

Employees who work around the system on purpose. Key users who, after their training, remain unsure what they should actually be doing. Managers who, two weeks after launch, ask for a temporary Excel workaround alongside the new ERP. ERP change management is the discipline that prevents this, but in practice it starts too late or stays too superficial to make a real difference.

This article explains what ERP change management means in practice, how you organise it before go-live, and which pitfalls hit organisations that do not give it enough attention.

Why change management is more complex for ERP than for other IT projects

ERP systems touch daily work processes differently than, say, a new reporting tool or a CRM replacement. Someone using a new dashboard application adjusts their routine. Someone using a new ERP system often has to rethink their entire work process: different screens, different steps, different terminology, sometimes a different logic behind the actions.

That makes ERP change management more substantive than generic organisational change. It is not only about communication and training days. It is about understanding how people work today, why they work that way, and how the new system fits or does not fit that reality.

ERP Company supports organisations with ERP projects as an independent consultancy. With 265+ specialists in different roles, ERP Company sees that the technical implementation is rarely the cause of failed adoption. The cause almost always sits in the change track: started too late, without a clear owner, or too generic in approach.

The three most common mistakes in ERP change management

Treating change management as a separate phase. It is not a phase you can schedule after testing. It runs in parallel with the entire project, from the first communication about the project until at least four weeks after go-live.

Scheduling training only after go-live. By that point the change is already a fact, and training feels like repair work. Employees who only learn the new system after launch start with a backlog. They watched the system arrive without being ready for it.

Naming key users without freeing them up from their regular work. Then they deliver nothing for the project, get stressed themselves, and lose credibility with colleagues who notice that the key user is also struggling to keep up.

When does ERP change management start?

The honest answer: at the first meeting about the project. Not at the project kickoff. Not at the training. At the moment a director says: “We are going to implement a new ERP system.”

That is the moment when the picture starts forming inside the organisation. Who has heard something about it? Who is worried? Who thinks their work is going to change? If you do not answer those questions, the rumour mill will. And rumours are rarely positive.

Early communication does not need to be detailed. “We are going to do this, we will keep you informed, and you will hear from us what it means for your department” is enough to set the tone.

The role of key users in ERP change management

Key users are employees who get to know the new system before the rest of the organisation. They are the bridge between the project team and the shop floor: they translate technical configuration choices into daily working practices, and they bring feedback from the floor back into the project.

But that bridge only works if you arrange four things well.

Choose key users on influence, not on availability. The most motivated colleague with little standing in their team is less effective than a slightly less enthusiastic employee whom everyone respects. Informal authority matters as much as formal position.

Give them real room in their schedule. A key user who spends 90% of their time on regular work has no capacity left for the project. That leads to shallow involvement and key users who do not live up to their role, not from unwillingness, but from lack of time.

Involve them early in configuration choices. Key users who only train and have no input on configuration experience the system as imposed. Key users who help shape work processes and choices take ownership. That difference in ownership shows up later on the shop floor.

Recognise them visibly within the organisation. In a culture where project work is seen as extra burden, you ask key users to give up part of their primary role. If managers do not visibly value that contribution, motivation is hard to sustain across an implementation that runs six to eighteen months.

ERP change management in five practical steps

Step 1: impact analysis per department

Map which departments are most affected by the system change, and how. That differs by organisation and by implementation. In a distribution setting the impact on warehouse and purchasing differs from a services business, where the impact lands hardest on project administration and invoicing.

An impact analysis lets you focus scarce attention. Not every department needs the same level of change support. Energy goes to where work processes change most.

Step 2: a communication plan with honest messages

Communicate early and regularly about the project, even when there is little to report. In organisations, silence gets filled with assumptions, and assumptions are rarely reassuring.

Honesty pays off here. If the implementation runs three months longer than planned, it is better to communicate that on time than to hide it until the week of the planned go-live. Employees who later discover they were not informed in time lose trust in the project and in project leadership.

Step 3: tailored training, not generic

Generic training covers the functionality of the system. But employees learn best when they see how the system supports their own work, in their own terminology, with familiar examples.

Develop training material per department and per role. Use the words employees already use for their processes. Show how the actions they know today look in the new system. That lowers the threshold and raises confidence.

Step 4: use test moments as learning moments

The user acceptance test (UAT) is a technical control for the project team. For employees it is the first real contact with the new system in a work situation that resembles their own.

Use that moment deliberately. Plan test moments with guidance: note which questions end users ask, which actions they find difficult, and where the configuration does not yet match how they think and work. A well-run test moment raises confidence in the system before go-live and produces useful configuration feedback.

Step 5: a hypercare period after go-live

The first weeks after go-live shape long-term adoption. Employees run into situations that did not come up in training. If they do not get a quick answer, they invent their own solution. And that solution is rarely the new system: it is an Excel sheet, a manual note, or a colleague who “always used to do it this way”.

Plan a hypercare period of at least four weeks after go-live. Provide accessible support, active monitoring of system usage, and a channel where employees can quickly raise questions.

The cost of insufficient adoption

Organisations that skip ERP change management or start too late see the payback time of their ERP investment increase. Not because the system performs poorly, but because the system is not used as intended. Workarounds, parallel Excel files and manual corrections are the visible symptoms of insufficient adoption. They are also the cost of a change track executed too quickly.

The hidden damage sits in the time employees lose to duplicate work, in the errors that arise from disconnected data, and in the frustration that, over time, lowers trust in both the system and the organisation that introduced it.

Organising change management in-house or external?

Smaller organisations sometimes choose to run change management entirely in-house, with a project manager or with HR. That can work if the person involved is genuinely freed from their regular tasks and has experience with change projects.

Larger organisations, or those with a more complex implementation, more often choose a combination: in-house ownership, supported externally. An external change advisor is not affected by internal politics, can collect feedback more honestly, and holds a more neutral position when interests collide between departments or layers of the organisation.

ERP Company offers independent guidance for ERP implementations, including the change management component. As a platform-independent partner, ERP Company has no stake in a specific system or a specific outcome.

Want to think through the change approach for your implementation? Get in touch for an exploratory conversation, with no obligations.

Three situations where change management weighs heaviest

Replacement projects where employees have worked with the old system for many years. The old system sits in their muscle memory. Letting go of that familiarity feels like loss, even when the new system objectively fits current processes better.

Implementations that have failed before inside the organisation. Distrust already exists, and the unspoken question “is this time really going to work?” hangs over the project. That distrust has to be addressed openly, not ignored.

Mergers or acquisitions where multiple systems and multiple organisational cultures come together. The change question is then technical and organisational at the same time: who works how, with which system, and according to whose processes?

What effective ERP change management delivers

Effective change management at ERP implementations raises adoption, shortens time-to-value and lowers the chance of remediation projects after go-live. Organisations that take change management seriously generally see higher end-user satisfaction, fewer functional workarounds and a faster return to normal productivity after launch.

That is not a soft quality. That is return on your implementation investment.

The link with ERP management after go-live

ERP change management does not stop on go-live day. Organisations evolve: new employees join, processes change, and the system has to grow with the organisation.

That means attention is also needed after the implementation: training for new joiners, evaluation of how the system is being used, and adjustments where they are needed. See also how to structure ERP management after go-live.

Which questions do you ask your implementation partner?

If you are selecting an implementation partner, it is worth asking explicitly how change management is anchored in their approach. Not as a by-product of training, but as a self-contained part of the project. How does the partner choose key users? What is their approach to departments with strong resistance? How do they organise the hypercare period?

Frequently asked questions about ERP change management

When should ERP change management begin?

ERP change management ideally begins as soon as the decision is made to implement a new system, well before the technical project start. Communication and impact analysis in this early phase prevent the rumour mill from shaping perception and prevent employees from feeling that the project is something happening to them.

Who is responsible for ERP change management?

Final responsibility sits with the client, usually the executive board or project sponsor. Day-to-day execution sits with the project manager, working with key users and, where helpful, an external change advisor. Without a clear owner, the approach dilutes and execution slips between the cracks.

How much resource does ERP change management require?

That depends on the complexity of the implementation and the size of the organisation. A rule of thumb: treat the investment in change management as equal to the investment in training. Organisations that treat it as a side issue see the payback time of the ERP project arrive later than planned.

Can ERP change management be organised internally?

Yes, that is possible if the right person is genuinely freed from their regular work and has experience with change projects. In practice, larger or more complex implementations choose a combination: internal ownership, supported externally. An external advisor brings neutrality and can gather feedback that is harder to surface internally.

ERP change management is not a by-product of a technical project. It is a self-contained part of a successful implementation, and it deserves the same care as configuration or data migration.

Whoever starts too late pays the price after go-live: in workarounds, remediation projects and a slower return on investment. Whoever starts early invests in the conditions for actual use of the new system.

Want to know how ERP Company approaches change management on implementation projects? Get in touch for an exploratory conversation, with no obligations.

Further reading: Want the complete approach? See our step-by-step ERP implementation approach.