by Dean Prigelmeier, President of Proactive Technologies, Inc.
Technical process documents standardize work processes in an attempt to maintain task performance at a consistent level of output. From organization to organization, process documents may vary in usefulness though required by ISO/AS/IATF certification. Some may be too vague, too specific or too cluttered into lengthy paragraphs designed for human error. Nevertheless, the intended purpose is to offer guidance as to the “best practice” way of performing work. Whether illustrating technical documents is useful in achieving that goal is dependent on a few factors.
Technical processes, illustrated or not, are most useful to a worker when learning a task for the first time. Unless in a checklist format where step-by-step initials are required to document that no steps are missed, most process documents are reduced to a “reference status” Even though management and auditors want to believe process documents are followed intently each time, that is usually a “staged” behavior. In reality, once committed to a worker’s memory many documents are not seen by the user until the audit is scheduled. Unfortunate but true.
Sometimes more diligent workers make up for document inadequacy or lack of process documents by keeping notes in their lunchbox or, more precariously yet, in their head. Heaven forbid this is discovered during an audit. These notes not only are uncontrolled and unofficial, but they represent a wealth of “tribal knowledge” that is not routinely shared with new-hires. Mistakes that are known to have happened, and can be avoided if shared, are repeated with each trainee to everyone’s detriment. The fact that each employee feels the need to keep their own notes is a sign of some problem with process documentation and should investigated.
Stepping back to get a better view of learning patterns of a typical worker may be helpful. It varies from organization to organization, job classification to job classification. If an organization has been trying to hire based predominantly on wage level, they often find the lower the wage level the lower the inventory of prerequisite skills for not only the tasks to be learned, but also the ability to learn. And most organizations that focus on lower wage levels do not have a budget for remediation of deficient core skills to improve the process of learning.
It is here that organizations sometimes try to make up for the deficit by expending time and money to illustrate the technical materials, thinking “pictures speak a thousand words.” Adding illustrations alone to flawed technical processes will not magically bring the document together to a make a better learning material. Here are a few examples of what I am talking about:
Example 1: Too much superfluous information, not enough specific information
- Load part on table. The part should be oriented so that the fat end is to the top and skinny end is to the bottom. Next, install the holding screws in the required locations. Tighten down the screws so the part only wobbles a little bit. Holddowns are important and were invented many centuries ago. Next, measure the width, height and thickness and determine the necessary amount of paint to provide a thorough cover. We have had experiences where too little paint was used and bare areas were rejected in quality. So, make sure you cover it thoroughly.
- Bake the part in the furnace at the appropriate temperature and required time to consistently cure the coat. Allow to air cool for the appropriate amount of time before handling. Visually inspect part and move to next operation.
- The company has been in the business for many years. Sometimes defective parts slip out the door. So, watch for defects.
Although appearing to be full of information for the user, it represents an exaggerated case of ambiguity that presents many opportunities for an incorrect interpretation, missed steps and operator error. I have seen many documents that the engineer who wrote it without a doubt understands but the employee who is to follow it exactly clearly does not. A document written clearly to the average reading level of the user, in a “step-by-step” format, including specifications and checkpoints, would eliminate the ambiguity.
Another extreme example of an ambiguous process document design is:
Example 2: Too ambiguous from lack of specific information
- Load part
- Process part
- Inspect part
This is another example of a process description that I have frequently come across; ambiguous for lack of information. Example 1 is written in a way for someone to miss a step when trying to follow the many steps contained in each step full of non-specific information. The discrete required actions at each step are unclear. The steps in Example 2 are also opened to the interpretation of the reader for lack of information. Neither example standardizes anything except ambiguity. Example 2 is so vague anything could result from it based on each worker’s interpretation. In both cases, adding illustrations is like a placebo that may give the false impression of clarity to the author but not so much to the reader. Clarifying and testing the document before deciding to illustrate is always a useful step. After all, if the worker is learning to perform the task in front of the product and equipment a 3D, tactile experience can be significantly more effective than a 2D, visual experience.
A more effective approach to process standardization for repeatable performance is to list the steps discretely and succinctly – providing only enough information at each step to accurately perform the step. Leave the opinions and historical information to the end of the process so what is expected is clear.
Example 3: A better example of defined process steps
- Install part in fixture T-2222B with notched end away from you and part flange facing up.
- Install T-12345 holding screws in holes 3, 6 and 8.
- Tighten holding screws with torque wrench to 15 lbs each.
- In this order: screw 3, screw 8, screw 6. Repeat until 15 lbs per each screw reached.
- Place T-3344 protective covers on screw heads.
- Apply flux at the outer weld points as directed in process sketch.
Once documents are clearly and thoroughly written so the process steps achieve a repeatable outcome, and knowing there is nothing better than the actual part or machine in lieu of illustrations, the choice of which processes to illustrate may become clearer and used on a limited basis.
Some practical reasons to illustrate process steps are:
- Visualization of the output of the task is helpful to making sure the previous steps led to the right outcome;
- Seeing examples of process-produced defects is helpful to rejecting discrepant parts;
- Process complexity requires visualization of each step in order to comply;
- Opportunities for observing a subject matter expert perform the process prior to execution are rare, therefore process performance is often “self-taught;”
- The process has stabilized and the possibility of changes and revisions is small plus any combination of 1-4.
Although there are legitimate applications for illustrated procedures, the notion that labor-intensive process illustration is vital to the procedure learning process is inaccurate. Its application could be used strategically for appropriate reasons – not in a futile effort to salvage the limitations of an existing document – lest it loses its credibility as a learning medium. If a document is clarified, verified and standardized, and mistakes and errors that occur in its utilization minimized, but still process repeatability is illusive, illustration might be the last consideration.