Quality System Processes without Documented Procedures

[Bev D]

Some documentation is prudent of course and I’ve listed them in previous posts. Checklists, BOMs, drawings with specifications and QC requirements, equipment manuals, automated processes in software (statistical software, ERP software, automation software), facilities layouts, schematics, diagrams, and standard work sheets (single piece of paper or computer screen) which specify timing sequence outputs etc. for operations that are longer than a minute. But these are not what most people think of as procedures.

I would challenge everyone to think about your chef/recipe analogy again. A single chef or individual cooks is not what a manufacturing facility is like. The food preparation analogy that fits is a restaraunt kitchen. They prepare the same things over and over in relatively high volume in a form of assembly line. They are trained and coached and supervised in techniques and methods and repeat the same steps over and over. They don't Read procedures or recipes. (Have you ever watched “worst cooks in America”?) At some point the head chef (or diner owner) creates the recipe and their is a checklist of ingredients and they know roughly how many people they will serve and how many of each dish each day, so they can purchase their supplies. The ingredients are staged at the prep and cook areas. The way orders are presented is very similar to a TPS manufacturer. I love watching a well oiled kitchen - I always learn something new about running a lean organization. Buca di Beppo has a special table in the kitchen - so much fun. I also love watching them make the donuts at Krispy Kreme an industrial engineering dream. The Toyota fork lift factory in Columbus Indiana is also very instructional to watch. No “procedures” there.

A long time ago, I bought into that big procedure thing. But I was continually frustrated by operators and engineers and others “not following the process”. No matter how much I wrote it didn’t get better. No matter how many findings I issued it didn’t get better. The more I pushed to documentation the more the organization moved away from it. I knew there had to be a better way. It took awhile, but I found it.

RANT AHEAD: As for my lazy and ignorant comment I stand by it. I know it’s rough but the quality profession has sunk into rote replication of crap processes and somehow we need to wake people up. Lazy isn’t a physical thing it’s a mental thing. It is hard to think about new or different ways - we must study, think for ourselves, try new things - or things from 70 years ago, search out the truth in the midst of the pablum that passes for ‘collective wisdom’. Ignorance means lack of knowledge. It’s curable. You don’t have to be ignorant. But study is hard. It’s easy to just accept the ‘quality practices’ (ISO, AIAG, FDA, USDA, you name it) and statistical alchemy that so many people push on us. We know it doesn’t work, we rail against it, then we defend it to our death because we think we have no choice. We are victims of the Stockholm syndrome. It’s just crap. It’s a waste and by defending it we are killing the quality profession. Think about it: how many hack auditors have you had that can’t accept anything that isn’t exactly what they are used to? They aren’ physically lazy, they are mentally lazy. How many times have we discussed on this very forum the abomination of operator error - “retraining” - discipline? That response is mentally lazy and ignorant of human behavior. We discuss Normal centric SPC, process capability indices, AIAG gauge R&R, fishbone diagrams and on and on. Deming himself warned us about hack statisticians and quality consultants yet so many people continue to flock to them because there are way more of them than of us. Because its easy to repeat the rhetoric and its easy to accept it. It doesn’t require thought. Just fill out an electronic form and an answer pops out. This forum is one of the last refuges of those who really care about quality. I don’t want to scare away those who are here to truly learn, and we can’t perpetuate the mediocre and wrong methods and thought processes.

 

[AndyN]

Amen!

 

[Mark Meer]

...A long time ago, I bought into that big procedure thing. But I was continually frustrated by operators and engineers and others “not following the process”. No matter how much I wrote it didn’t get better. No matter how many findings I issued it didn’t get better. The more I pushed to documentation the more the organization moved away from it. I knew there had to be a better way. It took awhile, but I found it. ...

Much appreciate your perspective Bev!
You're certainly nudging my thinking, and I hope others' too! Great discussion!

...and in that spirit, I hope you don't mind if I continue to probe...

