ERP AI change management: getting planners, buyers and supervisors to actually use it
ERP AI change management plan
Also searched as
- how to get planners and buyers to use an AI assistant
- AI adoption manufacturing change management
- ERP AI rollout resistance users
Short answer
Adoption follows trust and fit, not announcements. Start with one painful, repeated task for a small group of respected users, make answers checkable, state clearly what the tool will not do to jobs, and measure use weekly. Scale by word of mouth from named champions, not by mandate.
Applies to: Manufacturers rolling out a natural-language ERP assistant or agents to planners, buyers, schedulers, quality, finance and shop floor supervisors.
A rollout plan that respects how plants work
- 1Pick one workflow people already dislike: the Monday shortage report, past-due PO chasing, quote status lookups, or month-end variance questions. Solving a real irritation beats any training deck.
- 2Name two or three champions per site: respected, curious users, not only the most senior. Give them early access and a direct line to the project team.
- 3Write the trust rules in one page: answers show their source or query, users verify before acting, the tool is read-only at first, and nothing is written to the ERP without a human approving.
- 4State the job position plainly and early, agreed with HR: what the tool is for, whether it affects roles, and how time saved will be used. Silence is read as bad news.
- 5Train on the users' own real questions in short sessions, at the desk or on the floor, not in a classroom. Collect questions that failed and fix them visibly.
- 6Run a weekly feedback loop for the first eight weeks: top questions asked, wrong or weak answers, new requests, and what changed as a result.
- 7Track adoption as use by role and repeat use, not logins. Retire or fix use cases nobody returns to.
- 8Widen scope only after one group is using the tool without the project team in the room.
Why adoption stalls in manufacturing
Planners and buyers already have a way to get answers: their own spreadsheets, a trusted ERP inquiry screen, a colleague who knows the data. A new assistant has to beat that on speed and on trust. If the first three answers someone gets are wrong or hard to verify, they will not return, and they will tell colleagues.
The second cause is fear. Experienced people hear 'AI' and think about their jobs, or about being blamed when a machine-assisted decision goes wrong. A clear statement of what the tool does, what it does not do, and who owns the decision defuses a lot of this. Do not oversell; overselling creates the very scepticism you need to overcome.
The third is plain friction: another login, a screen away from where they work, or an answer format that does not match their habits. Single sign-on and a placement in the tools people already open each morning matter more than model quality in the early weeks.
Champions, training and the feedback loop
Champions are your adoption engine. Choose people others ask for help, give them time on their calendar, and let them shape the question library. A champion who says 'it found the late supplier lines in ten seconds' does more than a steering committee memo.
Training should be small and concrete. Take ten real questions from each team, run them live, show how to read the source or query, and show what a poor answer looks like and how to report it. Teach people how to phrase a question with an item, a site and a date range, because that improves results immediately.
Close the loop visibly. When a user reports a wrong answer and it is fixed, tell the group. Publishing a short weekly note of 'you asked, we changed' builds the habit of use and the belief that the system listens.
Weekly adoption check (first 8 weeks) - Active users by role (planner, buyer, QA, finance) - Repeat users in week N vs week N-1 - Top 10 questions asked - Questions with thumbs down or manual correction - Fixes shipped from last week's feedback - Open requests, with owner and date
Governance that supports adoption
Keep the permission model simple to explain: the assistant sees what you can see in the ERP, no more. If a buyer cannot open cost roll-ups in the ERP, the assistant should not reveal them. Tell users this directly; it settles many privacy worries.
Decide in advance what happens on a bad answer that someone acted on. A short, blameless review process, with the query and source preserved in logs, protects both users and the project. People will take reasonable risks with a tool when they know mistakes are handled fairly.
Be willing to say no to use cases that are not ready. Quote pricing, customer-facing output and anything that writes to the ERP should wait until the read-only experience has earned trust and approvals are designed.
Common pitfalls
- !Launching site-wide with an all-hands email and no champions.
- !Measuring logins rather than repeat use of useful questions.
- !Training in a classroom on generic examples instead of the team's own questions.
- !Leaving job questions unanswered until rumours fill the gap.
- !Fixing wrong answers silently, so users never learn the system improves.
- !Adding write-back automation before users trust the read-only answers.
How an ERP-grounded AI assistant handles this
With a grounded assistant such as ERPray, the shown query or source is the adoption mechanism: a planner can open the answer, see the table and filters behind it, and decide whether to trust it. Usage logs also reveal which questions people really ask, so your training and fixes follow actual demand. It respects ERP roles, so supervisors see only what they already may see, which removes one reason for resistance.
Frequently asked questions
Who should be the first users?
A small group with a daily, annoying, data-heavy task, such as planners handling shortages or buyers chasing past-due lines, led by one or two respected champions. They give honest feedback and their results travel by word of mouth. Avoid starting with executives or with the most sceptical group.
How do we handle fears about jobs?
Say plainly, with HR agreed, what the tool is for and whether any roles are affected. In most early deployments it removes lookup and report building so people spend time on decisions and exceptions. Do not promise what you cannot guarantee, and do not leave the question unanswered.
How long until we see steady adoption?
Expect weeks of focused support for the first group, then a slower spread as champions teach others. Judge by repeat weekly use among the target role rather than total accounts. If repeat use is flat after two months, revisit the use case, answer quality and where the tool sits in daily work.
Do we need a formal change management framework?
A light version is enough for a read-only assistant: sponsor, champions, communication, training, feedback loop and measures. Larger programmes with write-back or workflow changes benefit from a fuller approach and union or works council consultation where applicable. Match the effort to the scope of change.
Related
Staffing an ERP AI Team: What Roles You Actually Need
Most mid-market organizations do not need a dedicated ERP AI team at pilot stage - one ERP-literate technical owner working part-time with an implementation partner is enough. A dedicated team becomes worthwhile once you have more than two or three live AI use cases in production, at which point you need a named owner for prompt/data quality, one for integration and access, and a business-side owner for adoption.
CIO briefingDo You Need an ERP AI Governance Board?
Yes, once more than one AI use case touches ERP data - even a lightweight, four-person committee that meets monthly beats no governance at all. Its job is narrow: approve which ERP data an AI tool can touch, set the review cadence for accuracy and access, and own the kill switch if something goes wrong. It should not be a bureaucratic gate that slows every pilot to a crawl.
CIO briefingERP AI KPIs: which to track in the first 90 days and which to hold for later
Track three layers: adoption and quality as leading indicators (repeat use, answer accuracy on a fixed test set, time to answer), operational outcomes as lagging ones (report hours, expedite count, close days), and cost per active user. Fix baselines before launch, or you will not be able to prove anything.
CIO briefingMeasuring ERP AI ROI After Go-Live
Measure ROI with three metric families - time saved on named tasks, error or rework reduction, and adoption depth - tracked against a pre-go-live baseline you captured before the tool launched. Most CIOs skip the baseline and then cannot prove anything six months later, so capture it in week one even if the AI tool is not fully ready.
CIO briefingERP Upgrade or AI First? A CIO Decision Framework
In most cases, add a grounded AI layer on top of your current ERP first, because it proves value in weeks and shows exactly what an upgrade would need to fix. Reserve a full ERP replacement for cases where the platform itself is end of support, unsupported, or structurally blocking the business, not simply because it feels dated.
CIO briefingHow Much Does ERP AI Actually Cost?
A scoped pilot against one ERP module typically runs 15,000 to 50,000 USD; a single-department production deployment runs 50,000 to 150,000; a multi-module enterprise rollout runs 150,000 to 500,000 or more, plus ongoing hosting and usage costs. Native vendor copilots are usually priced per active user per month on top of existing licensing, not included free.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
AI for ERPAI for Infor LN: Sessions, BODs, and Engineer-to-Order Work
Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.
Stuck on ERP AI (any ERP)?
Talk to engineers who work inside ERP AI (any ERP) every week, and who build private AI that answers these questions from your own ERP data.