By Ritvars Mētra, Founder of ReadinessCompassThe ERP training curriculum has eleven courses, and they are named after the system: Procure to Pay, Order to Cash, Record to Report, Master Data Maintenance.
Nobody in the business has a job called Order to Cash. A customer service adviser has a job that touches four of those courses at three different depths, and will sit through the whole of two of them learning transactions they will never perform.
The curriculum is inheriting the wrong structure
Process-shaped courses come from the implementation team, because that is how the design was built and how the consultants are organised. It is a reasonable structure for configuring a system and a poor one for teaching a person their job.
The consequences are predictable. Attendance is high and relevance is low, so people disengage during the two-thirds that does not apply to them. Time is spent on transaction coverage rather than on the handful of tasks each role performs daily. And the exceptions — which is where the actual difficulty lives — get squeezed into the last twenty minutes, if at all.
Start from roles and tasks
A usable training needs analysis is a matrix, and it can be built in a couple of workshops if the impact work has been done. If a role impact assessment already exists, most of the input is there.
- Rows: real job roles, as the business names them — not org-chart titles and not personas. “Warehouse team leader, night shift” if that is a distinct job.
- Columns: the tasks that role performs in the new system, expressed as work rather than as transactions. “Receive a short delivery”, not “MIGO”.
- Cells: frequency and criticality. Daily, weekly, rare. And what happens if it is done wrong.
The matrix immediately reorganises the effort. Daily-and-critical tasks need practice to the point of fluency. Rare-but-critical tasks need a job aid and a known escalation route, because nobody retains a procedure they perform twice a year. Frequent-but-trivial tasks need five minutes. Most curricula treat all three identically.
| Task profile | What it needs | What it usually gets |
|---|---|---|
| Daily, high consequence | Repeated practice to fluency, at realistic volume | One demonstration in a classroom |
| Rare, high consequence | A job aid and a named person to call | A slide in week two, forgotten by go-live |
| Daily, low consequence | Five minutes and a reference | A full module |
| Exception handling | Worked examples of the real awkward cases | “Contact your super user” |
Design is only one of three factors
Even a well-built curriculum is a minority of what determines whether people can do the job afterwards, and there is a long-standing model that says so.
Timothy Baldwin and J. Kevin Ford’s review of transfer of training in Personnel Psychology holds that transfer depends on three things: trainee characteristics, training design, and the work environment — where work environment includes supervisory and peer support, and the constraints and opportunities to actually perform the learned behaviour on the job. They also define transfer as requiring both generalisation to the job context and maintenance over time.
Two things follow for an ERP programme. First, training that ends three weeks before go-live fails the maintenance condition almost by construction, because there is no opportunity to perform in between. Second, if a manager does not create time for people to practise, the curriculum quality is close to irrelevant — which is why manager readiness sits upstream of training effectiveness.
Markus and Tanis observed the same thing from the other end, listing “no growth of end-user skills after initial training” among the characteristic problems of the period after go-live. Capability plateaus at whatever the classroom produced unless something in the environment keeps it moving.
Sequence against the date, not the design
The most common scheduling error is running training when the configuration is stable rather than when people can use it. Stability is a programme convenience; retention is a human constraint.
A workable pattern for a fixed-date go-live:
- Six to eight weeks out: awareness and orientation. What changes, why, what your day looks like.
- Two to three weeks out: role-specific task practice, in a realistic environment, with the exceptions included.
- The final week: a rehearsal at volume rather than more content. This is the step that produces evidence as well as capability.
- After go-live: scheduled short sessions in weeks two and four, when people have real questions that a classroom could never have anticipated.
The post-go-live sessions are the cheapest item on that list and the first to be cut. They are also the only part that addresses maintenance.
What the analysis should produce
A finished training needs analysis is not a curriculum. It is four things, and only the first is a course list:
- A role-by-task matrix with frequency and criticality, agreed by the people who do the work.
- A statement of which tasks require demonstrated capability before go-live, and which need only awareness.
- A list of job aids for the rare-but-critical cases, with an owner.
- The environmental conditions that have to hold — practice time released, managers briefed, a system to practise in — each with a name against it.
The fourth item is the one that turns a training plan into a readiness plan, because it names the things that will quietly not happen and makes somebody accountable for them.
One output of the matrix deserves separate treatment. Rare-but-critical tasks need a job aid rather than a course, and a job aid is a different artefact from reference documentation even though most organisations produce only the second.
More on capability and readiness in the ERP Readiness Hub, or read why training completion and adoption are different measurements.