1. Regarding recipe analogy: I realize that this isn't the way a kitchen would work, but all I was pointing out is that documented procedures do have value in specific contexts, and to the extent that an operation may have/experience a similar context, it makes sense to use them.
Here is an example recently experienced here:
- We receive PCBs maybe 6 months to a year intervals.
- The receiving inspections were created by an engineer who documented the steps (in simple, easy-to-follow way - like a simple recipe), and trained a technician to do them (not much training to do - we just observed that he could correctly follow....sort of like usability testing for the instructions).
- Because of the 6 month to a year interval between executions, the technician still finds it valuable to reference the instructions - as he can not rely on memory of all the stuff he did months ago. This is valuable.
- (additionally) This week, our PCB delivery coincides with our technician being on vacation, and engineer being sick. With the instructions, anyone* can receive simply by following the instructions, and so there are no delays in receiving.

*two caveats: (1) by "anyone" I mean those we've deemed competent/qualified to follow the instructions. (2) that "someone" is available.

2. Regarding checklists: In my view there is a blurry line between checklist and procedure. If a procedure is sufficiently succinct, it is akin to a checklist. Many of our testing protocols are documented in this way: a table with test and acceptance criteria to be completed on the left, and a checkbox on the right. This ensures that all tests ("steps") in the "procedure" are carried out.

3. Regarding need for documented procedures: are there any processes where you think that documenting procedures has value? Document control, or change control perhaps?

 

[John Predmore]

I think a documented procedure, like a recipe, is a form of process control. Whether a written procedure is required is a decision should be made in the proper context on the basis of risk and cost/benefit, and not blithely made into a dogma requirement. If we use the example of a recipe, sometimes you want to control the list of ingredients to guard against substitutions that diminish consistency of the output result. Sometimes substitutions don't matter. Perhaps a checklist is needed to guard against omissions that may ruin the result. Sometimes your recipe controls the precise amount of ingredients because the ratio of ingredients is crucial to the outcome. Sometimes it is the sequence of ingredients or process steps that is most important. But a recipe is only one possible form of control.

Process control can also achieved through other means, perhaps more effectively. Training could be one form of control reducing the need to strictly follow a written procedure (although the written procedure per se could be valuable for training and for auditing). Certification of competency is another form of control. Anyone bake a cake, but to prepare food for paying customers requires ServeSafe certification on safe food handling. Error-proofing is another form of control, I can't run the microwave oven with the door open, for example. Limiting access is another form of control, that is why my grandkids aren't allowed to operate the stove. The software or hardware interface might be another means of control, so there is a lockout feature on my dishwasher. Every time I think of a case where a procedure is necessary I can think of a counter example where control is achieved through other means and a written procedure is overkill.

 

[Mark Meer]

I think a documented procedure, like a recipe, is a form of process control. Whether a written procedure is required is a decision should be made in the proper context on the basis of risk and cost/benefit...
...
Every time I think of a case where a procedure is necessary I can think of a counter example where control is achieved through other means and a written procedure is overkill.

I think we're all on the same page with respect to different strategies for process control.

However, I think the meat of discussion is as to whether or not documented procedures are ever warranted over-and-above the other methods.
Judging by your last statement, I'm guessing you are leaning towards the "there is always a better way than procedures" camp?

