ERP Change Management: The Change Workstream by Phase, Roles, and Adoption Measures

What is ERP change management?

ERP change management is the workstream that prepares people to do their jobs in a new enterprise resource planning system and in the redesigned processes around it. It runs beside the technical work from design through stabilization, and it covers impact assessment, communications, role-based training, a super user network, and readiness checks before cutover. ERP programs fail on adoption when users reach go-live without knowing why their process changed, without practice on their own transactions, and without help close at hand when something goes wrong. A successful program is one in which people run the business through the system after cutover and the spreadsheets and side processes disappear.

An ERP program is harder on people than most technology projects because it changes several things at once. Finance, supply chain, manufacturing, and sales move to shared data and standard processes. Local practices that teams built over years are retired. Approval rights, controls, and reporting lines shift. An order entry clerk, a plant scheduler, and a controller each face a different change on the same day, which is why change management for an ERP implementation has to be planned by role.

Why do ERP programs fail on adoption?

The public record contains detailed examples. A United States Senate subcommittee reported in 2014 that the Air Force spent over $1 billion on its Expeditionary Combat Support System between 2004 and 2012 with no capability to show for it. The subcommittee named cultural resistance to change and a lack of strong leadership among the root causes. The Government Accountability Office reviewed two other defense ERP systems in 2011 and found that the systems did not give finance users the capabilities they expected and that users were relying on manual workarounds to perform day-to-day operations. Both systems were in use, and people were still doing part of the work outside them.

Research explains the pattern. Adel Aladwani's paper on change management strategies for ERP implementation, published in the Business Process Management Journal in 2001, observed that top management commonly faces an unwanted attitude from potential users who resist the implementation, and argued that management should deal with the problem proactively. Technology acceptance research identifies what shapes that attitude. Viswanath Venkatesh and his coauthors compared eight models of technology acceptance using data from four organizations and combined them into a unified theory with four core determinants of intention and usage: performance expectancy, effort expectancy, social influence, and facilitating conditions. In plain terms, people use a system when they expect it to help them do their job, when they expect it to be manageable to learn, when the people who matter to them expect them to use it, and when the organization gives them the support to use it.

Each of the four has a typical point of failure in an ERP program.

Users were not involved in the design

Process decisions made by a core team and a system integrator reach the wider workforce as finished facts. People who had no part in the design do not expect the new process to help them, and they find the gaps the design team missed on the first day of live operation.

Training covered screens and skipped the job

Generic navigation training teaches people where to click. It does not teach a buyer how to handle a late supplier in the new process, and it does not explain why a step moved to another team. Training that is delivered long before go-live fades, and training on a system with empty or unrealistic data does not transfer to real work.

Managers stayed on the sidelines

Employees take their cue from their direct manager. A manager who was not briefed, who cannot answer questions, or who keeps asking for the old report tells the team that the old way remains acceptable.

Support ended at go-live

Programs that plan only to the cutover date leave users alone in the weeks when they have the most questions. Each unanswered question becomes a workaround, and workarounds harden into the unofficial process.

What does change management for ERP implementation involve in each phase?

The change workstream has a defined job in every phase of the program. The table summarizes the objective, the main activities, and the evidence that the phase is complete from a people standpoint.

Three points in this sequence deserve attention. The first is the change impact assessment in design. It lists what changes for each role and rates the size of the change, and every later activity draws on it. The second is user acceptance testing. It is the first time people from the business run their own work in the system, so it tests the training and the process as well as the software. The third is the readiness review before cutover. The people measures belong in the go or no-go decision beside the technical ones, because a system that is ready for users who are not ready will produce the workarounds the program was meant to remove.

The sections of a change plan apply here without modification. Our change management plan template sets out the seven sections, from the case for change to adoption metrics.

Which roles carry ERP change management?

A change lead cannot deliver adoption alone. Six roles share the work.

• Executive sponsor. The sponsor states why the company is replacing its systems, settles disputes between functions over process standards, and stays visible through stabilization.
• Process owners. Each end-to-end process, such as order to cash or procure to pay, has one owner who decides the standard design and answers for its adoption.
• Change lead. The change lead runs the impact assessment, the communications plan, and the readiness reviews, and reports adoption risks to the steering committee.
• Training lead. The training lead builds the curriculum by role and confirms that people can perform their tasks, which is a higher bar than attendance.
• Line managers. Managers explain the change to their teams, release people for training, and stop asking for outputs from the old system.
• Super users. Super users are respected practitioners from each function and site who learn the system early and support their colleagues.

The super user network is the part of this structure that reaches every desk. A super user joins during design, helps to test the system, co-delivers training, and provides floor support after go-live. The role works when three conditions hold. Managers nominate people whom colleagues already ask for help, and they avoid nominating whoever happens to be available. The program frees a real share of each super user's time and backfills the day job. Super users also keep a role after stabilization as the first point of contact for questions and improvement ideas, which gives the business a standing channel to the process owners.

How do you measure ERP adoption?

Adoption measures fall into two groups. Readiness measures are collected before cutover and tell the steering committee whether people are prepared. They include the share of users who have completed role-based training, the share who passed a proficiency check on their critical transactions, super user coverage by site and shift, business participation in user acceptance testing, and readiness survey results by group.

Usage measures are collected after cutover and show whether the organization is running on the system. Five of them carry the most information.

Active use compares the number of people transacting in the system with the number who should be. Process compliance tracks the share of transactions completed in the standard process, with manual journal entries, off-system purchase orders, and shadow spreadsheets counted as exceptions. Support demand tracks help desk tickets by volume and category, and a category that keeps growing points to a training or design gap. Quality tracks error and rework rates on key transactions. Business performance tracks the cycle times the program promised to improve, such as the time to close the books or to fulfill an order, against the baseline taken before go-live.

A workaround count deserves a place on the dashboard. The Government Accountability Office findings quoted above show that a live system and an adopted system are different things, and the gap between them is visible in the work people still do by hand.

When should ERP change management start?

The work starts in design, when process decisions are still open and user input can shape them. A change workstream that begins shortly before training can inform people about decisions, and it has lost the chance to involve them. The size of the effort depends on the number of users and sites, how far the standard processes sit from current practice, how much the program changes roles and controls, how many languages and shifts the training has to cover, and how much other change the organization is absorbing. An ERP program that is part of a wider digital transformation needs its change plan coordinated with the other initiatives that reach the same people.

BD Emerson delivers ERP change management with our Andersen Consulting colleagues at Daniels Consulting Group, a firm of organizational psychologists and experienced business professionals whose published client work includes leadership and team effectiveness after an ERP implementation. To plan the people side of your program, see our change management consulting service and book a consultation.