1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice
You must be a registered member in order to post messages and view/download attached files in this forum.
Click here to register.

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

Discussion in 'ISO 9001:2008 - Quality Management Systems' started by Ajit Basrur, Aug 31, 2015.

  1. Ajit Basrur

    Ajit Basrur New Member

    Joined:
    Jul 30, 2015
    Messages:
    3
    Likes Received:
    6
    Trophy Points:
    2
    I was wondering why did the terms "Root Cause" or "Root Cause Analysis" did not find a place in ISO 9000 - Quality management systems -- Fundamentals and vocabulary ?

    Any thoughts ?
     
  2. Andy Nichols

    Andy Nichols Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    5,086
    Likes Received:
    2,553
    Trophy Points:
    112
    Location:
    In the "Rust Belt"
    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?
     
  3. RoxaneB

    RoxaneB Moderator Staff Member

    Joined:
    Jul 31, 2015
    Messages:
    926
    Likes Received:
    1,081
    Trophy Points:
    92
    Location:
    Ontario, Canada
    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?
     
  4. PaulJSmith

    PaulJSmith Well-Known Member

    Joined:
    Jul 30, 2015
    Messages:
    107
    Likes Received:
    113
    Trophy Points:
    42
    Location:
    Midwestern USA (STL area)
    It's been my experience that every organization does indeed have a Quality Management System; they just not always very well organized and/or documented. Most successful companies do most of the things outlined in ISO 9001 to some degree. They just don't think about it as a "system."

    I agree with Andy about people overusing CA. We recently had to deal with an engineer at our place who thought that every non-conformance should naturally progress through the formal CA process. A ridiculous notion. Fortunately, he moved on about a week ago, as I was growing weary of constantly arguing the point with him.

    A formal definition would most certainly be helpful in such instances.
     
  5. Tom Waite

    Tom Waite Member

    Joined:
    Aug 3, 2015
    Messages:
    45
    Likes Received:
    33
    Trophy Points:
    17
    Location:
    Grand Rapids Michigan Area
    I totally agree there is a difference in correction and corrective action. Not all issues need corrective actions (certainly not formal). But here is the big question on this....who decides?

    I have seen companies that decide this, and then get audited and the auditor tries to decide what should have been or what should not have been corrective actions - and it differs from auditor to auditor. So who gets to decide, "the nature and extent of the impact" and how it relates to the business as a method to determine if actions are needed or just corrections are acceptable?

    In addition, since this was started about root cause, when would correction be acceptable without knowing the root cause? While this is different than taking things through a full blown CA process why would you not want to know RC and ensure your corrections fix it? Thus understanding the definition of RC could come in handy so companies don't just fight the fire and never address the cause of the fire.

    This would tie directly into Risk mitigation and understanding what risks are going to be accepted, so I see that there is an avenue for corrections through accepting the root cause as risk, but without that when would it be acceptable as a good business practice to not know what caused the need for corrections in the first place?
     
  6. Eric Twiname

    Eric Twiname Well-Known Member

    Joined:
    Jul 31, 2015
    Messages:
    329
    Likes Received:
    232
    Trophy Points:
    42
    Location:
    Northeast USA
    Great question. I'll go you one better...Is effective correction possible without knowing the root cause?

    I'm sure it can be effective to simply bypass the problem area in some cases...but as a fairly safe generalization, you can't fix it unless you know where its broke.

    To the concept of why "Root cause" didn't make it into the standard...it makes sense to me that it did not. How I understand the problem need not be legislated...that I find it and fix it makes a lot more sense to include in the standard.

    "Do it" is in the standard.
    "Do it this way" is not.
    That makes total sense to me.
     
  7. RoxaneB

    RoxaneB Moderator Staff Member

    Joined:
    Jul 31, 2015
    Messages:
    926
    Likes Received:
    1,081
    Trophy Points:
    92
    Location:
    Ontario, Canada
    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.
     
  8. Bev D

    Bev D Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    605
    Likes Received:
    663
    Trophy Points:
    92
    Location:
    Maine
    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.
     
  9. Sidney Vianna

    Sidney Vianna Well-Known Member

    Joined:
    Jul 30, 2015
    Messages:
    127
    Likes Received:
    172
    Trophy Points:
    42
    Probably because the terms "root cause" and "root cause analysis" are not used anywhere in the standards which comprise the documents maintained by the SC2 of TC 176. Why would they define something which is not used in the standards they are responsible for?

    Having said that, if one peruses the ISO Online Browsing Platform, the terms are used in many places; for example in ISO 13372:2012 - Condition monitoring and diagnostics of machines — Vocabulary, they define

    8.9 root cause
    set of conditions or actions that occur at the beginning of a sequence of events that result in the initiation of a failure mode (4.6)

    8.10 root cause failure analysis - RCFA
    after a failure (1.7), the logical systematic examination of an item, its construction, application and documentation in order to identify thefailure mode (4.6) and determine the failure mechanism and its basic cause
    Note 1 to entry: Root cause failure analysis is often used to provide a solution to chronic problems.
     
  10. Brian Vandolah

    Brian Vandolah Member

    Joined:
    Aug 5, 2015
    Messages:
    19
    Likes Received:
    15
    Trophy Points:
    2
    Location:
    Ft. Worth, TX
    Why do the phrases "root cause" and "root cause analysis" not quite fit into the ISO 9001 standard? Most likely because simply identifying "causes" allows any organization (ranging from a mom-and-pop shop to a large corporation) to develop the controls that best suit them, which IMO promotes the not-being-prescriptive aspect of the standard.

    To me, if a particular organization wishes to complicate their corrective action process by requiring multiple levels of root cause analysis to resolve its issues, that should be OK as long as the controls are effective and the process works as advertised. On the other hand, if correction is all that is needed to fix simple issues because a company only expects simple issues to happen, then that should be OK as well - again, as long as efficacy and bureaucracy are not trampled upon. Either way it all goes back to proper risk management, which (I hear) is where the new edition of ISO 9001 is expected to direct us towards.

    To tell you the truth, I'm not even sure where terms like "root cause" and "root cause analysis" originated from, but it's interesting to note that because these terms are so ingrained into (and permeated throughout) our general quality culture it's easy to forget that we are really just trying to identify and eliminate "causes", and while I know that not all causes are equal in nature, for the most part they can be dealt with systematically through sound risk management. I'm glad that the standards recognize this, and that we still have some semblance of flexibility when it comes to designing our CA processes.
     
    tony s, PaulJSmith and Pancho like this.
  11. Bev D

    Bev D Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    605
    Likes Received:
    663
    Trophy Points:
    92
    Location:
    Maine
    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.