Training and adoption

“120 staff trained” is not an achievement. It is an attendance count.

The only question: how many of them can do their job on the system tomorrow without help? Anybody not measuring that finds out in go-live week, when support channels fill with questions the training should have answered.

Train by role, not by module

The commonest training mistake is organising it around system modules: a day for purchasing, a day for inventory, a day for finance.

An employee does not work in a module. They work in a role.

A storekeeper needs: receiving, packing slips, stock counts, and printing a document. Those sit across three modules, and they need nothing else in any of them.

So build a matrix: roles down the rows, tasks across the columns. Then train each role on its own tasks only. The result: less training time, higher retention, and no employee sitting through two hours of an explanation that does not concern them.

Super-users — chosen against criteria

The super-user network is what makes support survivable in week one. Somebody who answers a question from the next desk is faster than any support ticket.

Who is chosen? Not whoever volunteers, and not whoever is best with computers.

Three criteria:

• Whoever their colleagues already ask — before the new system. The informal authority already exists, and the intelligence is in using it.
• Whoever knows the process rather than the software.
• Whoever will stay. Training somebody who leaves in three months is wasted spend.

One per ten to fifteen users, with a published time allocation after go-live of no less than 20% — otherwise they become ordinary users carrying an extra burden.

The competence standard

Training ends with proof rather than with attendance.

Each role gets a short test on the system itself: three to five real tasks, executed without help, within a set time.

The result is a number that is measured and presented: what share of each role passed? Any role below 80% needs an extra session before go-live, not after.

That number is the most useful human readiness indicator you have, and it belongs in the steering committee alongside the testing indicators.

The material that survives

The slide deck is forgotten. Three things survive.

• A one-page role guide: the daily tasks with their steps, printed and pinned up.
• Short clips, one to three minutes per task — watched at the moment of need rather than at the moment of training.
• A training environment left open after go-live, where staff can experiment without fear of damaging real data.

The third is usually closed to save cost, and it is the cheapest item on the list and the most effective.

When training starts

Timing decides the effect here more than content does.

Timing	What happens
Two months before go-live	It is forgotten. People train on what they will not use for eight weeks
One to three weeks before	Correct — close enough to be remembered, far enough to fix what surfaces
After go-live	People learn on real transactions, and their mistakes become journal entries

The first row is the common error at well-run projects, because it looks like good preparation. It is not: a skill unused for eight weeks disappears, and the real training happens in go-live week under pressure.

One exception: super-users are trained early — two months out — because they will train twice: once to learn, and once when they teach. Teaching is the strongest form of retention.

And after go-live, a second round in week three. By then people have hit their real questions, and an hour then is worth a full day before go-live.

Measuring adoption after go-live

Adoption is measured from system data rather than from impressions. Four indicators, read weekly for the first two months.

Indicator	What it reveals
Share of documents created in the system against outside it	Parallel working in spreadsheets — the most dangerous indicator
Document cycle time from creation to approval	A bottleneck in approvals
Count and age of pending documents	A process nobody understood
Support questions classified by role	Which role was undertrained

The first indicator is what exposes silent failure. A working system with a company running itself on a spreadsheet beside it is the definition of a failed project, and it appears in no fault report. See why ERP projects fail.

What you actually do in this station

• Build the role and task matrix before writing any training material.
• Choose super-users against the three criteria, and get their time allocation in writing.
• Write a competence test per role, and present the pass rates at the steering committee.
• Prepare the one-page guides and the short clips before go-live.
• Ask for the training environment to stay open for six months after go-live.
• Define the four adoption indicators and make them a weekly report.

The three commonest mistakes

One: training by module. The employee sits through two hours that do not concern them and misses what does.

Two: super-users in name with no time. The network collapses in its first week.

Three: measuring training by attendance. Success gets declared while half the people cannot do their jobs.

The acceptance test for this station

1. Show the role and task matrix.
2. Name the super-users, the criteria you chose them by, and their allocated time share.
3. Show the competence test results per role.
4. Show the one-page guide for one role.
5. Name the four adoption indicators and how you will read them.

What comes next

The people are ready. The next station is the night itself: cutover and go-live — the rehearsal, the point of no return, and the rollback decision written before it is needed.