The Most Overlooked Stakeholders in ERP Transformation Projects

They’re not on the steering committee. But they often determine whether the transformation actually works.

ERP transformation projects are meticulous about stakeholders.

Steering committees. Executive sponsors. Program leads. Workstream owners. Stakeholder maps that categorize every person with formal accountability, assign engagement strategies by influence level, and track communication touchpoints across the program lifecycle.

On paper, it’s comprehensive. Every formal stakeholder has been identified, mapped, and engaged.

And yet, in most ERP programs, the same things happen regardless of how thorough the stakeholder strategy is. Adoption struggles. Workarounds emerge quietly alongside the new system. Decisions stall at levels where they should be moving independently. Confusion lingers in pockets of the organization long after go-live, concentrated in exactly the functions where nobody thought to look.

Not because stakeholders were missed entirely. Because the wrong stakeholders were prioritized.

The assumption that shapes most stakeholder strategies

ERP programs instinctively focus their stakeholder attention on the people with decision authority, formal accountability, and visible organizational influence. And that instinct makes sense — these are the people who approve budgets, sign off on milestones, and set the direction that everyone else is supposed to follow.

But they are not the people who determine how the system is actually experienced day-to-day.

That happens somewhere else — in the informal networks, the team-level conversations, the workaround decisions that get made when the new system doesn’t match the old process, and the perception that forms in the first few weeks of go-live before anyone in program leadership has heard about it.

The most influential stakeholders in ERP transformations are often the least visible. They don’t sit in governance forums. They don’t present in steering committee meetings. They’re not listed in formal stakeholder maps. But they shape how work actually gets done, how information flows through the organization, how the system gets used or quietly avoided, and how the narrative about the transformation is formed at the ground level.

When ERP programs don’t engage them intentionally, they don’t become obstacles. They become independent variables — people who determine the outcome of the transformation based on their own experience of it, without the program having any influence over that experience.

The five stakeholders most ERP programs underestimate

1. The informal operators

Every organization has them — and every experienced employee knows exactly who they are even if they’ve never been formally identified. They’re the people who know how things actually work. Who hold the process together when systems don’t. Who get things done across organizational boundaries through relationships and institutional knowledge that no org chart captures.

They’re not always managers. They’re not always senior. But they are relied upon — by their peers, by their teams, and often by their managers — in ways that aren’t visible until the informal operator is unavailable or disengaged.

In ERP transformations, informal operators are among the first people to identify gaps between how the new system is supposed to work and how work actually gets done. They’re also among the first to create workarounds — not out of resistance, but out of a pragmatic need to keep things moving. And when they create workarounds, others follow. Not because they were told to, but because they trust the informal operator’s judgment more than they trust a system they haven’t learned yet.

If informal operators don’t understand and believe in the change — if they experience it as a disruption without a clear improvement on the other side — they won’t block the transformation directly. They’ll route around it. And others will route with them. That quiet routing, multiplied across an organization, is what produces the persistent adoption gaps that programs struggle to diagnose months after go-live.

2. The translation layer — managers

Managers are usually listed in stakeholder maps. They’re rarely treated as what they actually are: the primary interpreters of change for the people who will live inside the new system every day.

Managers take enterprise-level messaging — the program announcements, the leadership communications, the town hall content — and turn it into team-level meaning. What does this change actually mean for our team? What are we supposed to do differently starting Monday? What questions can I answer and what should I escalate? When managers are clear, confident, and consistent, their teams are more likely to adopt quickly and ask better questions. When managers are unclear — because they were given dense slide decks, last-minute updates, and no real context for why — everything downstream is unclear.

The failure mode isn’t that managers don’t try. It’s that the program underestimated what it takes to equip them. A manager who received the same all-staff communication as their team, with no additional context or preparation time, is not positioned to translate. They’re positioned to repeat — and repetition without translation produces confusion at the team level even when the enterprise message was clear. (For how to equip managers as translators rather than repeaters, read How to Create an ERP Communications Plan That Actually Works.)

