An ERP program is a business change that technology enables, not a software install that the business happens to notice. The system can pass every test, load every record, and clear every integration check, and still fail on the first Monday because the people who run accounts payable, the warehouse, or the plant floor will not use it the way it was designed. Technical readiness and business readiness are different measures. The first says the software works. The second says the people will work it. Most of the Gartner finding that more than 70% of recent ERP initiatives fall short of their business case is a business-readiness gap, not a code defect.
Why map the people before go-live
Resistance and risk do not spread evenly across a company. They concentrate in a handful of groups whose daily work changes most, and whose cooperation the program cannot do without. A stakeholder map finds those groups before they find you. Skip the map and the change budget gets spread thin across everyone, which means the three or four groups that can stall go-live get the same attention as groups the program barely touches.
The exercise is not long. For a program touching 2,000 users, a working map lists 15 to 30 groups, not 2,000 names. Each group gets two scores: how much their work changes (impact) and how much they can help or block the program (influence). A finance shared-services team of 40 people that moves from three screens to one new system is high impact. A regional vice president who signs off on the plant schedule is high influence. The two are rarely the same people, and treating them the same is the error.
An influence-and-impact grid decides where effort goes
Plot every group on a grid of influence against impact. The quadrant a group lands in sets what the program owes it, and roughly how much of the change budget it should draw.
| Quadrant | Who lands here | What to do | Rough share of change effort |
|---|---|---|---|
| High influence, high impact | Process owners, department heads whose teams change most | Involve directly in design and decisions; brief weekly; make them co-owners of their area | 40% to 50% |
| High influence, low impact | Executives, sponsors, functions touched lightly | Keep informed and consulted; short monthly briefings; protect their confidence in the program | 15% to 20% |
| Low influence, high impact | Front-line users, clerks, warehouse and floor staff | Train well, listen hard, give a real channel to raise problems; this is where adoption is won or lost | 25% to 35% |
| Low influence, low impact | Groups with a minor, occasional touch | Standard broadcast updates; do not overspend attention here | 5% or less |
The common mistake is pouring effort into the top-left executives, who are already informed and rarely the ones who abandon the system, while under-serving the bottom-right front line, who have the least power to shape the program and the most power to quietly reject it. A clerk who keeps a private spreadsheet because the new screen is slower has not been converted, and no steering committee will hear about it until the numbers drift.
Find resistance early and name what drives it
Resistance is information. It usually points at a real problem the design has not solved, and it is cheapest to handle months before go-live rather than in the first weeks after. Three drivers account for most of it, and each has a different answer.
The first is fear of job change. When a role that took skill in the old system becomes a few clicks in the new one, the person reasonably asks what they are now for. The answer has to come from their own manager, with specifics, not from a program poster. The second is loss of local control. A plant or a regional office that configured its own processes over 15 years now runs a shared design it did not write, and the loss is genuine. Naming it, and showing where local choice still exists, lands better than pretending the loss is not real. The third is workload during dual-run. For the weeks a company runs the old and new systems at once, people do their job twice. If that overload is not staffed for or acknowledged, the new system gets blamed for the exhaustion.
Find these early by asking, not by waiting for the complaint. Short readiness surveys at 6 months and 3 months before go-live, plus listening sessions with the high-impact groups, surface the drivers while there is still time to act. A group that goes quiet is not a group that agrees. It is usually a group that has stopped expecting to be heard.
A change champion network puts help inside the business
The people most likely to be believed about the new system are not the program team. They are respected co-workers in the same department who already know the system and the work. A change champion network, sometimes called super-users, puts one of those people inside each team. They are trained first, they help write the scenarios, they answer the small questions that no one wants to raise with the help desk, and they report back what is really happening on the floor.
Size the network to the end-user population, not to a round number. A rough ratio that holds up is 1 super-user per 15 to 20 end users in high-impact groups, thinning to 1 per 40 or 50 in groups the program touches lightly. A 2,000-user rollout with that spread lands at roughly 80 to 120 champions. Fewer than 1 per 30 across the board, and the network cannot cover the floor in the first weeks after go-live, when questions spike. Build in backfill: a champion who is also doing their day job at 100% will drop the champion half, so free 20% to 30% of their time during the heaviest months.
Communication segmented by audience, not one broadcast
One company-wide email that tells executives, managers, and front-line users the same thing in the same words serves none of them. Executives want the business case and the risk position. Managers want to know what changes for their team and when they lose people to training. Front-line users want to know what their Monday looks like and who to ask when it breaks. Segment the plan by audience, channel, and frequency.
| Audience | What they need | Channel | Frequency |
|---|---|---|---|
| Executives and sponsors | Business case, risk, decisions needed | Steering briefing, one-page update | Monthly, weekly in the last 8 weeks |
| Managers and process owners | What changes for their team, training dates, staffing impact | Manager briefings, team lead calls | Every 2 weeks, weekly near go-live |
| Front-line end users | What their day looks like, training, where to get help | Team meetings, champions, short demos | Weekly in the 8 weeks before go-live |
The front-line cadence matters most and is funded least. A message that reaches a warehouse worker through their own shift lead and a 10-minute demo lands; the same message in a corporate newsletter does not.
Measure adoption after go-live so "ready" is a number
"The business is ready" has to be a measurement, not an opinion. The software passing its tests tells you nothing about whether people are using it. Four signals, read daily in the first weeks after go-live and weekly after that, show whether adoption is real.
Login and active use: the share of expected users who actually sign in and transact, by team. A department at 60% when the plan assumed 95% is running a shadow process somewhere. Transaction completion: the share of started transactions that finish in the system rather than being abandoned or routed around. Error rates: the share of transactions kicked back for correction, which separates a training gap from a design gap when read by team and by error type. Help-desk ticket volume and theme: a spike is expected and healthy in week one; tickets that stay high in week four, clustered on the same step, point at a step the design got wrong. Set a target for each before go-live, such as 90% active use by week two and error rates back to the old-system baseline by week four, so the steering committee is reading the program against a line it drew in advance, not against a feeling.