Training Is Not Adoption: Why ERP and AI Programs Need Practice, Not Just Learning

Training completion is one of the most seductive metrics in transformation management. It is clean. It is countable. It travels well in steering decks. It makes programmes look busy, responsible, and vaguely under control.

It also tells you very little about whether people can actually perform the new work under real conditions.

This is not an argument against training. Training matters. Of course it does. It gives people language, orientation, basic competence, and sometimes a little courage. But training completion is not adoption. It is, at best, an early signal that people have been exposed to the new way of working.

The difficult part comes later: when the employee is back at their desk, the customer is waiting, the month-end deadline is close, the data looks strange, the AI answer sounds plausible but slightly wrong, and the old workaround is still sitting there like a comfortable chair.

That moment — not the training session — is where adoption either begins or quietly dies.

• Training completion measures exposure; adoption measures changed behaviour.
• ERP and AI programmes fail when learning is not transferred into daily work.
• Practice must be role-based, scenario-based, and close to real operating conditions.
• Managers, not trainers, often decide whether new behaviours stick.
• Adoption should be measured through usage, proficiency, data quality, workflow compliance, and business outcomes — not attendance alone.

The training-completion trap

Most organizations already know, at least intellectually, that training attendance is not enough. The problem is that attendance is easy to measure, while adoption is messier. So the proxy becomes the truth.

A project reports:

• 96% of users trained;
• all sessions delivered;
• materials uploaded;
• recordings available;
• go-live readiness green.

Then go-live happens, and the real questions appear.

Can users complete the new workflow without help? Do they understand exceptions? Are they entering clean data? Are they avoiding shadow spreadsheets? Do they know when not to trust an AI-generated answer? Are managers asking for the new process, or quietly accepting the old one because “we’re too busy right now”?

The Kirkpatrick model is useful here because it refuses to stop at training activity. It distinguishes between reaction, learning, behaviour, and results. In its current framing, Kirkpatrick Partners explicitly describes the model as a way to move beyond “training completion” and toward measurable performance results.

That distinction is not academic hair-splitting. It is the difference between “people attended” and “the organization changed.”

Learning transfer: the old research still bites

The training-transfer literature has been telling us this for decades. Baldwin and Ford’s classic model of training transfer argues that transfer depends not only on what happens in the training room, but also on trainee characteristics, training design, and the work environment. Their model explicitly notes that even well-learned skills may fail to survive on the job because of weak motivation or lack of supervisory support.

That sentence should probably be printed on every ERP and AI programme wall.

Because this is exactly what happens in transformations. A user can learn a process in class and then abandon it because:

• their manager still asks for the old report;
• the new workflow takes longer during the first weeks;
• the support model is unclear;
• the system data is not trusted;
• the old Excel file gives an answer faster;
• nobody corrects the workaround.

Training creates the possibility of new behaviour. The work environment decides whether that behaviour survives.

Prosci’s ADKAR model says something similar in change-management language. Individual change requires Awareness, Desire, Knowledge, Ability, and Reinforcement — not knowledge alone. Prosci’s own reinforcement guidance is even more blunt: after go-live, organizations need feedback, corrective actions, performance measurement, accountability mechanisms, recognition, and incentives that support the change. It also warns that without reinforcement, the investment in awareness, desire, knowledge, and ability risks being wasted.

So yes, training matters. But training without practice and reinforcement is like teaching someone to swim by explaining water.

Why ERP adoption is especially unforgiving

ERP training is difficult because ERP rarely changes only a screen. It changes process logic. It forces functional work into integrated flows. It changes who sees what, when, and with what consequences.

Caporarello and Viachka describe ERP implementation as a shift from functional to process-based operational logic, where information integration increases transparency and may even create tension because supervisors can monitor performance more directly. They also note that ERP requires extensive training at all organizational levels, but the deeper issue is whether users feel capable of working in the system and understand the benefits of adopting ERP as a business strategy.

That is the bit training plans often underestimate. Users are not merely learning transactions. They are learning a new social contract around data, visibility, timing, accountability, and cross-functional dependency.

Kwahk and Lee’s ERP study makes the adoption issue harder to dismiss. Their research used 283 responses from 72 Korean organizations that had implemented enterprise-wide ERP systems. They found that readiness for change indirectly influenced ERP usage intention through perceived usefulness and perceived ease of use. Readiness for change and computer self-efficacy together explained 57% of the variance in perceived usefulness, with readiness adding 38% beyond computer self-efficacy alone; for perceived ease of use, they explained 43%, with readiness adding 21%.