3. The edge users

Edge users are the people operating at the boundaries of the system — field teams, frontline roles, cross-functional coordinators who sit between functions and manage the handoffs that enterprise systems are supposed to streamline but often complicate.

They experience system friction first — before the help desk logs it, before the program team hears about it, before anyone in governance has a chance to address it. They encounter process gaps in real time, under operational pressure, without the luxury of submitting a ticket and waiting for a response. And they develop their own solutions to those gaps — solutions that often persist long after the official gaps have been addressed, because the workaround became the process before the fix arrived.

The problem isn’t that edge users are difficult. It’s that they’re engaged late — brought in during training, communicated to through generic all-staff messages, and rarely given a channel for surfacing what they’re actually experiencing before go-live. By the time their experience informs the rollout, it’s already happened. Programs that engage edge users early — during design and testing phases, with specific role-level communication and structured feedback channels — consistently produce smoother go-lives than programs that treat them as recipients rather than contributors.

4. The shadow influencers

Shadow influencers are the people others go to with the real questions — not the official ones.

“Do you think this will actually work?”
“Is this how we’re supposed to use it, or is that just what they told us?”
“What do you think is actually going on with this program?”

They’re not formally recognized. They’re not listed in stakeholder maps. But they are highly trusted — by their peers, across functions, sometimes across levels — in ways that formal authority rarely replicates. Their credibility comes not from their position but from their track record of being honest, of being right, of giving their colleagues the real story rather than the managed one.

In ERP transformations, shadow influencers shape perception faster and more durably than any official communication. If a shadow influencer is genuinely skeptical about the program — if they believe the system won’t work for real operational needs, or that the implementation is being rushed, or that leadership doesn’t understand what they’re asking people to change — that skepticism travels through informal networks at a speed and depth that no newsletter or town hall can counteract. It’s not deliberate sabotage. It’s trusted people telling the truth as they see it.

The same dynamic works in the other direction. When shadow influencers genuinely understand and believe in the change — when they’ve been engaged early enough to have real context, have had their concerns addressed honestly, and have come to see the value in the new system — they reinforce the transformation without being asked. Their alignment becomes organic advocacy that reaches parts of the organization that formal communication never does.

This is the calm cascade operating in the informal network — emotional tone and narrative stance traveling through trust relationships rather than hierarchy. Programs that identify and genuinely engage their shadow influencers, treating their concerns as signals rather than resistance, consistently see faster adoption and more durable behavior change than programs that communicate past them. (For the full treatment of how informal influence works during change, read The Psychology of Alignment.)

5. The support ecosystem

IT support teams, help desks, and training support staff are almost universally treated as secondary stakeholders in ERP programs — people who need to be informed, not actively engaged. They receive the same communications as everyone else, with perhaps a slightly earlier heads-up about go-live timing so they can prepare for increased ticket volume.

But during and after go-live, the support ecosystem becomes the front line of the transformation experience. They are the first people employees interact with when something doesn’t work — when a workflow doesn’t match the training, when a transaction produces an unexpected result, when the old process and the new process collide in ways nobody anticipated. Every interaction with the support ecosystem is an opportunity to either reinforce the narrative of the transformation or undermine it.

When support teams understand not just how the system works but why the change was made — what problem it’s solving, what the organization is trying to achieve, what good adoption looks like — they do more than solve tickets. They become ambassadors of the change. When they don’t have that context, they solve tickets while communicating, often unintentionally, a narrative of dysfunction. “We’ve been getting a lot of those calls” lands very differently than “That’s a common question in the first few weeks — here’s the context for why the process changed.”

Why these stakeholders get missed

Not because program teams don’t care about them. Because they’re structurally difficult to prioritize within how ERP programs are typically designed.

