ERP Adoption Training: Stop the Spreadsheet Fallback
Staff who quietly rebuild spreadsheets after an ERP go-live were never trained for the task in front of them. Here is how role-based training closes the gap.
Most failed erp adoption training programmes do not fail loudly. They fail quietly, about six weeks after go-live, when a familiar spreadsheet reappears on someone's desktop and the ERP becomes the place where the "official" number is typed in after the real work has been done elsewhere. This article is for HR and L&D leads, operations managers and trainers who suspect that is happening, and who want training that changes behaviour rather than ticking a completion box.
Why ERP adoption training fails when the spreadsheets quietly return
The return of spreadsheets is rarely a sign that people are lazy or resistant to change. It is feedback. Something in the new system is slower, less clear or less trusted than the workaround, and nobody has addressed it. Treat the spreadsheet as a diagnostic instrument and it will tell you exactly where your training or your design is falling short.
What the spreadsheet comeback actually tells you
A shadow spreadsheet usually persists because it does one of three jobs: it holds a calculation people cannot find in the ERP, it preserves a local view that the ERP reports do not provide, or it lets someone complete a step they were never shown how to do. Each points to a different remedy. Before commissioning more training, find out which one you are looking at.
The difference between a skills gap and a design gap
A skills gap means the person could do the task correctly if they knew how. A design gap means the ERP genuinely does not support the task as configured, or requires so many steps that the workaround wins. Training cannot fix the second, and pretending otherwise wastes everyone's time. The TechTarget analysis of software change notes that adoption stalls precisely when the change effort stops and the practical friction begins [1].
The Tuesday test: ask a new starter to do the job unaided
Pick a recent joiner, give them the training materials you currently publish, and ask them to complete one real task with no help. If they cannot, your materials — not your people — need work. This test is fast, brutal and far more informative than a satisfaction survey.
Spreadsheets are a symptom, not a discipline problem
Framing the workaround as indiscipline poisons the conversation. People will hide the spreadsheet instead of explaining it. Ask neutrally: "What does this sheet do that the system doesn't?" The answer is your training brief, or your change request.
Spot the workarounds your ERP adoption training missed
Workarounds leave traces. You do not need surveillance software; you need to read the signals you already have and ask the right people the right questions. The first ninety days after go-live are when patterns set, and when they are easiest to correct.
Five signals in the first ninety days
- Repeat tickets on the same transaction type, often with the same words: "how do I…"
- Data entered late, or in batches, suggesting it is being captured elsewhere first.
- Users exporting to Excel immediately after running a report.
- The same two or three people being asked for help by everyone around them — informal experts filling a training vacuum.
- Process steps that exist in the procedure document but never appear in the audit trail.
Reading the support queue as a training map
Your service desk tickets are a curriculum written by your users. Group them by task rather than by module, count the repeats, and you have a ranked list of the videos and refresher sessions you most need. A ticket that appears twenty times in a month is not a support problem; it is a missing two-minute demonstration.
Who to ask, and what to ask them
Ask the informal experts first — they know where the friction is. Then ask the people who have quietly stopped using a function. Avoid asking "did you find the training useful?" Ask instead: "Show me how you do this task today." The screen they open tells you more than any survey.
Separating a training failure from a missing feature
| Observation | Likely cause | Right response |
|---|---|---|
| Task done correctly but slowly | Skills gap | Short, role-based refresher |
| Task done in a spreadsheet and pasted in | Missing report or field | Change request, then re-record |
| Task skipped when busy | Unclear priority or ownership | Manager reinforcement |
| Task attempted, error repeated | Interface confusion | Annotated screen recording |
Design ERP adoption training around roles, not modules
Module-based training mirrors the vendor's sales structure, not the user's working day. Nobody logs in to "use the finance module"; they raise a purchase order, approve a timesheet or correct a stock count. Role-based ERP training videos start from those tasks and stop when the task is complete.
Start from the tasks a person actually does
List the ten most frequent tasks for each role and rank them by frequency and consequence of error. Train the top five properly rather than the whole system superficially. Most users need a small, stable set of procedures done well; the long tail can wait for a support call.
Map each role to a short, specific video
Create a simple matrix: role, task, video, owner, last reviewed. A warehouse supervisor might have six clips; a finance controller twenty. This is your erp knowledge transfer training asset, and it survives staff turnover far better than a slide deck buried in a shared drive.
For the onboarding side of this — getting new starters to the right clip at the right moment — see our guide to creating employee onboarding videos for internal software.
Keep the training inside the system they use
Training that lives in a separate learning platform competes with the task in front of the user. Put links to the relevant clip directly beside the procedure, on the intranet page people already open, or in the team channel. The closer the help is to the screen, the more likely it is to be used in the moment of need.
How long each role-based clip should be
Roughly 60 to 120 seconds for a single task. Attention online is short and unforgiving; widely cited usability research from the Nielsen Norman Group shows users leave pages quickly, and that assumption should shape every training asset you record [2]. If a task genuinely needs longer, split it.
One task, one video, one real record
Use a genuine example record — a real-looking customer, a plausible order — rather than "test 123". Users copy what they see. If the demonstration uses realistic data, the mental transfer to their own work is far quicker.
Practical takeaway: if you cannot describe a training clip in one sentence starting with a verb ("Raise a purchase order", "Reverse a goods receipt"), it is too broad to be useful.
Record ERP adoption training from the live system
Recordings made from the live system, at the version people actually use, beat generic vendor material every time. The screens match, the buttons are where users will find them, and the awkward bits can be shown rather than skipped.
What a 60–120 second annotated demonstration should show
- The starting point: where to click and what the screen looks like before you begin.
- The fewest steps that complete the task, narrated in plain language.
- The one mistake people commonly make, shown and corrected.
- The confirmation that the task worked — the saved record, the confirmation message.
Show the real screens, including the awkward ones
Do not edit out the warning dialogue or the two-step confirmation. Those are exactly where new users hesitate and where support tickets originate. Honest recordings build trust; polished ones build suspicion when reality does not match.
Version and date every recording
Put the release number and recording date in the title card and in the file name. When a user reports a problem, you can immediately tell whether they are following an out-of-date clip. This single habit prevents a great deal of confusion during quarterly updates.
Why screen recordings beat slide decks after go-live
Slides explain concepts; recordings show actions. After go-live, people do not need to understand the philosophy of the ERP — they need to complete a task before lunch. A recording is also cheaper to update: re-record two minutes, not rebuild a deck.
Measure whether ERP adoption training changed behaviour
Completion rates measure attendance, not competence. To know whether your erp user adoption training worked, look at what people do, not what they clicked.
The metrics worth tracking after go-live
- Volume of repeat tickets by task, month on month.
- Time to complete a standard task, sampled from the audit trail.
- Number of active shadow spreadsheets found and retired.
- Proportion of transactions entered same-day rather than batched.
- New-starter time to first unaided completion.
Where to look for evidence
System logs, support tickets and short observation sessions give you more than surveys. The Prosci ADKAR model is a useful lens here: it separates awareness, desire, knowledge, ability and reinforcement, and it is reinforcement — the post-go-live follow-through — that most programmes neglect [3]. Track each dimension separately so you know which one is weak.
When to re-record instead of re-train
If people can explain the task but still do it wrongly, the material is probably unclear or out of date. Re-record the clip rather than booking another classroom session. If people cannot explain the task at all, you have a knowledge problem and a short targeted session is appropriate.
Keep ERP adoption training alive after the first quarter
The first quarter gets attention because the project is visible. The second year is where adoption quietly erodes unless someone owns the training library.
Refresh triggers: releases, process changes, new starters
Define what forces a review: a major ERP release, a change to a controlled process, a new role, or three tickets on the same clip within a month. Without triggers, recordings drift out of date and lose credibility.
Hand ownership to operations, not just project teams
Project teams disband. Operations managers, HR and L&D are still there when the next release lands. Transfer the role-to-video matrix to them with a named owner and a review date before the project closes.
A simple maintenance cadence
A quarterly review of the top twenty clips, an annual full audit, and a standing item at the operations meeting is enough for most organisations. Post-go-live training support does not need a large programme — it needs a small, reliable habit.
ERP adoption training: what to do in the next thirty days
Vidabug fits here as a way to produce and maintain role-based software training videos quickly. It films narrated demonstrations of real software, tests the application the way a new user meets it, and can repair the defects it can prove on separate branches the owner reviews, recording the evidence. It does not certify software as bug-free and it is not a penetration or load test, so treat it as a fast route to good training material and clearer defect reports, not a guarantee of adoption.
Publish one annotated demonstration this week
Choose the single task that generates the most repeat tickets. Record it in under two minutes, annotate the key click, and publish it next to the procedure. Do not wait for a full library.
Pick the role most likely to fall back
Look at your support queue and shadow spreadsheets, and identify the role with the most friction. Give that role three clips before you build anything else. Early wins create the appetite for the rest.
Review the result with the people doing the job
Two weeks later, ask a handful of users to show you the task again. If ticket volume on that task falls and the spreadsheet stops appearing, you have proof that erp adoption training can change behaviour — and a template for the next role.
Effective erp adoption training is less about teaching the software than about removing the reasons people avoid it. Find the workaround, watch how the task is really done, record a short honest demonstration, and keep it current. Do that consistently and the spreadsheets lose their purpose.
[1] Software change stalls when adoption begins | TechTarget
[2] How Long Do Users Stay on Web Pages? — Nielsen Norman Group
Questions people ask
Why do staff go back to spreadsheets after an erp rollout?
Usually because the new system is slower or less obvious for one specific task, and nobody has shown them the right path through it. The spreadsheet fills a gap the training never covered, so it survives long after the classroom sessions end.
How can erp adoption training stop spreadsheet workarounds?
Train on the task rather than the module, using the live system and real records, and keep each demonstration short enough to watch at the desk. Support articles that describe software change stalling as adoption begins note that the hard work starts once the system is live, not at go-live.
What is role-based erp training and does it work?
It means each person learns only the tasks their role performs, with examples from their own area rather than a generic tour of the whole application. It works because the learner can connect the demonstration to a job they already have to finish that day.
When should post-go-live refresher training happen?
Within the first two to four weeks, when questions are still fresh, then again whenever a release changes a screen or a process. Watch the support queue and the workaround files: both tell you where a refresher is overdue.
How do we train staff on an erp with no spare time?
Keep it to 60–120 seconds per task and put the link next to the task in your knowledge base or intranet. Short, annotated demonstrations can be watched once before doing the job, which is far easier to schedule than another half-day session.
How do we measure whether erp training actually changed behaviour?
Track rework rates, the number of manual spreadsheet versions on shared drives, support ticket themes, and how quickly a new starter completes a core task unaided. Compare a role before and after the training is published rather than surveying satisfaction.
Sources
- Software change stalls when adoption begins | TechTarget — techtarget.com
- How Long Do Users Stay on Web Pages? - NN/G — nngroup.com
- The Prosci ADKAR® Model | Prosci — prosci.com