Change Management for ERP Implementations: Why Technology Is Only 30% of the Battle

In 26 years of implementing Infor CloudSuite and Lawson, I have watched organizations spend millions on technology and months perfecting configurations, only to stumble at the finish line because they neglected the human side of the equation. The pattern is so consistent that I now tell every client the same thing on day one: technology is only about 30% of ERP success. The other 70% is people.

That is the 70/30 rule, and it is not a talking point I invented to sell consulting hours. It is what I have observed across healthcare systems, universities, public sector agencies, and retail organizations. The projects that succeed invest heavily in organizational change management for ERP. The projects that fail almost always underinvest in it.

Why Most ERP Projects Underinvest in Change Management

There is a simple reason most organizations shortchange change management ERP implementation efforts: change management is hard to quantify. You can show a steering committee a Gantt chart with technical milestones. You can demonstrate a configured module in a sandbox environment. But how do you demonstrate that 2,000 employees are emotionally and practically ready to work differently starting Monday?

What typically happens is that leadership allocates 90% of the budget and attention to software licenses, infrastructure, consulting fees for configuration and development, and testing. Change management gets a line item that amounts to "we will do some training before go-live." That is not ERP change management. That is a recipe for user resistance and adoption failure.

Budget imbalance: Organizations routinely spend 10x more on technology than on preparing people to use it
Timeline compression: When projects run behind schedule, change management activities are the first to be cut
Misunderstanding: Leadership equates "training" with "change management" when training is only one piece
Ownership gap: Nobody is explicitly accountable for organizational readiness, so nobody owns it

The 70/30 Rule in Practice:

If your Infor CloudSuite project budget is $2 million, you should be investing at least $400K-$600K in change management activities including stakeholder engagement, communications, training development, super user programs, and post go-live support. Most organizations spend less than $100K.

Building a Change Management Framework for Infor CloudSuite

Effective Infor CloudSuite change management does not happen by accident. It requires a structured framework that runs parallel to your technical implementation from day one. I use a framework built around five pillars that I have refined over hundreds of engagements:

Stakeholder analysis and engagement -- understanding who is affected and how deeply
Communication planning -- keeping people informed before fear fills the vacuum
Training strategy -- building competence and confidence, not just awareness
Resistance management -- anticipating and addressing pushback at every level
Adoption measurement -- tracking whether people are actually changing behaviors

Each of these pillars has specific activities, deliverables, and timelines that map directly to your implementation phases. Let me walk through each one.

Stakeholder Analysis: Know Your Audience Before You Communicate

Before you send a single email about the project, you need to understand your stakeholder landscape. Not all stakeholders are created equal, and not all of them need the same message or the same level of engagement.

I map every stakeholder group across two dimensions: how much the change impacts their daily work, and how much influence they have over whether the project succeeds or fails. This gives you four quadrants:

High impact, high influence: Your priority group. These are department heads, process owners, and senior managers whose teams will use the system daily. They need deep engagement and early involvement.
High impact, low influence: Your end users. They will feel the change most directly but have less organizational power. They need clear communication, excellent training, and responsive support.
Low impact, high influence: Executives and board members who approve budgets but will not use the system. They need concise updates focused on business outcomes and ROI.
Low impact, low influence: Peripheral stakeholders who need basic awareness but not deep engagement.

Practical Tip:

Create a stakeholder register in the first two weeks of the project. Update it quarterly. I have seen projects derailed because a key stakeholder was overlooked until month eight, when they suddenly became a vocal opponent of the entire initiative.

Communication Planning: Fill the Vacuum Before Fear Does

Here is a truth about organizational change management for ERP that I have learned the hard way: in the absence of information, people will invent their own narrative, and it will always be worse than reality. If you are not communicating proactively, the rumor mill is communicating for you.

A solid ERP communication plan answers four questions for every stakeholder group:

Who needs to hear this message?
What do they need to know at this stage?
When do they need to hear it (tied to project milestones)?
How should it be delivered (email, town hall, department meeting, one-on-one)?

I recommend a cadence of monthly all-hands updates during the design phase, biweekly during build, and weekly during the final three months before go-live. Department-level communications should be more frequent and more specific to how the change affects their workflows.