These stakeholders are harder to map — they don’t have formal titles that make their influence visible, and their importance doesn’t show up in org charts or governance structures. They’re not tied to formal authority, which means they don’t appear in the decision rights and accountability structures that programs use to organize stakeholder engagement. And they’re difficult to categorize — the informal operator in one function might be the most important person in the building, while a person with the same title in another function has far less informal influence.

ERP programs operate under enormous pressure — of scope, of timeline, of budget. Under that pressure, they default to what’s measurable and what’s formally structured. Governance meetings, steering committee approvals, workstream accountability. These are important. They’re also insufficient.

Because transformation doesn’t happen in formal structures. It happens in how work is actually done — in the informal networks, the team-level conversations, the day-to-day decisions that aggregate into adoption or resistance across a large organization.

What changes when you design for them

The benefits aren’t hypothetical — they’re consistent enough to be predictable.

When ERP programs intentionally engage informal operators, manager translators, edge users, shadow influencers, and support ecosystems, messaging becomes more practical because it’s been stress-tested by people who know where the real gaps are. Adoption issues surface earlier — before they become entrenched workarounds — because the people who encounter friction first have a channel for surfacing it. Adoption becomes more consistent across functions because the informal networks are reinforcing the same narrative rather than generating competing ones. And resistance that would otherwise build quietly shows up earlier, when it’s still addressable.

Not because more people are involved in the program. Because the right people are — the ones who shape how the transformation is actually experienced rather than just how it’s formally approved.

How to include them without overcomplicating the program

This doesn’t require a new framework or a separate workstream. It requires a shift in attention — from who has formal authority to who has actual influence.

Identify who people actually go to. Not who is supposed to influence the transformation, but who does. Ask people directly: “Who do you go to when something doesn’t make sense?” “Who helps you get work done when the system falls short?” Those answers will identify your informal operators and shadow influencers more accurately than any stakeholder mapping tool.

Bring them in earlier than feels necessary. Most programs engage these stakeholders during testing, training, or go-live. That’s too late — by then, informal narratives are already forming, and the patterns of adoption or workaround are already being established. Engage informal operators and shadow influencers during design and early process conversations, when their input can still shape the approach rather than react to it.

Give them context, not just information. These stakeholders don’t need more updates. They need to understand why the change is happening, what problems it’s solving, and what trade-offs are being made — because they are the people others will ask. An informal operator who understands the genuine rationale behind a process change can explain it to twenty colleagues in a way that no official communication will match. An informal operator who received the same generic all-staff message as everyone else will answer those twenty colleagues with “I don’t really know.”

Listen to them as signals, not noise. When informal operators raise concerns about how the system handles a specific workflow, or when shadow influencers express skepticism about the implementation timeline, those concerns are almost always early indicators of something real — a gap in the system, a gap in the communication, or a gap in the design. Programs that treat these signals as operational detail to be managed miss the diagnostic value of the most informed observers in the organization. (For how to build feedback loops that capture these signals systematically, read Why ERP Projects Fail.)

What this looks like in practice

I worked with an ERP program team that was six months post-go-live and still experiencing significant adoption gaps in two of their five functions. The steering committee was engaged. The executive sponsor was visible. The formal stakeholder strategy had been executed as planned.

When we diagnosed where adoption was breaking down, the pattern pointed consistently to the same dynamic in both functions: the informal operators — the people their colleagues relied on to interpret the new system — had been engaged only during training, had received the same generic communication as everyone else, and had come out of the go-live experience skeptical about whether the system actually solved the problems it was supposed to solve.

Their skepticism hadn’t been expressed loudly. It had traveled through informal networks — in the form of workarounds that their colleagues adopted, in the form of questions that routed around the help desk to them directly, in the form of a quiet narrative that the old way was still more reliable than the new one for certain transaction types.

We ran targeted engagement sessions with the informal operators and shadow influencers in both functions — not to persuade them, but to genuinely understand what they were experiencing. Two of their concerns revealed actual system gaps that the program team hadn’t been aware of. Three revealed communication gaps — places where the narrative hadn’t addressed the specific workflow implications that mattered most to these functions.

