In the beginning of my training arena entry, I came across a definition of training that I still use today. Training is the sharing of knowledge and skills to others in an organized and planned manner that involves both learning and doing. A trainer’s job therefore, is to close the training gap between what the learner knows BEFORE and what the learner can do AFTER as effectively as possible.
This implies that a series of actions can be repeated each time regardless of the content. Some folks refer to it as a process. But here’s where it gets confusing. We mix in the word system and then interchange system, process and even program when we describe training. So does a program mean a system or a course or a particular subject matter curriculum?
To make matters worse, there could be more than one process to accomplish “training”. For example, designing content is separate from uploading attendance into a database or how to qualify SMEs as a Trainer. In these organizations, “the training program” consists of mini-processes that are often fragmented and decentralized thus managed by multiple owners that frequently lead to conflicting work practices for training. The result is a broken training system that creates frustration for its end users and becomes a barrier for partnering with line management. We tend to see only our part and don’t fully appreciate the impact our decisions have on the other processes. So, it’s hard to think of training as a system.
It’s best to step back from the ownership perspective and think holistically about training from start to finish. Then chunk up segments like preparation, delivery and measuring effectiveness. Within these blocks, consider the inputs, process steps, outputs and the achievable outcome(s). It is perfectly acceptable to generate separate work instructions for these processes just as long as they are integrated back into the big start-to–finish picture with a logical process flow. Also known as SIPOC (suppliers, inputs, process, outputs, customers) process map. While variations of these formats exist, the main content includes inputs, value-added process steps, and the outputs.
I also find it helpful for training system owners to have a high-level policy type document to describe the overall process flow and orient end users on where the processes are used in order to ensure the sequence is kept in order. The more procedures there are, the more critical these linkages become. But rather than having one all-purpose document that can total to more pages than desirable, SME teams collaborate on what makes sense for the organization.
When all the training pieces and parts are contained within the systems view, responsibilities for each process (or procedure) are still assigned regardless of the departmental reporting structure. The systems view promotes a shared ownership of the entire system, not just the individual processes. Thus ensuring a more consistent training experience from trainer to trainer as well as ensuring classroom sessions are designed and effectively delivered.
How do you organize Man (People), Machine (Tools), Methods (Procedures), Materials, and Metrics into one logical process flow for training? Become a Theory vs. Practice Blog subscriber first. And then request the process flow diagram.