ERP implementations fail for many reasons, but one of the most common, and most preventable, is poor change management. You can have the right platform, the right partner, and the right strategy, but if your people aren’t ready to adopt new processes, the whole project stalls. That’s where the Prosci ADKAR Model comes in. It gives organizations a structured, repeatable framework for moving individuals through change, one stage at a time.
At Concentrus, we’ve seen this play out across hundreds of NetSuite and Acumatica ERP projects. The companies that treat change management as an afterthought are the same ones calling us for ERP rescue services six months later. The ones that build adoption into their rollout plan, using models like ADKAR, are the ones hitting their ROI milestones on schedule.
ADKAR breaks change down into five sequential stages: Awareness, Desire, Knowledge, Ability, and Reinforcement. Each stage targets a specific barrier that prevents people from embracing new systems, workflows, or roles. Skip one, and the whole chain weakens. This article walks through each of the five stages in detail, explains how they work together, and shows you how to apply the framework to your next major initiative, whether that’s an ERP go-live, a process overhaul, or a company-wide restructuring.
What the Prosci ADKAR model is
The Prosci ADKAR model is a goal-oriented change management framework developed by Prosci founder Jeff Hiatt after studying why change initiatives succeed or fail at the individual level. Unlike process-focused models that map out project timelines and organizational milestones, ADKAR focuses on the person going through the change. It treats successful change as the sum of individual transitions, not a single coordinated event. Each letter in the acronym represents a required building block: Awareness, Desire, Knowledge, Ability, and Reinforcement.
Organizations that address change at the individual level are far more likely to hit adoption targets than those that treat change as a project management exercise.
Where ADKAR came from
Prosci, the research and training organization behind the model, published the ADKAR framework in 2003 after studying more than 700 organizations to understand what separated successful change from failed change. What Hiatt and his team found was consistent: projects collapsed not because of bad strategy or flawed technology, but because individual employees lacked one or more of the five building blocks. The model was built to give change leaders a clear diagnostic tool they could use to identify exactly where adoption was breaking down and course-correct before the damage spread.
The framework has since become one of the most widely applied change management models in the world, with Prosci training practitioners across more than 80 countries. It underpins Prosci’s broader change management methodology, which includes role-specific tools for executive sponsors, people managers, and front-line employees. ADKAR is not theoretical; it emerged directly from pattern analysis of real project outcomes, which is why practitioners find it actionable rather than abstract.
How the model is structured
ADKAR works as a sequential, building-block framework, meaning each stage must be solidly in place before the next one can take hold. You cannot build genuine desire in someone who does not yet understand why change is necessary. You cannot expect ability without first delivering knowledge. This sequencing is what makes the model both precise and diagnostic. When someone resists a new process or system, ADKAR gives you a straightforward way to trace that resistance back to its root: Is the person unaware of the business reason? Do they understand it but lack the desire to participate? Do they know what to do but not how to execute?
Each of the five stages applies at the individual level, not the organizational level. This distinction matters. Your organization can technically go live on a new ERP system while large portions of your team are still stuck at Awareness or Desire. ADKAR gives you a structured, repeatable way to measure where each person sits in the change process and what specific intervention will move them forward.
Why ADKAR matters for ERP and finance teams
ERP projects are technology investments, but they fail for human reasons. When a finance team moves from a legacy system to NetSuite or Acumatica, the technical configuration is rarely where things break. Resistance, confusion, and inconsistent adoption are what derail timelines and erode ROI. The Prosci ADKAR model gives your team a concrete framework to address those human factors before they become expensive problems.
ERP rollouts demand behavior change, not just system change
Most ERP go-lives require your people to abandon familiar workflows and build entirely new habits under pressure. Finance teams face this acutely: close cycles change, approval chains shift, and reporting processes get rebuilt from scratch. Without a structured change model, employees revert to old methods or create workarounds that undermine the system’s value.
The gap between a system going live and a team actually using it correctly is where most ERP ROI gets lost.
Your finance leadership needs more than a training schedule to close that gap. ADKAR gives you a diagnostic lens to identify exactly which stage each team member is stuck at, so you can intervene with precision rather than guessing.
Finance leaders carry unique change pressure
CFOs and controllers are responsible for system adoption outcomes while simultaneously managing day-to-day financial operations. That dual pressure means change management often gets treated as someone else’s responsibility. But your team’s ability to hit ROI milestones depends directly on whether your people move through each ADKAR stage completely.
Skipping structured change management on an ERP rollout does not save time. It costs you months of rework, data errors, and user frustration that compound long after go-live. Finance teams that build ADKAR into their project plan from the start report faster adoption and more consistent use of the reporting tools that drive financial decisions.
The 5 stages of ADKAR explained
The Prosci ADKAR model builds on a simple premise: people move through change in a predictable sequence, and you can only advance once each stage is genuinely complete. Understanding what each stage actually demands from your team members is the first step toward using the framework effectively.
The five stages at a glance
Each stage in ADKAR targets a specific barrier that blocks adoption. The table below breaks down what each one means in practice.
| Stage | What it addresses | What success looks like |
|---|---|---|
| Awareness | Does the person know why change is happening? | They can explain the business reason clearly |
| Desire | Does the person want to participate? | They actively support the change, not just tolerate it |
| Knowledge | Does the person know how to change? | They understand new processes and their role in them |
| Ability | Can the person perform the new behaviors? | They execute correctly in real-world conditions |
| Reinforcement | Will the change stick over time? | Behaviors are sustained without constant supervision |
Desire is the stage most organizations underestimate, yet it is the one most responsible for sustained adoption failures.
How the stages connect
The five stages are sequential by design, which means a gap at any point blocks everything downstream. Your team member may complete every training session, but if their desire to change is low, their ability scores will look stronger on paper than they perform in practice. That gap shows up in data errors, workarounds, and slow close cycles.
Recognizing this sequential dependency changes how you diagnose adoption problems. Rather than assuming a resistant employee needs more training, ADKAR pushes you to check whether desire was ever fully built. The answer often reshapes your entire intervention plan.
How to apply ADKAR to an ERP rollout
Applying the prosci adkar model to an ERP rollout means treating the framework as an active project tool, not background reading. You build stage-specific activities into your project plan from day one, assign ownership for each stage, and measure progress at the individual level throughout the rollout, not just at go-live.
Start the process before configuration begins
Most ERP teams wait until training week to think about adoption. By that point, awareness and desire are already set, for better or worse. You need to start building awareness during the discovery phase, when business leaders can communicate the strategic case for change clearly and credibly. If your employees understand why the system is changing before they ever see a demo, desire becomes a much easier conversation to have.
The teams that start ADKAR conversations at project kickoff are the same teams that hit their go-live targets without emergency interventions.
Map your project phases to ADKAR stages explicitly. Awareness and desire belong in planning and discovery. Knowledge belongs in configuration and testing. Ability belongs in training and parallel runs. Reinforcement belongs in the first 90 days after go-live, where your finance team is executing real closes on the new system and building consistent habits.
Assign ownership at each stage
ADKAR does not run itself. Each stage needs a named owner who is accountable for measuring progress and resolving gaps before they compound. Executive sponsors carry the message that drives awareness and desire. Your project managers and department leads own knowledge transfer and skill-building. HR and line managers own reinforcement by tying new behaviors to performance expectations and direct feedback.
Without clear ownership, stages get assumed rather than executed. You end up at go-live with a team that completed training but still lacks genuine ability or desire, which is exactly the pattern that triggers rework, data errors, and budget overruns in the months after launch.
Common ADKAR pitfalls and how to fix them
Even teams that commit to the prosci adkar model from the start can undermine it with a handful of predictable mistakes. Knowing where these gaps typically appear gives you the ability to catch them early, before they turn into adoption failures that push your go-live date back or inflate your post-launch support costs.
Skipping awareness and assuming people will catch up
The most common mistake is treating awareness as a communication checkbox rather than a foundational stage that requires verification. Sending one email about the new ERP system does not build awareness. Your employees need to hear a clear, credible explanation of why the change is happening, what problem it solves, and what it means for their specific role. Without that specificity, confusion fills the gap and resistance follows quickly.
If your team cannot explain the business reason for the change in their own words, awareness is not complete.
Fix this by testing comprehension directly, through brief conversations with team leads or short pulse surveys, before you move the project into the knowledge phase.
Treating training as both knowledge and ability
Many teams deliver a training session and then mark both knowledge and ability as complete, but these are two separate stages. Knowledge means someone understands what to do. Ability means they can actually do it correctly under real conditions, with real data, real pressure, and real consequences. Confusing the two leaves your finance team technically trained but practically unprepared when the first live close cycle hits.
Fix this by building hands-on simulation exercises into your rollout plan. Supervised parallel runs, where employees execute actual processes in the new system before go-live, are the most reliable way to close the gap between theoretical knowledge and genuine operational ability.
Dropping reinforcement after go-live
Reinforcement is the stage teams most consistently cut when project budgets tighten or timelines compress. Without structured follow-up in the first 90 days, teams revert to old habits gradually and without much fanfare. Fix this by assigning your department managers specific reinforcement responsibilities, including regular check-ins, performance feedback tied to correct system use, and visible recognition when teams hit adoption benchmarks.
Next steps
The prosci adkar model gives you a precise, repeatable way to diagnose and resolve the adoption gaps that derail most ERP projects. When you apply each of the five stages deliberately, from building awareness before configuration begins to reinforcing correct behaviors through the first quarter post-launch, you protect the ROI your ERP investment is supposed to deliver. Most ERP failures trace back to skipped stages, not bad technology, and ADKAR gives you the diagnostic structure to prevent that pattern before it costs you.
Applying this framework effectively requires a partner who understands both the technical and human dimensions of ERP change. Concentrus works with CFOs and finance leaders to build change management into every phase of a NetSuite or Acumatica rollout, not as an add-on, but as a core driver of measurable outcomes. If you are planning an implementation or rescuing one that has stalled, talk to the Concentrus team about building adoption into your ROI plan from day one.