One non-negotiable: every communication should answer the question employees actually care about, which is "what does this mean for me and my job?" If your project newsletter reads like a technical status report, you have missed the point entirely.

ERP Training Strategy: Beyond "Show Them the Screens"

This is where most ERP training strategies fall apart. The typical approach is to schedule a few days of training right before go-live, walk users through the screens, hand them a manual, and hope for the best. It does not work.

Effective user adoption for ERP requires a layered training approach:

Role-based training: A payroll clerk does not need the same training as a purchasing manager. Design training curricula around specific job roles and the transactions they will perform daily.
Hands-on practice: Lecture-based training has a retention rate of about 5%. Hands-on practice in a sandbox environment pushes that above 75%. Build realistic exercises using your actual data.
Progressive learning: Start with concepts and business process changes weeks before go-live. Move to system navigation. Then specific transactions. Then exception handling. Layer it over time instead of cramming it into two days.
Ongoing reinforcement: Training does not end at go-live. Plan for refresher sessions at 30, 60, and 90 days. Publish quick-reference guides. Record short how-to videos for common tasks.

Training Rule of Thumb:

For every hour of training you think you need, plan for three. One hour of concept and process training, one hour of hands-on practice, and one hour of post go-live reinforcement. The organizations that follow this rule consistently have smoother go-lives.

Dealing with ERP User Resistance at Every Level

Resistance to ERP change is not a bug in the process. It is a feature of human nature. People resist change when they fear losing competence, control, or comfort. The key is understanding that resistance looks different depending on where someone sits in the organization.

Executive resistance usually manifests as budget questioning, delayed decisions, or suddenly reprioritizing other initiatives. Address it by connecting every project milestone to business outcomes they care about: cost reduction, compliance, competitive advantage.

Middle management resistance is often the most dangerous and the most overlooked. These are the people who control whether their teams engage with the project or quietly sabotage it. They resist because the new system often reduces their information gatekeeping power. Engage them as process owners and give them visible roles in the project to convert them from resistors to advocates.

End user resistance is the most visible and the easiest to address if you start early. Most end users resist because they are afraid of looking incompetent in the new system after being experts in the old one. Give them ample practice time, pair them with super users, and publicly celebrate early adopters.

Building an Effective Super User Program

A well-designed super user program is the single most effective change management tool in your arsenal. Super users are the bridge between the project team and the broader organization. They are your force multiplier.

Here is how I build super user programs that actually work:

Select carefully: Choose people who are respected by their peers, not just technically proficient. A super user nobody listens to is useless regardless of their system knowledge.
Dedicate their time: Super users need at least 25-50% of their time dedicated to the project during the three months before go-live and the first month after. If their manager will not release them, find a different super user.
Train them deeply: Super users should receive training two to four weeks ahead of end users. They need to know not just how to perform transactions but why the process works the way it does and what to do when things go wrong.
Empower them: Give super users a direct line to the project team. They should be able to escalate issues in real time, not through a help desk queue.
Recognize them: Publicly acknowledge their contributions. This is extra work on top of their regular job. Make it count toward their performance review.

Super User Ratio:

Plan for one super user per 15-20 end users. For a 500-person deployment, that means 25-35 super users. It sounds like a lot. It is not. Organizations that skimp on super users always regret it during the first week of go-live.

Measuring Adoption and Readiness

You cannot manage what you do not measure. Yet most organizations have no KPIs for change management until someone asks "are we ready?" two weeks before go-live. By then it is too late.

I track these metrics throughout the project:

Training completion rates by role and department (target: 95%+ before go-live)
Training assessment scores demonstrating actual competency, not just attendance
Stakeholder engagement scores from periodic pulse surveys
Communication reach measuring whether messages are being received and understood
Super user readiness assessed through practical scenario testing
Issue volume and resolution time during user acceptance testing
Post go-live system usage rates compared to expected transaction volumes

If training completion in a department is below 80% two weeks before go-live, that is a red flag. If super users cannot resolve common issues independently, that is a red flag. These metrics give you time to intervene rather than discover problems after the fact.

The Go-Live Dip: Managing the Productivity Valley

Every ERP go-live, no matter how well managed, produces a temporary dip in productivity. I call it the go-live dip, and it is critical that leadership understands and expects it.

