ERP
ERP Change Management: Why People, Not Software, Determine Success
May 202510 min read
ERP
Studies consistently show that up to 70% of change initiatives fail due to poor change management, and productivity drops 20–40% during ERP adoption when change management is inadequate. I've watched a technically perfect ERP system — clean code, fast performance, reliable infrastructure — get abandoned because nobody managed the human side of the transition. The finance team found workarounds. The warehouse staff reverted to paper. The project was declared a success by the vendor and a failure by the business. This post is about preventing that outcome.
Resistance to ERP is rational, not irrational. When an employee has spent five years mastering a set of Excel files and WhatsApp workflows, an ERP system doesn't just change their tools — it changes what their expertise is worth. The person who knew 'which tab to check for pending POs' suddenly doesn't know anything. That's a real loss, and it deserves acknowledgment. In Indonesian businesses, there are also specific cultural dynamics: hierarchical deference means staff won't openly resist a system endorsed by management, but passive resistance (using the system incorrectly, maintaining parallel spreadsheets 'just in case') is very common and very hard to detect.
In every ERP rollout I've been part of, resisters fall into three groups. Active resisters openly argue against the system — they're actually the easiest to manage because they're visible. Passive resisters comply on the surface but maintain shadow processes and share their skepticism informally. This group is the most dangerous. Anxious adopters want to adopt but fear failure — they're not resistant, they're undertrained, and the solution is more support, not more pressure. Each group needs a different intervention: direct conversation for active resisters, transparency and involvement for passive ones, and patient coaching for anxious adopters.
Effective ERP change management requires a dedicated internal team, not just a project coordinator. You need an executive sponsor (visible, active, using the system themselves), department champions (one per function who own adoption for their team), a communication lead (owns the internal messaging, change bulletins, and FAQ), and a training coordinator (schedules and tracks all training sessions). This team should be formed in Month 1 of the project, not added as an afterthought in Month 8 when adoption is failing.
ERP Change Management Team Structure
┌─────────────────────────────────────────────────────────┐
│ EXECUTIVE SPONSOR (CEO/Director) │
│ • Uses system visibly in Week 1 │
│ • Champions program in all-hands meetings │
│ • Escalation authority for adoption blockers │
└────────────────────────┬────────────────────────────────┘
│
┌────────────────────────▼────────────────────────────────┐
│ PROJECT STEERING COMMITTEE │
│ PM + Dept Heads + IT Lead + Implementation Partner │
└──────┬──────────────────────────────────┬──────────────┘
│ │
┌──────▼──────┐ ┌───────▼───────┐
│ DEPT CHAMPION│ │ COMM + TRAINING│
│ per department│ │ LEAD │
│ │ │ │
│ • Own adoption│ │ • Internal │
│ for their │ │ bulletins │
│ team │ │ • Training │
│ • First point │ │ schedule │
│ of contact │ │ • FAQ mgmt │
└──────┬───────┘ └───────────────┘
│
┌──────▼───────────────────────────────────────────────┐
│ END USERS │
│ Active Resisters │ Passive Resisters │ Anxious Users│
│ (direct convo) │ (involve early) │ (more support│
└──────────────────────────────────────────────────────┘From my experience implementing ERPs at Commsult: involve the most skeptical department head in the design phase. When the person most likely to resist has input into how the system works for their team, they become its defender instead of its critic. We brought the finance manager into every AP module design session — by go-live, she was training her own team and correcting misconceptions that came from other departments.
Change resistance grows in information vacuums. When employees don't know why the system is changing, when it will affect them, or what the transition will look like, they fill the gap with rumors and worst-case scenarios. A structured internal communication plan covers the full project lifecycle: Month 1 — 'why we're doing this' announcement from the CEO, Month 3 — module demos for department leads, Month 6 — go-live date announcement with training schedule, Month 8 — 'what changes for you' role-specific briefings. Each communication should be honest about disruption, not only positive.
# ERP Internal Communication Plan Template
Month 1 — Kickoff Communication
From: CEO / Director
Channel: All-hands meeting + company email
Message: Why we are implementing ERP, what problem it solves,
what the project timeline looks like, who is involved.
Month 3 — Module Demo Series
From: Project Manager
Channel: Department-level workshops (not company-wide)
Message: Demo of modules relevant to each dept.
"Here's what the leave request flow will look like for you."
Month 6 — Go-Live Date Announcement
From: Executive Sponsor
Channel: Company-wide email + team WhatsApp groups
Message: Go-live date confirmed. Training schedule published.
What changes and what stays the same.
Month 8 — Role-Specific Briefings (2 weeks before go-live)
From: Dept Champions
Channel: 1:1 or small team sessions
Message: Exactly what YOUR role does differently after go-live.
Where to get help. Who to call with questions.
Key principle: Be honest about disruption.
"The first 2 weeks will be slower while we all learn"
is better than pretending there will be no impact.Organizations with comprehensive ERP training see up to 70% faster adoption rates. Role-specific training — not generic system walkthroughs — is the difference. A warehouse staff member does not need to understand the AP approval workflow. A finance approver does not need to know how to generate purchase orders. Every training session should cover exactly the screens and workflows the participant will use on day one, with realistic test scenarios drawn from actual company data. Record 3–5 minute screen capture videos for every workflow and host them in an accessible internal wiki. Users can replay them when they forget steps, and new staff can self-onboard.
The most common change management mistake is treating go-live as the finish line. Project teams celebrate, the implementation partner exits, and management attention moves on — right when users are most vulnerable, most confused, and most tempted to revert. In the first 30 days after go-live, usage drops, errors spike, and shadow processes re-emerge. This is normal. The response is to maintain intensive support, hold daily check-ins with department champions, and explicitly not declare victory until all core processes are running in the ERP with no shadow workarounds.
You can't manage what you can't measure. Key adoption metrics to track post-go-live: daily active users as a percentage of total licensed users (target: 80%+ by day 30), transaction error rate (flag anything above 5% as a training signal), percentage of processes still running on shadow workarounds (target: zero by day 60), and support ticket volume (should peak in week 1 and decline by 50% by week 4). Review these metrics weekly with department champions. A department with low daily active users is not a technology problem — it's a people problem that needs investigation.
After multiple ERP rollouts, the interventions that actually move adoption are: executive visibility (the CEO uses the system in the first week, publicly), department champion incentives (recognition, not just responsibility), real-time support channels (a dedicated WhatsApp group or Slack channel for ERP questions, staffed during business hours for the first 90 days), and patience with the productivity dip. The productivity drop is real — plan for it, budget for it, and communicate it honestly. Businesses that pretend the dip won't happen are the ones that panic and start blaming the system when it does.