ERP user training and pilot operation: what to plan

An ERP system that has passed its tests is not yet a system the company works in. First people have to learn it, and a first group has to do real work in it. Management often treats this period as a formality, and that mistake is expensive.

Instructions by role

The documentation supplied with an ERP product describes all of its functions and is written for specialists. A user needs the few scenarios of their own job, in the order of the company's process. Such instructions are written during the project, one set for each role, and the time for them belongs in the schedule and the budget.

The screens in an instruction are taken under the access rights of that role. A consultant works with full rights and no longer notices the extra buttons and fields. A user who sees a form that differs from the picture stops and asks for help. So access rights have to be designed, set and tested before training begins, and this work is often missing from the estimate.

Training on the company's own data

Training on a demo database gives less than training on the company's migrated data with the settings of the project. Employees work with their own items, counterparties and documents and learn their own process, not the product in general.

General topics are taught in large groups, the details of each role in small ones, and some people then need individual sessions. When the supplier trains the client's key users and they train their colleagues, the knowledge stays in the company after the project.

Training ends with an examination by role. It is not a formality that everybody passes: the results go to the heads of departments, and the number of repeat attempts is agreed in advance.

What an inconvenient screen costs

If an inconvenient form adds 10 seconds to an operation that a user repeats 100 times an hour, the loss is 1,000 seconds an hour, almost 17 minutes. Over an 8-hour day that is more than 2 hours of one person's working time.

Such forms are found during training, by the consultant who prepares a session and by the users. Each case is recorded as a change request: a developer sees such a change as secondary, while the user loses time on it every day. This is a reason to start training before development ends, as soon as a block can be shown.

A pilot with dates and exit criteria

Pilot operation checks the system on real work: the algorithms, the instructions and the transferred data. Only a part of the employees takes part, so the others do not enter data in two systems.

The group works in the new system in parallel with the old one or uses only the new one. The second option leaves no pause for corrections: defects are fixed in a system that is already in use.

The pilot needs a written regulation with dates and success criteria, for example no critical defects on the last day of the term. When the criteria are met, an act is signed and the phase is closed. Without such a document the pilot drags on: employees busy with their main duties test slowly, and the project team waits.

Rules for the first days

These rules can go into the pilot regulation as they are.

• A manager does not accept a report prepared outside the new system, in a spreadsheet or on paper.
• In the first days a specialist, external or in-house, sits next to the users and examines each difficulty at the workplace.
• The client's key users give first-line support, and the supplier supports them.
• Every change request goes into one list and gets a prompt decision.
• An employee who avoids training or the system is a matter for the client's managers, not for the programmers.