Why is there no definition for Root Cause or Root Cause Analysis in ISO 9000 ?

Who knows? We see people doing waaaay too much CA when correction is all that's needed. Maybe because they've given people the option to correct vs corrective action for long enough, they shouldn't HAVE to define it?

 

Is it not one of the ideas behind ISO 9000 to help a new employee get up to speed and become competent as quickly as possible? Not everyone will have done a job before, and that's why we tend to be somewhat detailed in procedures and work instructions and training information.

Similarly, not every organization has pursued a quality management system before. If they had, we wouldn't see the same questions popping up here and over in our former home regarding document control, corrective action processes, and 'form versus record'. While many of us appreciate that ISO 9001 tells us WHAT to do and not HOW to do it, sometimes it is so vague, organizations do not know how to proceed or become confused. Thankfully, in some cases, ISO 9001 makes reference to guidance documents to support us. Is there a definition for root cause or root cause analysis in one of them?

 

If an organization does not have the resources to address every single nonconformance with corrective action, then any action taken will be ineffective...if you try to fix AND solve everything, you'll end up like a hamster on a wheel, going nowhere pretty quickly.

As for who decides when a correction is suitable versus corrective action, that should be up to the organization...presuming some logical, near risk-based thinking, goes into the process. The establishment of triggers can help an organization and its staff quickly decide what level of action is needed and then move on to the suitable next step. To establish triggers, an organization requires metrics and data on these metrics.

For example...

If there are delays in the production line causing backlogs, defect products and poor morale, to focus on every single type of delay may be insurmountable. Instead, classify the delays by type, area, equipment, crew, etc., whatever works for your organization. Look at the length of time for the delays in whichever variable you opted for. Depending on the analysis you could say only delays at Equipment XX will warrant corrective action, all others will be a correction - thus meaning over time the process at Equipment XX may come under control due to solid corrective actions. Or you could any delay greater than XX minutes will warrant corrective action, all others will be a correction - thus meaning over time delays > XX minutes may decrease due to solid corrective actions.

But triggers CANNOT remain stagnant - they need to be reviewed and updated, as processes come under control and/or change.

But triggers CANNOT be chosen at random - use the data to justify why a trigger is a trigger.

Show any auditor (internal or external) a solid process in trigger definition and the actions to be taken be they a correction or corrective action, and you're showing well thought-out process for nonconformances, corrective action, continual improvement, data analysis, resource management etc.

 

Eric - yes it is not only possible, but people do it all of the time. Rework is a form of correction without understanding cause. Screening removing and scrapping defective material from a lot is correction without understanding cause. Replacing a defective product in the Customer's possession is correction without understanding cause. Correcting an incorrectly filled out field in a form is correction...
Tom - why would we want to do this? because we have so many problems that the more minor ones cannot be resourced if we are to address the major ones to root cause and prevent recurrence. this is why the standard allows simple correction. It is a risk decision and we could use this as an example of risk based thinking. (We pareto our problems by severity of effect and work on Corrective Action for the top items...).
I think the question regarding 'who decides' is one of those gray areas of the standard; it should be the company and they should be able to justify their decision, auditors should be allowed to 'second guess' the company unless the miss is obvious and egregious, like not pursuing a Problem that poses a safety risk to Customers or employees...

and yes we can be assured that these corrections are effective if we have an effective retest for the Part or Record after correction.

 

The term "root cause" originated from the need to prevent problems from recurring. I have found that there is actual value in understanding the structure of multiple layers of cause-effect. The standard does have a requirement for "eliminating the causes of nonconformities in order to prevent recurrence." (where appropriate for the effect of the nonconformities) Again in my experience, 'complication' and bureaucracy come from people who don't really understand the cause system and substitute some arbitrary count of number of levels of causes to assess whether or not 'root cause' was identified. The complexity of the causal system is dependent on the causal system and not the size or sophistication of the business...At this point its important to remember that non-conformities include people process sourced problems and physics sourced problems...a solid investigative process is not replaced by a sound risk management process. a sound risk management process will tell us whether or not a nonconformity has a severe enough effect to warrant recurrence. But when the effect is serious, a sound risk management process will insist on a sound investigative process...

A common example of the lack of understanding of 'root cause' (or actually 'causal mechanism' which is becoming more commonly used) and how ineffective it is in preventing recurrence is the "operator error" excuse. it is true that operators make errors and mistakes as immediate causes to many nonconformities. however the two readily available actions one can take against operator are to retrain them and discipline them. These actions rarely work as they don't get to the 'root cause' of why the operator made the error or mistake. When we dig deeper we can find a cause that will allow us to prevent recurrence.