ERP training, and how to train the trainer

However it is done, practical training is never cheap but, by using this method, costs can be minimized at the same time that effectiveness is being maximized. Typically, two types of people require training: the implementation team and the end-users.

When one of the large system integrators (SIs) such as Deloitte, Accenture, Capgemini, etc has been contracted to help with the project, companies should be able to assume that the SI's consultants are both trained and experienced (although that is not always the case).

But regardless of the size of the system being implemented and whether or not an SI is being used, companies always need their implementation team to be fully trained in all aspects of the software. Some believe that, when using SIs, it is only necessary to have end-user training but experience tells us that it is essential for companies to have an internal implementation team that has undergone sufficient education and training.

Without that, they can't possibly monitor or evaluate challenges or perhaps even understand the decisions that are being taken by SIs and external consultants on their behalf. Companies that don't think this is necessary are advised to consider the recent Lidl debacle, where the retailer spent over half a billion dollars on a new system before realizing that it wasn't going to work for them.

With Tier 2 and Tier3 systems, SIs are frequently not used because of their cost, and then the implementation team is more usually made up of a mix of the supplier's consultants, the customer's internal project team, and, hopefully, an independent consultant to help identify what the system should be doing and how best to achieve that.

When system design and configuration is complete and thorough system testing (i.e. testing of both software and procedures) has been performed, end-user training can commence. This training can be carried out by the vendor's or SI's consultants and, in fact, sometimes this is the only option when, for example, internal resources are limited.

But companies have good reasons to consider a train-the-trainer approach at least and one reason is that compiling and presenting a training course is a good way to become an expert in the subject matter. It encourages people to look below the surface of the system because nobody likes being caught out when users ask unexpected questions (and if the users don't get good answers to those questions, it's harder for them to accept what they are told).

A second reason is that a company's staff are best placed to explain things to people using their language, including company jargon and industry terms that might not be known to external consultants. That is not only a more efficient use of time but it also reduces the risk of misunderstandings and accidental misinformation.

Additionally; if end-users get the impression that consultants don't clearly understand how they and the overall company work, it is very difficult for them to have confidence in the system that those consultants are presenting. Thirdly; a company's people will know the strengths and weaknesses of the individuals they are training.

They will know who needs extra time and encouragement and who can be left to work through things at their own pace, working things out as they go. Fourthly; being trained by their colleagues gives users confidence in those colleagues, and that makes it easier for them to ask for extra information, advice and clarification later (when external consultants have long since packed up and gone, taking their knowledge with them).

Lastly; a company's people are cheaper than external consultants. In many ERP projects, when costs start to rise and budgets start to be stretched, many companies look to cut costs, and training is unfortunately frequently seen by them as something that can be cut back on.

They will ask themselves if users really need all of the training time that has been scheduled for them, whether they need so many practice sessions with trainers in attendance, and they will then try to justify their decisions with claims that, “you only really start to learn a system when you begin using it in earnest”.

Using internal resources for training reduces the temptation to scrimp on it. Clearly, there are good reasons for adopting a train-the-trainer approach, but one important proviso is that not everybody has the qualities to be a good trainer.

Subject matter knowledge is not enough because to be effective trainers, people need a range of skills that perhaps they don't need in their regular jobs and, although they can be sent on courses to help develop these skills, it is undeniable that some of your best people will not be your best trainers.

It may be that some will lack patience and empathy, whilst others will be so keen to pass on their knowledge that their training sessions will be carried out at a speed that few can keep up with. There are, in fact, many reasons why some people just don't make good educators, so not infrequently the people who lead the implementation don't lead the training.

Nevertheless, developing training skills in-house bodes well for the future, when users need to be retrained to cope with new releases of the software and changing business requirements.