ERP
ERP Training That Survives Go-Live Week
Classroom training three weeks before go-live has largely evaporated by the time it's needed. What holds is practice on real tasks with real data.
The standard training plan is a set of classroom sessions, module by module, in the weeks before go-live. It is easy to schedule and easy to report against, and it produces very little retained capability — because it teaches the system rather than the job, and it happens far enough ahead that most of it is gone by the time anyone needs it.
Teach tasks, not modules
Nobody's job is 'inventory management'. Their job is receiving a delivery against a purchase order, resolving a short delivery, and moving stock between locations. Build the curriculum from the list of tasks each role performs, ordered by frequency, and stop when the list is covered.
• Write out each role's actual task list with the people doing the job today.
• Order by how often the task occurs, not by how the software is organised.
• Train the top handful to fluency; document the rest as reference.
• Include the exception paths — that is where new systems actually hurt.
Practise on migrated data
Training on vendor demo data teaches the happy path with clean records. Practising in a sandbox loaded from your own migration rehearsal teaches the real thing, including the awkward records and the local naming conventions. It also puts a second set of eyes on migration quality, which is a free benefit.
The first time someone sees their own data in the new system should not be on the Monday it goes live.
Train late, then train again
Move the bulk of hands-on training as close to go-live as the schedule allows, and plan a second short session in the first fortnight after. The post-go-live session is the highest-value hour in the whole programme, because people arrive with specific questions from real work rather than hypotheticals.
Grow super-users from the floor
Every team has someone colleagues already ask for help. Identify those people, train them deeper and earlier, and give them explicit time to support others. Support that comes from a trusted peer at the next desk is used; support that requires a ticket is worked around.
Assess by doing
A completion certificate proves attendance. Ask each person to perform three of their real tasks unaided in the sandbox instead, and record who could. That list is your actual readiness assessment, and it is usually different from the attendance report in ways that matter — a whole shift or a whole site can turn out to be unready while showing 100% trained.
Deciding what to do about that is a management call. Knowing it before go-live rather than during is the point.
Role-based task lists instead of module tours was the change that worked for us. A warehouse operative needs six tasks, perfectly, not a tour of inventory management.
Super-users chosen by the team rather than appointed by the project made a visible difference. People ask the colleague they already trust, not the person with the title.