What a Pre-Symposium Panel on Change Management Taught Me About ERP Implementation Success
- Jun 2
- 4 min read
I recently had the opportunity to join Lisa Fleming and William Sandoval for a pre-symposium panel hosted by Ambition in Motion.
The topic was From Strategy to Reality: Turning Change Initiatives Into Measurable Wins. The lead-up to the Executive Symposium on June 11th in DFW.
What started as a conversation about organizational change management turned into one of the most direct articulations I have heard of why ERP implementations struggle even when the technology is right, the partner is capable, and the business case is sound.
I want to share what came out of that conversation and what it means for organizations preparing for an ERP implementation or navigating one right now.
Urgent Always Wins. Until It Doesn't.
The insight that landed hardest for me the one I have been thinking about since the panel ended was this. "We need to allow some urgent balls to drop for the sake of prioritizing important but non-urgent work".
That sounds counterintuitive in an operational environment. Plant floors do not stop. Assets do not wait. Work orders do not pause because a project team needs attention.
But here is what I see consistently in ERP implementations across asset-heavy organizations. The implementation is planned. The timeline is set. The kickoff happens. And then the first operational fire breaks out, and the project takes a back seat. Then another fire. Then another. The implementation keeps slipping because operational fires keep winning the prioritization battle.
Nobody is wrong to fight the fires. That is the job. But the ERP that was supposed to reduce the fires. The one that would give the maintenance team better asset data, cleaner work order management, and proactive maintenance scheduling never gets the organizational attention it needs to deliver on that promise. Because every week there is something more urgent.
The important but non-urgent work building the foundation that prevents next quarter's fires keeps losing to this quarter's emergencies.
That is not a project management problem. That is a leadership prioritization problem. And it requires a deliberate decision from the top: we are going to protect time for this transformation even when operations is pulling in the other direction.
Change Metrics Have to Be Personal
One of the first topics the panel covered was how to hone in and make change metrics personalized. This is something most ERP implementations get completely wrong.
The business case has metrics. ROI projections. Efficiency gains. Downtime reduction targets. Those metrics make sense to the CFO and the COO. They mean almost nothing to the maintenance technician who is being asked to change how they complete a work order.
What makes a metric personal is when it answers the question what does this change mean for me specifically, in my role, doing my job? Not what does it mean for the organization. Not what does it mean for the P&L. What does it mean for this person on this floor doing this work?
When organizations translate business KPIs into role-level impact. When the maintenance supervisor understands that the preventive maintenance schedule in IFS Cloud directly reduces the emergency callouts that disrupted their weekend last month the metric becomes real. It connects the transformation to something the individual already cares about.
That translation work is not automatic. It requires intentional design. And it almost never happens in a standard implementation plan.
Assigning Ownership Is Not the Same as Feeling It
The panel spent meaningful time on the difference between assigning ownership and feeling ownership. This distinction shows up in ERP implementations in a very specific way.
A project team assigns a department lead as a key user. That person attends the sessions, completes the training, signs off on the UAT. On paper they own their module. In practice they were assigned to own it and there is a significant difference between those two things.
Felt ownership comes from involvement. From having genuine input into how the system is configured for your team's work. From being asked what your team needs not told what they are getting. From having your concerns heard and addressed or at least explained before go-live.
When ownership is assigned without that foundation, the key user becomes a compliance participant. They do what is required. They do not become the internal champion the adoption plan depends on.
Psychological Safety Is Not Soft. It Is Structural.
The panel addressed what systems need to be in place for employees to have the comfort and psychological safety to participate in change. In an ERP context this is more practical than it sounds.
If a technician raises a concern about a new work order process and it gets dismissed or worse, ignored they will not raise the next concern. They will build a workaround instead. And then another. And the workarounds become the process.
Psychological safety in an ERP implementation is not about feelings. It is about whether the people closest to the work believe their input has any real influence on the outcome. When they do, they engage. When they do not, they comply at best and resist at worst.
Creating that environment requires the manager's active role which the panel addressed directly. The manager who endorses participation, who makes space for their team to engage with the project, who treats implementation involvement as legitimate work rather than a distraction from it that manager produces a different adoption outcome than the one who treats the project as someone else's problem.
What This Means for Your ERP Implementation
Every topic covered in that panel has a direct equivalent in an ERP implementation context.
Personalized change metrics. Translate the business case into role-level impact before the first training session.
Clearly defined intent, every person on the project team and in the affected workforce should be able to answer why we are doing this in one sentence.
True employee buy-in, not compliance. Not attendance. Genuine understanding of the personal why and genuine input into the how.
Psychological safety, a project environment where concerns surface early rather than becoming go-live surprises.
Manager endorsement, leaders who protect their team's time to participate rather than treating implementation as a distraction.
Felt ownership, key users who were involved in shaping the solution, not just assigned to deliver it.
And letting urgent balls drop, the organizational discipline to protect transformation work from being consumed by operational urgency every single week.
That last one is the hardest. And it is the one that most often determines whether the transformation delivers what the business case promised.