Both sets of gaps were addressed. Within six weeks, the informal narrative in both functions had shifted — not because we had broadcast a corrective message, but because the people others trusted had genuinely changed their assessment of the system.

The formal stakeholders hadn’t changed. The informal ones had. And that’s what moved adoption.

Final thought

The most overlooked stakeholders in ERP projects are not hidden.

They’re just not formally recognized.

And that’s exactly what makes them easy to miss — and expensive to ignore.

If you want to understand how your transformation will actually land, don’t just look at who is accountable.

Look at who people trust. Look at who people follow. Look at who people go to when things aren’t clear.

Because that’s where the real transformation happens — or doesn’t.

FAQs: Stakeholders in ERP transformation

Who are the most important stakeholders in an ERP implementation?
Beyond the formal stakeholders — executive sponsors, steering committees, workstream owners — the most influential stakeholders are often the least visible: informal operators who hold processes together through institutional knowledge, managers who translate enterprise messaging into team-level meaning, edge users who experience system friction first, shadow influencers whose trust shapes perception faster than any official communication, and support ecosystem teams who become the front line of the transformation experience at go-live.

Why do ERP programs struggle with stakeholder engagement?
Because they prioritize formal authority over actual influence. Stakeholder strategies are built around decision rights and formal accountability — the people who approve the transformation. But the people who determine how the transformation is actually experienced day-to-day are often informal, harder to map, and not tied to any formal governance structure. When programs focus exclusively on formal stakeholders, they leave the most influential people in the organization unengaged.

What is an informal operator in an ERP transformation?
An informal operator is someone in the organization who knows how things actually work — who holds processes together when systems don’t, who gets things done across boundaries through relationships and institutional knowledge that org charts don’t capture. In ERP transformations, informal operators are among the first to identify gaps, the first to create workarounds, and the most influential people in shaping how their colleagues adapt to the new system. When they’re not engaged, their workarounds become the de facto process.

What is a shadow influencer and why do they matter?
A shadow influencer is someone who isn’t formally recognized as an organizational leader but is highly trusted by peers and colleagues — the person others go to with real questions about whether something will actually work. In ERP transformations, shadow influencers shape perception faster and more durably than official communication. Their skepticism spreads through informal networks before any corrective message can counteract it. Their genuine alignment, when earned, produces organic advocacy that reaches parts of the organization formal communication never does.

When should informal stakeholders be engaged in an ERP program?
Earlier than feels necessary — during design and early process conversations, not just during training and go-live. By the time testing begins, informal narratives are already forming and patterns of adoption or workaround are already being established. Early engagement allows informal operators and shadow influencers to surface real gaps while there’s still time to address them, and gives them the context they need to become advocates rather than skeptics.

How do you identify shadow influencers and informal operators?
Not through org charts or stakeholder mapping tools. Ask people directly: who do you go to when something doesn’t make sense? Who helps you get work done when the system falls short? Who do you trust to tell you what’s really going on? The answers will identify the real influencers more accurately than any formal analysis — because the people who are asked are the ones who know who their colleagues actually trust.

How does The Clarity Framework™ apply to stakeholder engagement in ERP programs?
The Clarity Framework™ starts with diagnosis — identifying where understanding is breaking down and who is shaping the informal narrative before official communication can reach them. That diagnostic work is where informal operators, shadow influencers, and edge users become visible. The define principle then builds the narrative that gives these stakeholders something genuine to believe in and repeat — not a managed message, but a coherent story grounded in the real problem the system is solving. And the measure principle tests whether alignment has built in the informal network, not just in the formal one.

Ana Magana is a strategic communications and change management consultant based in Calgary, Alberta. She helps organizations design stakeholder engagement strategies that reach the people who actually determine how ERP transformations land — through The Clarity Framework™.

Running an ERP program where informal adoption is lagging behind formal expectations? Work with Ana →