In plain English: people don’t adopt ERP just because they know which button to click. They adopt it when they believe the system is useful, manageable, supported, and relevant to their work.

The old workaround has home-field advantage

This is the brutal truth of ERP adoption: the old way usually works well enough for the person using it. Not for the organization, perhaps. Not for auditability, not for process integration, not for data quality, not for global reporting. But for the individual employee under time pressure? The old spreadsheet, informal message, copied report, local macro, or personal checklist may feel safer.

That is why ERP practice must go beyond feature demonstration. Users need rehearsal under realistic conditions:

• What happens when master data is wrong?
• What happens when an approval is missing?
• What happens when a customer request does not fit the happy path?
• What happens when month-end pressure arrives?
• What should the user do instead of creating a shadow workaround?

The adoption risk is not ignorance alone. It is reversion under pressure.

AI makes the training problem even stranger

AI adoption has the same training problem, but with a twist. ERP users usually learn a defined process. AI users must learn a way of thinking, questioning, checking, and deciding under uncertainty.

Microsoft and LinkedIn’s 2024 Work Trend Index found that 75% of knowledge workers were already using AI at work, and 46% of those users had started less than six months earlier. Yet 60% of leaders worried their organization lacked a plan and vision for AI implementation, while 78% of AI users were bringing their own AI tools to work.

This is not orderly adoption. It is improvisation at scale.

AI training cannot simply show users how to write a prompt. That’s necessary, but thin. Users need to practice judgment:

• When is an AI answer good enough?
• When must it be checked against primary sources?
• What data can safely be entered?
• How should hallucinations be detected?
• When should AI be disclosed?
• Which tasks should not be delegated to AI at all?

McKinsey’s 2025 State of AI report argues that the value of AI comes from “rewiring how companies run,” not simply deploying tools. Its survey found that workflow redesign had the biggest effect on an organization’s ability to see EBIT impact from generative AI, yet only 21% of respondents using generative AI said their organizations had fundamentally redesigned at least some workflows.

That is revealing. AI programmes can train people on tools, but if workflows remain untouched, value stays trapped at the individual level. Someone writes an email faster. Someone summarizes a document faster. Nice. But the organization still approves slowly, duplicates work, measures the wrong things, and argues in meetings from half-clean data.

What real adoption practice looks like

Better training does not mean longer training. In many cases, longer training is just a slower way to lose people.

The better question is: what practice architecture helps users transfer learning into work?

1. Role-based scenarios, not generic feature tours

A finance controller, sales planner, HR business partner, warehouse supervisor, and procurement specialist do not need the same adoption experience. They may use the same system, but they do not face the same risks.

Role-based practice should mirror actual job tasks:

• complete a standard transaction;
• handle a common exception;
• interpret system output;
• decide what to do when the system conflicts with local habit;
• escalate correctly.

In AI programmes, role-based practice matters even more. A legal team needs source-checking and confidentiality discipline. A marketing team needs brand voice and claim verification. A customer service team needs escalation boundaries. An analyst needs assumptions, data provenance, and output validation.

2. Practice with realistic data

The classroom demo always works because the demo data behaves. Real data sulks.

ERP users need to practice with examples that resemble the messy reality they will face: incomplete records, duplicate customers, unusual order types, missing approvals, awkward country-specific requirements. AI users need prompts and documents that reflect their actual work, including ambiguity, poor source material, and conflicting instructions.

People do not build confidence from perfect examples. They build confidence by surviving imperfect ones.

3. Spaced practice around go-live

One of the easiest ways to waste training is to deliver it too early. People attend, nod, pass a quiz, and then do not use the skill for six weeks. By go-live, much of the learning has evaporated, but the dashboard still says “trained.”

A more sensible rhythm looks like this:

• early awareness and concept learning;
• hands-on practice close to go-live;
• short refresher sessions immediately before cutover;
• floor-walking or virtual support during hypercare;
• targeted re-practice based on support-ticket patterns;
• post-go-live adoption clinics for difficult scenarios.

Not elegant. Effective.

4. Manager reinforcement in team routines