Perhaps there are contexts where cost/benefit indicates a documented procedure is valuable (such as examples I've given in this thread). ...but then it might be argued that such contexts are fundamentally setup inefficiently so as to necessitate documented procedures. i.e. if you are depending on procedures it might be possible to restructure to eliminate need for procedures...but this, in itself, is a cost/benefit decision, and I'm dubious as to whether it is always a possibility.

 

[mattador78]

Recently we have had a large expansion of staff and a turnover of experienced staff either into senior Management roles or have moved on, This has created a void in competency levels here so we have had to produce probably 50% more written procedures than we had before, all of our processes used to be manual operations which gave the senior staff hands on control and raised competency through the roof. The hands off approach of automation has taken the control of certain aspects from the staff and with the staff loss we are having to use the written procedures to help understand the control of certain aspects of our processes. What we have learned from this however is that we are installing a manual process line on a smaller scale to give the new staff a hands on experience so that moving to the automation will be a progression and they will understand all the control elements lowing the amount of written procedures required. I can attest to what Eredhel is saying about the right people in the right positions, our processes have always required a huge element of multitasking as very few people here are doing the same jobs inside their process all day everyday. I have over 20 years experience on our production floor and I can do all the operations with no written instructions and process 90% of the work with no job or route cards and ensure it goes back to the right customer with the right finish. I cant trust that the majority of my workforce could get close to that, hence the reason we are reinstalling a manual process which then increases our training which raises our competency which reduces our requirements for documentation (in theory)

 

[John Predmore]

whether or not documented procedures are ever warranted over-and-above the other methods.

To paraphrase the old African proverb: If you want to go fast, go it alone. If you want to go consistently the same way every time, use a documented procedure.

 

[Mark Meer]

... If you want to go consistently the same way every time, use a documented procedure.

I think this is central to the discussion. The point being made is that documented procedures don't (necessarily) ensure consistency - or at least they are not effective towards this end.

A parallel could be drawn to the changing view of the medical device risk-management standard. The base standard initially cited "information for safety" provided to users (e.g. warnings in instructions/labelling), as a way to mitigate risk. Much in the way a documented procedure may be intended to control process, providing documented information to users was intended to control risk. Despite these intentions, however, it was soon apparent that in actual use, few people actually read instructions, so it was questionable how effective (if at all) this approach was to actually mitigating risk.

But again, context matters. To continue with this analogy, to the extent that you could rely on your user-base to read instructions (maybe they are of a particular OCD disposition ), perhaps the information is valuable/effective.

 

[Sidney Vianna]

Recently we have had a large expansion of staff and a turnover of experienced staff either into senior Management roles or have moved on, This has created a void in competency levels here so we have had to produce probably 50% more written procedures than we had before, all of our processes used to be manual operations which gave the senior staff hands on control and raised competency through the roof. The hands off approach of automation has taken the control of certain aspects from the staff and with the staff loss we are having to use the written procedures to help understand the control of certain aspects of our processes. What we have learned from this however is that we are installing a manual process line on a smaller scale to give the new staff a hands on experience so that moving to the automation will be a progression and they will understand all the control elements lowing the amount of written procedures required. I can attest to what Eredhel is saying about the right people in the right positions, our processes have always required a huge element of multitasking as very few people here are doing the same jobs inside their process all day everyday. I have over 20 years experience on our production floor and I can do all the operations with no written instructions and process 90% of the work with no job or route cards and ensure it goes back to the right customer with the right finish. I cant trust that the majority of my workforce could get close to that, hence the reason we are reinstalling a manual process which then increases our training which raises our competency which reduces our requirements for documentation (in theory)

I think you just described the challenge of managing knowledge in your organization, so as I said before, documentation is a dynamic component of knowledge management.

 

[Marcelo]

A parallel could be drawn to the changing view of the medical device risk-management standard. The base standard initially cited "information for safety" provided to users (e.g. warnings in instructions/labelling), as a way to mitigate risk. Much in the way a documented procedure may be intended to control process, providing documented information to users was intended to control risk. Despite these intentions, however, it was soon apparent that in actual use, few people actually read instructions, so it was questionable how effective (if at all) this approach was to actually mitigating risk.

I think you are confusing things. Information for safety is still a risk control measure, and an accepted one by engineering practice. It can always mitigate risk if validated (thru and usability engineering process.

The crazy EU deviation was created by someone with no engineering background. This has been corrected in the MDR.

Also, what really control the risk is the action (or inaction) of the user to prevent the problem, not the instruction itself.