I have trained people in business software in quite a few different environments – in classrooms, over the Internet, and one-on-one. In all these circumstances there is a need for consistency, thoroughness and, above all, applicability. To achieve this, there needs to be a systematic approach.
When the subject of the training is an in-house application or process, the trainer needs to use and abuse the system to encounter all the possible errors and entries the users might input. The trainer can only recognize the possibilities and prepare the users for them. The next step would be to design the series of steps the users would use to learn all the phases of the process. This should include improper input so that the users can get accustomed to the error messages and how to correct the situation. Next, write a teacher’s manual and student manuals. The student manuals should contain screen prints of what they would expect to see, as well as the steps to be done; and they should have plenty of white space for note taking. The best venue for this type of training is a computer lab or classroom, using a test system, so users can try different things without harming live data.
This type of training should be offered to employees yearly. Those who have had the training may want to brush up, and new employees should be required to attend.
When the application or process is changed, fresh training should be designed and offered, with fresh user manuals that stress the new aspects, but cover the material thoroughly as well, as is done in regression testing. This allows the trainer to show the new aspects, but it also creates a manual for new hires. The trainer’s manual would incorporate the changes.
If the application to be taught to business employees is over-the-counter, the approach is a little different. The developer of the training should meet with the hosting company and find out how the application is being used by the employees to be trained. For instance, if the application is Microsoft Excel, are the employees using it as a database, accounting ledgers, number crunching or analysis? And the host company should inform the developer of what version is being used.
Over-the-counter applications afford the training developer an opportunity to pre-design courses into modules. This way the developer can mix and match according to the needs of the business. For example, if the application is Excel, There would be an introductory module which explains the nature and terminology of the application. A separate module might be on the properties of cells in regard to protection and formula reference. A third module would be on the many functions in Excel and when and how to use them. A fourth might be on macros and the programming language to write them.
By discussing the needs with the host company, the training developer can customize the training using the pre-tested modules, and applying the practices specifically to the company’s users. This not only makes bosses happy, but employees develop enthusiasm when they see how it applies to their own work.
Trainer and student manuals are still needed in the same format as mentioned above.
The developer should check in with the host once or twice a year to see if other employees need the same training or if there is another aspect that the employees could learn. In any training such as this, it is a good idea to have all students fill out an open-end questionnaire to gauge how well the training went, and to get input about good ideas for change. This questionnaire should be unsigned; it is for the edification of the trainer and developer, not for evaluation of the students.
If the training is successful and well-retained, the developer will be asked to return. If, on the return, previous students are in the classroom, they appreciate consistency of presentation. And if this is a return visit, students are especially attentive when they notice their suggestions were followed.
The developer needs to save training modules for a wide variety of versions for the same application, because different businesses use different versions. Once the basic format for training has been determined, it is simply applied to the new version or even a new application. This helps prevent errors.
Many companies, on the wrap-up of a project, have a “lessons learned” meeting where they evaluate the problems encountered. These problems can be runaway expenses, poor cooperation from a sector of the project, incorrect choice of products, poor communication, whatever. Then steps are taken to avoid the same problems the next time. This should also be done with business training. Immediately after a training session ends, read the evaluations, take note of any notations in the trainer manual, then make the changes in the manuals and test them, while things are fresh in your mind, and you won’t forget to cover or correct anything.
When you have a systematic approach to developing business training, no matter what the subject matter, things go more smoothly. New assignments do not seem so daunting, and attention can be focused on the learning environment.