In the old system, a payroll clerk could process a batch with muscle memory in 20 minutes. In the new system, that same batch might take 45 minutes for the first few weeks as they learn new screens, new workflows, and new approval processes. Multiply that across every transaction in every department, and you have a measurable productivity decline.

The typical recovery curve looks like this:

Week 1-2: Productivity drops 30-50%. Everything takes longer. Help desk volumes spike. This is normal.
Week 3-4: Productivity recovers to about 70-80% of pre go-live levels. Users start building new muscle memory.
Month 2-3: Productivity returns to baseline. Users are becoming comfortable.
Month 4-6: Productivity exceeds the old system as users leverage new capabilities and efficiencies.

If leadership is not prepared for this dip, they will panic at week two and start questioning the entire project. Set expectations early. Show them the curve. Remind them that this is temporary and expected.

Post Go-Live Support and Hypercare

Go-live is not the finish line. It is the starting line. The first 30-90 days after go-live, commonly called the hypercare period, is when your change management investment either pays off or falls short.

During hypercare, I recommend:

Floor support: Super users and project team members physically present in departments for the first two weeks
Rapid response triage: Issues categorized and resolved within hours, not days
Daily standup meetings with department leads to surface problems early
Weekly executive updates with honest assessments of adoption progress
Training refreshers targeted at areas where users are struggling most
Quick wins documentation: Capture and publicize examples of the new system working better than the old one

Change Management for Healthcare and Education

Healthcare and higher education organizations face unique change management challenges that require specialized approaches. I have worked extensively in both sectors, and the differences from private industry are significant.

In healthcare, you are dealing with clinical staff who view any system change through the lens of patient safety and care quality. Nurses, physicians, and clinical managers will resist anything they perceive as slowing down patient care. You also frequently encounter union environments where change must be negotiated, not mandated. The approach that works is involving clinical leadership early, framing every change in terms of patient outcomes, and providing extra training time for staff who work rotating shifts and cannot attend standard training sessions.

In education, faculty governance creates a unique dynamic. Professors and academic leaders expect to be consulted, not told. Shared governance means change moves slower but has stronger buy-in once achieved. Administrative staff in higher education often have very long tenure and deep expertise in legacy processes, which means the transition from "how we have always done it" to new workflows requires patience and respect for institutional knowledge.

Sector-Specific Insight:

In unionized healthcare environments, I always recommend including union representatives on the change management steering committee. Not as an afterthought, but as core members. When unions feel informed and respected, they become allies instead of obstacles. I have seen this approach turn potential labor disputes into smooth transitions.

Common Change Management Mistakes That Kill ERP Projects

After 26 years, I have compiled a list of change management mistakes that consistently correlate with ERP project failures. If you see yourself in any of these, consider it an early warning:

Starting change management too late. If your first change management activity is training two weeks before go-live, you have already failed. Start on day one of the project.
Delegating change management to the IT department. IT is responsible for the technology. Business leadership must own organizational change. When IT runs change management, it becomes technology-centric and misses the human element.
Treating communication as a one-way broadcast. Sending newsletters is not communication. Real communication is two-way: listening to concerns, answering questions, and adjusting based on feedback.
Using a one-size-fits-all training approach. A finance power user and a casual requisition approver do not need the same depth of training. Role-based training is not optional.
Ignoring middle management. Frontline managers can make or break adoption. If they are not bought in, their teams will not be either.
Cutting change management when the budget gets tight. This is like cutting your parachute because the plane is running low on fuel. The landing is the part that matters most.
Declaring victory at go-live. Adoption is not binary. Going live is the beginning of change, not the end. Plan for at least 90 days of active change management support after go-live.

Making the Case for Change Management Investment

If you are a project sponsor or CIO trying to justify change management investment to your board, here is the data point that usually gets attention: according to Prosci research, projects with excellent change management are six times more likely to meet or exceed objectives than those with poor change management. Six times.

When you are investing $1-5 million in an Infor CloudSuite implementation, the question is not whether you can afford to invest in change management. The question is whether you can afford not to.

I have seen $3 million implementations deliver transformational results because the organization invested properly in people. And I have seen $5 million implementations produce expensive shelf-ware because they treated change management as an afterthought. The technology was identical. The outcomes were not.