Managers are the adoption layer many programmes politely underuse.

If a manager keeps asking for old reports, old spreadsheets, old meeting formats, and old performance signals, users will quite rationally conclude that the new way is optional. If managers do not understand the change themselves, they cannot reinforce it. If managers do not correct workarounds, workarounds become the real operating model.

Manager reinforcement should be concrete:

• review new-system reports in team meetings;
• ask for decisions based on new data sources;
• challenge shadow spreadsheets;
• recognize clean adoption behaviours;
• make space for practice during the productivity dip;
• escalate structural blockers instead of blaming users.

The manager’s question should not be, “Did your team complete training?” It should be, “Can my team now perform the work differently?”

Measuring adoption beyond training completion

Training completion should stay on the dashboard, but it belongs in the bottom drawer. It is a necessary input metric, not an adoption metric.

A better adoption dashboard should combine four kinds of evidence.

Learning evidence

This tells you whether users understood the basics.

• assessment scores;
• scenario pass rates;
• confidence ratings before and after practice;
• ability to explain the new process, not just click through it.

Behaviour evidence

This tells you whether work is actually changing.

• system usage by role and process;
• transaction completion without support;
• workflow compliance;
• drop in old workarounds;
• AI usage in approved tools rather than shadow tools;
• manager reinforcement activity.

Quality evidence

This tells you whether adoption is good enough.

• data-error rates;
• rework volume;
• support tickets by root cause;
• AI output correction rates;
• approval-cycle defects;
• audit or compliance issues.

Outcome evidence

This tells you whether the change is producing business movement.

• cycle-time reduction;
• forecast accuracy;
• fewer manual reconciliations;
• faster case resolution;
• improved data availability;
• reduced duplicated effort;
• measurable productivity gains that are actually captured, not merely imagined.

McKinsey’s AI research makes this point directly: among adoption and scaling practices, it highlights tracking well-defined KPIs, embedding AI into business processes, creating role-based capability training, building trust, collecting feedback, and reinforcing adoption through incentives. Less than one-third of respondents reported that their organizations were following most of the 12 adoption and scaling practices.

The pattern is familiar. Organizations buy tools faster than they redesign work.

Common mistakes when training is treated as adoption

The first mistake is declaring readiness because training is complete. This is probably the most common one, and maybe the most forgivable, because deadlines create optimism. Still, it is dangerous. Readiness requires capability, confidence, support, and reinforcement.

A second mistake is generic training. It is administratively efficient and behaviourally weak. People do not adopt generic change. They adopt the version that touches their own tasks, risks, and incentives.

A third mistake is training too early or too late. Too early, and knowledge decays. Too late, and people learn while already under operational pressure. Both create avoidable anxiety.

A fourth mistake is separating training from hypercare. The support team then becomes a reactive helpdesk rather than a learning-feedback engine. Support tickets should shape re-training, process clarification, communication, and even design fixes.

A fifth mistake is ignoring the emotional side of competence. People can be trained and still feel unsafe. ERP exposes mistakes. AI creates uncertainty about judgment and replaceability. Microsoft’s Work Trend Index found that 52% of people using AI at work were reluctant to admit using it for important tasks, and 53% worried that using AI on important work made them look replaceable. Hidden use is not adoption maturity. It is adoption without trust.

The better principle: practice until the new way becomes easier than the old way

Adoption happens when the new behaviour becomes credible, supported, and easier to sustain than the workaround.

That takes practice. Not one heroic training push. Not one beautiful e-learning module. Not a completion report with green cells. Practice.

For ERP, practice means users can execute real workflows, handle exceptions, trust the data, and know where to go when something breaks. For AI, practice means people can use tools responsibly, question outputs, protect sensitive information, and integrate AI into the actual rhythm of work rather than treating it as a clever side assistant.

Training tells people what the new way is. Practice lets them become the kind of worker who can use it under pressure.

Which raises the measurement question. Completion and satisfaction describe the first two levels of the Kirkpatrick model and say nothing about capability; unaided completion rate is what makes behaviour measurable, and it is obtainable in half a day per function.

And maybe that is the line transformation leaders should use more often in steering committees: we are not done when people have learned it. We are done when the new way survives contact with Monday morning.

Training gaps are one of the more common sources of adoption risk. Browse adoption risk resources for related material on capability, manager capacity and early warning signals.