Somewhere in your statement of work there is a line that says “end user training, 5 days”. That number was set by someone who had never met your accounts payable team, before anyone knew what the solution design would look like. It is now the only training plan you have.
The pattern that follows is familiar. Everyone sits through a demonstration three months before go-live. They nod. On day one they cannot find the screen, so they ask the person next to them, who also cannot find it. Within a fortnight half the business has invented workarounds in Excel.
An ERP training plan that survives contact with reality is not longer than the one in the statement of work. It is shaped differently.
Table of contents
Stop designing one course for everyone
Generic training fails for a structural reason. An ERP is not one product, it is thirty products sharing a database. A warehouse operative and a management accountant have almost nothing in common in their use of it, and a course that serves both serves neither.
Role-based design means you start from a list of roles, not a list of modules. For each role you write down the transactions that person performs in a normal week, the ones they perform at period end, and the exceptions they have to handle.
That list, not the software’s menu structure, becomes the curriculum.
| Role | What they actually need | Format | Realistic duration |
|---|---|---|---|
| AP and AR clerks | Their eight to twelve daily transactions, to speed, plus the three exceptions that occur weekly | Hands-on in a sandbox, small groups | 6 to 8 hours across 2 sessions |
| Warehouse and despatch | Scanning, picking, receipting, stock adjustments, on the device they will actually hold | On the floor, on real hardware | 3 to 4 hours plus supervised practice |
| Sales and customer service | Quote to order, pricing rules, credit holds, order amendment, customer enquiry | Hands-on, scenario-based | 4 to 6 hours |
| Buyers and planners | Requisition to receipt, supplier management, reorder logic, the reports they will live in | Hands-on plus report walkthrough | 6 to 8 hours |
| Finance team | Period end sequence, reconciliations, dimensions, reporting, correction and reversal | Hands-on, plus a full dry-run close | 2 to 3 days including a practice close |
| Approvers and managers | Approving, rejecting, delegating, and reading the three reports they will be asked about | Short, focused, ideally 45 minutes | 1 hour, once |
| System administrators | User and licence administration, security roles, environment management, support escalation | Partner-delivered, technical | 2 days |
Approvers are the group most often overtrained. A department head who approves eleven requisitions a month does not need a half-day course. They need forty-five minutes and a card. Offer the half day and they will not attend at all.
Train the trainer, and where the model breaks
The train-the-trainer model uses your super users as the delivery channel. The partner trains a small group deeply, that group trains everyone else, and the knowledge ends up inside your business instead of on an invoice. It is usually the right choice, but it fails in three specific ways.
It fails when super users are trained on the software rather than on teaching. Knowing the system is a prerequisite, not a qualification. Give them a short session on how to run a hands-on class, and make them deliver one practice session to a friendly audience before they face a real one.
It fails when super users are given no time. A person who is expected to deliver six sessions, answer questions for a fortnight and do their day job will deliver two sessions badly.
This is the same backfill problem the whole project has, and it is covered in detail in our guide to ERP implementation team structure.
It fails when nobody owns the content. Super users are excellent at delivery and inconsistent at documentation. Have the partner produce base materials and have super users adapt them with your terminology, customer names and part numbers. Adaptation is fast. Authoring from nothing is not.
There is also something a training plan usually ignores. Prosci’s benchmarking research on change communication finds that employees want the business reasons for a change from senior leaders, and the personal impact on their own job from their immediate manager.
Neither message should be heard first in a training session run by a colleague from another department.
Timing: the window between forgetting and panicking
Too early and people forget. Too late and they panic, and you have no time left to fix what the training reveals.
The workable window for most end user training is two to four weeks before go-live, with three qualifications. Super users train much earlier, because they need to be competent enough to build test scripts.
Finance needs a practice period close scheduled around your actual close calendar. And everyone needs a short refresher in the last week, so the final hands-on contact falls within about five working days of the first live transaction.
| When | Who | What | Why then |
|---|---|---|---|
| End of design | Super users | Deep functional training on configured system | They cannot write test scripts without it |
| During system testing | Super users | Teaching skills, session practice | Delivery capability takes time to build |
| 4 weeks out | Finance | Practice period close in the sandbox | Reveals reporting and reconciliation gaps while there is time |
| 3 to 4 weeks out | Warehouse, despatch | On-device training on real hardware | Device and network problems surface here, not at go-live |
| 2 to 3 weeks out | Transactional roles | Role-based hands-on sessions | Close enough to retain, far enough to fix problems |
| 1 to 2 weeks out | Approvers, occasional users | 45 minute session plus reference card | Any earlier and they will not remember |
| Final week | Everyone | Optional refresher clinics, drop-in | Last contact before the first live transaction |
If the cutover date moves, the training schedule moves with it. Training delivered five weeks early because the date slipped is training you will repeat. Build the dependency into the plan. Our ERP cutover plan guide shows where the training milestones sit.
Train on your data, not on demo data
This is the highest-return change you can make to a training plan, and it gets skipped because it depends on the migration being on schedule.
Training in a sandbox loaded with your own migrated data means people see their own customers, part numbers, chart of accounts and pricing. It also turns every session into an extra round of data validation, because users spot wrong data in their own records faster than any reconciliation report will.
Three practical points. Refresh the training sandbox from the most recent trial load, or you will spend the session explaining that the data is stale. Mask or exclude genuinely sensitive records such as payroll and personal contact data, since a training environment has looser access controls than production.
And keep it separate from the UAT environment, because a trainee who posts a journal mid test run will cost your testing coordinator a day.
The relationship runs both ways. Poor migrated data makes training unconvincing, and training exposes poor migrated data. Our ERP data migration strategy guide covers the trial load cycle that feeds this.
Build the quick reference material before you need it
Nobody reads a 200 page user manual. They read one page, once, at the moment they are stuck.
The material that actually gets used has three properties: one page, one task, available at the point of work. That means a laminated card by the goods-in terminal, a pinned document in the team’s Teams channel, and a short clip for anything over six steps.
A useful set for a mid-market implementation is roughly twenty to thirty one-page job aids, not one large document. Write them in the second person, numbered steps, a screenshot per step, and an “if this goes wrong” block at the bottom.
Name the file after the task the user wants to achieve, not the transaction code. Record sessions as you deliver them: unedited recordings indexed by topic are cheaper and more useful than produced video, and they capture the questions people actually asked.
Measure competence, not attendance
An attendance register tells you who was in the room. It tells you nothing about whether they can do the job on Monday.
The Kirkpatrick Model sets out four levels: reaction, learning, behaviour and results. Kirkpatrick Partners, who maintain the model, make two points that matter for an ERP project. Level 2, learning, measures the degree to which people acquire the intended knowledge, skills, attitude, confidence and commitment, so confidence is part of the measurement rather than an optional extra.
And they recommend planning from Level 4 backwards, starting from the organisational result you need rather than the course you intend to run. The model was created by Donald Kirkpatrick in the 1950s and later updated by Jim and Wendy Kirkpatrick as the New World Kirkpatrick Model, which gives more weight to what happens after the course: the workplace conditions, processes and reinforcement that decide whether the new behaviour survives.
That distinction matters on an ERP project, because a good training session still fails if the conditions around it do not support the new way of working.
The same conclusion arrives from outside the training industry. In Why Leadership Training Fails and What to Do About It, Michael Beer, Magnus Finnström and Derek Schrader call it the great training robbery: organisations spent close to $356 billion globally on employee training and education in 2015 and did not get a good return, because for the most part the learning does not improve organisational performance, since people soon revert to their old ways of doing things.
Their prescription is that context is crucial, so the needed fixes in organisational design and management processes have to come first. On an ERP project that is a practical instruction rather than a theory.
If the new approval route, the new process ownership and the new reporting are not genuinely in place on the Monday after go-live, no amount of training will make people work the new way.
In practice, for an ERP go-live, that means a short practical assessment rather than a quiz. Something like this, run by the super user, scored by observation:
| Role | Competence check | Pass standard |
|---|---|---|
| AP clerk | Enter a three-way matched invoice, a non-PO invoice and a credit note | All three completed unaided in under 15 minutes |
| Order entry | Create an order for a credit-held customer and resolve it correctly | Correct escalation path followed without prompting |
| Warehouse | Receipt a partial delivery and record a discrepancy | Correct on first attempt, on the real device |
| Finance | Run the trial balance, drill to source, post a correcting journal | Unaided, with correct dimension coding |
| Approver | Approve one item and reject one with a reason | Completed in under 3 minutes without help |
Report the pass rate by team in the go-live readiness pack, alongside the data and testing measures. A team at 60 percent competence two weeks out is a finding the sponsor needs. Our ERP go-live readiness assessment scores it as a criterion.
Is your training plan a plan, or a line item?
Alphavima will review your current training approach against your scope, your roles and your go-live date, and give you a role-based schedule with competence checks you can take to your sponsor. Send us your statement of work and your go-live date to start.
Resistance is usually information
The least useful sentence in ERP delivery is “the users are resistant to change”. It describes a symptom as a diagnosis, and it invites more communication aimed at people who understood perfectly well the first time.
In our experience most resistance on ERP projects is one of four things, and only the last is actually about change.
The new process is genuinely worse for that person. A step that took two clicks now takes seven because a control was added upstream. The person complaining is right. Either the control is worth the cost, in which case say so, or the design needs another look.
The new process exposes something. A manual step used to absorb a data quality problem, a margin adjustment or an approval that was never really given. The system now makes it visible. This resistance is usually quiet and expressed as a technical objection.
The person has not been given the time to become competent. They are being asked to learn a new system while carrying the same workload, and their objection is a resourcing complaint wearing a training costume.
The person does not understand why. This is the only category where more communication helps, and it is the smallest of the four.
Change management models help structure the response, as long as they are attributed properly. The Prosci ADKAR Model breaks individual change into five elements: awareness of why the change is needed, desire to participate in and support it, knowledge of how to change and what success requires, ability to put new skills and behaviours into practice, and reinforcement to sustain the new way and prevent backsliding.
Prosci is explicit that ADKAR is a model for individual change rather than a complete change management methodology, and that the elements are sequential but not linear. Its value on an ERP project is diagnostic: it tells you which of the five is missing, and stops you answering a knowledge problem with an awareness campaign.
Kotter’s 8 Steps for Leading Change work at the organisational level instead. As currently published by Kotter International the steps are: create a sense of urgency, build a guiding coalition, form a strategic vision, enlist a volunteer army, enable action by removing barriers, generate short-term wins, sustain acceleration, and institute change.
Note that the original linear 8 Steps from Leading Change were developed by Kotter into the 8 Accelerators described in Accelerate (2014) and the firm’s 2021 book CHANGE, so any summary presenting them as a strict one-way sequence is describing an earlier version.
There is also a formal standard for the competence side: ISO 10015:2019, Quality management, guidelines for competence management and people development, reviewed and confirmed in 2025. Useful if you already run an ISO 9001 system and want the training plan to sit inside it.
What a realistic training budget looks like
Training is usually the first line compressed when a proposal needs to look cheaper, and the compression is invisible until go-live. If your quote allocates less than about 8 percent of total project effort to training and materials, ask what was removed.
Our guide to comparing Business Central partner quotes covers the line items that get quietly trimmed.
The costs people forget are not the trainer’s time. They are the room and the machines, the super user hours spent preparing and delivering, the sandbox refresh, the job aid authoring, and the fortnight after go-live when your most capable people answer questions instead of working.
Budget that fortnight explicitly. It is the cheapest support you will ever buy, and it is the difference between a business that adopts the system and one that works around it.
Frequently asked questions
How long before go-live should ERP training happen?
Most end user training lands best two to four weeks before go-live, with a short refresher in the final week so the last hands-on contact is within about five working days of the first live transaction. Super users need deep training much earlier, at the end of design, because they cannot write test scripts without it. Finance needs a practice period close roughly four weeks out.
What is the train-the-trainer model in an ERP implementation?
The partner trains a small group of super users deeply, and that group then trains everyone else. It keeps knowledge inside your business and costs less than partner-delivered training for every user. It needs three things to work: super users trained in how to teach as well as what to teach, protected time to prepare and deliver, and base materials produced by the partner that super users adapt rather than author from scratch.
Should ERP training use demo data or our own data?
Your own migrated data, in a sandbox refreshed from a recent trial load. People learn faster on records they recognise, and every session becomes an extra round of data validation because users spot errors in their own customers and parts quickly. Mask or exclude genuinely sensitive records, and keep the training environment separate from the UAT environment.
How do we measure whether ERP training worked?
Score competence, not attendance. Give each role a short practical assessment performed in the sandbox and observed by a super user, with a defined pass standard, and report the pass rate by team in the go-live readiness pack. The Kirkpatrick Model calls this Level 2, learning, and it measures knowledge, skills, attitude, confidence and commitment rather than satisfaction with the course.
What do we do about users who resist the new ERP?
Treat resistance as information first. In most cases it is one of four things: the new process is genuinely worse for that person, the system has made something visible that a manual step used to hide, the person has not been given time to become competent, or they genuinely do not understand why. Only the last is fixed by more communication. Diagnose which one you have before you respond.
How many training materials does an ERP go-live need?
Roughly twenty to thirty one-page job aids for a mid-market implementation, not one large manual. Each one covers a single task, is named after what the user is trying to achieve rather than the transaction, uses numbered steps with a screenshot per step, and ends with a short "if this goes wrong" block. Recorded sessions, indexed by topic, cover the rest.
Who should deliver the message about why the ERP is changing?
Senior leaders deliver the business reasons, and each person's immediate manager delivers what it means for their own job. Prosci's benchmarking research on change communication identifies these as the two preferred senders, and a training session run by a colleague from another department is the wrong channel for either message.