You are right to be concerned. Observing the variation that I do even in document control expectations, this one is going to be hard. Auditors are notoriously difficult to calibrate. I see it all the time.
Informational How the addition of "Risk" will affect ISO 9001:2015
- Thread starter WCHorn
- Start date
When I finish my move to SC I think I will, in time make an auditor training curriculum and offer internal auditor classes. I have been biding my time while I do my CB work.
I got to the end of the line in pursuing a Training Manager job with my CB. It came down to me and him, and they selected the other guy. I was disappointed of course, because naturally I have some ideas of where to reduce the variation. But I will need to be patient I guess. I'm in this for the long game.
I got to the end of the line in pursuing a Training Manager job with my CB. It came down to me and him, and they selected the other guy. I was disappointed of course, because naturally I have some ideas of where to reduce the variation. But I will need to be patient I guess. I'm in this for the long game.
And THAT is the exact reason for my comments. There will be a percentage of organizations AND auditors that will embrace the intent of RBT and do a good job at it.
But, there will be a higher percentage of organizations that will do lip service to RBT and there will be auditors lacking intellectual horsepower to properly assess the explicit and implicit requirements associated with RBT.
The ISO TC 176 SC 2 manages 9000, 9001 and 9004. Anybody who is knowledgeable of ISO 9004 is aware of the fact that standard has some "sophisticated" guidance to QMS development which are not part of 9001, the requirements standard. Obviously, that is done on purpose as 9001 is supposed to be a BASIC, UNIVERSALLY DEPLOYABLE standard. In a business setting, RBT adds complexity, despite the TC attempt to belittle it with the example of "crossing a road". Failure to foresee the potential source of friction in the conformity assessment practices because of the introduction of RBT in 9001 is concerning, in my estimation. And I don't believe the TS9002 will be able to solve the puzzle.
The new 9001 document will require organizations to understand their context and deploy RBT. I think the TC 176 SC2 WG24 failed to realize it's context and do due diligence introducing RBT in 9001. They should have applied for waivers from the HLS and keep risk in 9000 and 9004.
Time will tell, but we are about a year away from the first ISO 9001:2015 certificates being issued, as there will always be the organization who want to boast about being the first certified. Do we have any concrete effort in the conformity assessment industry to develop and deploy a coherent, reduced-variation, value-adding understanding and deployment practices of RBT? The answer is a resounding NO.
While some CB's, Training Providers, registrants, consultants, etc might be developing their material, the issue should have the full attention of the IAF, ISO and a common approach being developed. Otherwise, standardization of understanding and auditing will not be accomplished, defeating the goal of having a standard, to start with.
All true Sidney, and well said. In any case I have run along some appreciable variation on how concepts are applied, even though guidance is available. 9001 is, of course supposed to be applicable to most any type and size organization. That in itself invites variation. We'll continue to see that as has been apparent for many years already, even as it is in environmental and safety systems that really should be easier because of the available regulations to use as origination points. There will be tons of confusion and there will be good, bad and ugly consulting to "help" organizations through the transition. One of them, which shall go unnamed here, I have seen already offering a registration service and information package for 9001:2015 though the standard is still in draft. All of this is why Quality has taken on such a bad name, thought of as ice cream flavors, etc.
Colin
Quite Involved in Discussions
Sidney, I share many of your concerns with regard to RBT but I also wonder whether we may be being overly worried about the subject.
Is not RBT also subject to RBT? - in other words, I think we are applying this in many cases already. When we are auditing an activity don't we ask ourselves the questions such as "what is this item used for" and "what are the consequences if it fails".
I think that the most difficult aspect will be in looking for objective evidence of RBT being applied and, as you mention, what auditors will be satisfied with by way of this evidence.
Is not RBT also subject to RBT? - in other words, I think we are applying this in many cases already. When we are auditing an activity don't we ask ourselves the questions such as "what is this item used for" and "what are the consequences if it fails".
I think that the most difficult aspect will be in looking for objective evidence of RBT being applied and, as you mention, what auditors will be satisfied with by way of this evidence.
P
pldey42
Having availed myself of a copy of ISO/DIS 9001 I now understand what it calls a risk-based approach. Sorry, Sidney, you're right.
In Appendix A.4 it says, "Although risks and opportunities have to be determined and addressed, there is no requirement for formal risk management or a documented risk management process."
That's different from ISO 27001 where, to John's point, the results of risk assessment are indeed auditable because the mitigations selected in risk management have to be listed in the "Statement of Applicability" (SoA); also a formal risk assessment process is specified with what some would describe as prescriptive requirements - which make the risk assessment process itself auditable.
To Sidney's point, yes, if the final version continues to eschew formal risk management, TC 176 would be well advised to consider urgently writing something like ISO 27007 "Guidelines for information security management systems auditing." Mind, even that is fraught with difficulty: ISO 27007 says, amongst other things, that the auditor should look for risks that are under-stated, but does not indicate how that should be done; it relies upon the auditor's detailed grasp of the organization's context, risk management policy, criteria and the mitigations for risk that are in place.
Without such guidance there is a clear risk that auditors will impose their own risk appetites and favourite mitigations upon clients - especially perhaps if they, alongside their clients, are at risk of litigation.
Pat
In Appendix A.4 it says, "Although risks and opportunities have to be determined and addressed, there is no requirement for formal risk management or a documented risk management process."
That's different from ISO 27001 where, to John's point, the results of risk assessment are indeed auditable because the mitigations selected in risk management have to be listed in the "Statement of Applicability" (SoA); also a formal risk assessment process is specified with what some would describe as prescriptive requirements - which make the risk assessment process itself auditable.
To Sidney's point, yes, if the final version continues to eschew formal risk management, TC 176 would be well advised to consider urgently writing something like ISO 27007 "Guidelines for information security management systems auditing." Mind, even that is fraught with difficulty: ISO 27007 says, amongst other things, that the auditor should look for risks that are under-stated, but does not indicate how that should be done; it relies upon the auditor's detailed grasp of the organization's context, risk management policy, criteria and the mitigations for risk that are in place.
Without such guidance there is a clear risk that auditors will impose their own risk appetites and favourite mitigations upon clients - especially perhaps if they, alongside their clients, are at risk of litigation.
Pat
Failure to take action to prevent loss of opportunity (see 6.1.1b) sounds a lot like a preventive action nonconformity to me.
P
pldey42
Is that a triple negative?
But yes, it is - an NC ... but since it's an NC it requires a corrective action which involves, er, risk management, or what was preventive action!
My wonderful new copy of the DIS says, in Appendix A4, "One of the key purposes of a quality management system is to act as a preventive tool. Consequently, this International Standard does not have a separate clause or sub-clause titled 'Preventive action?. The concept of preventive action is expressed through a risk-based approach to formulating quality management system requirements."
In other words, my words, they dropped preventive action because too many people misunderstood it (e.g. by only doing it when an NC was detected in a combined CAPA process) and instead called for the risk management that we do, e.g. with FMEA in design and with dual sourcing in supply chain management. Sorry, "risk based approach" or RBT.
Maybe organizations seeking certification should identify the risk that the auditor will not understand their risk-based approach ...
Pat,
Agreed, failure to take preventive action may require corrective action.
Many systems are reactive and auditors see evidence of this. Such as people agreeing a new objective but failing to change the system to be reasonably sure of fulfilling that objective. Such as designers not considering manufacturability, maintainability and usability. Such as managers relying on inspection instead of understanding and controlling the process.
Yes, CAPA has a lot to answer for. It should always have been PACA. But TC176 should've used the word "stop" instead of "prevent" in defining corrective action.
With the DIS 9001 we have to seek evidence of risk based thinking and its outcomes before we can invoke corrective action to improve prevention.
But in the end the users will make it work the best they can. The requirements that do not work will be ignored. And in a future revision TC176 will quietly drop the ignored requirements.
They'll eventually keep only the requirements that should have been based on what is widely accepted as good practice in the first place.
John
Agreed, failure to take preventive action may require corrective action.
Many systems are reactive and auditors see evidence of this. Such as people agreeing a new objective but failing to change the system to be reasonably sure of fulfilling that objective. Such as designers not considering manufacturability, maintainability and usability. Such as managers relying on inspection instead of understanding and controlling the process.
Yes, CAPA has a lot to answer for. It should always have been PACA. But TC176 should've used the word "stop" instead of "prevent" in defining corrective action.
With the DIS 9001 we have to seek evidence of risk based thinking and its outcomes before we can invoke corrective action to improve prevention.
But in the end the users will make it work the best they can. The requirements that do not work will be ignored. And in a future revision TC176 will quietly drop the ignored requirements.
They'll eventually keep only the requirements that should have been based on what is widely accepted as good practice in the first place.
John
T
TShepherd
Morning all,
Whooa... back the wagons up - we may be overthinking this the concept of Risk Management (RM) within the 9001-2015 changes.
As most of us have experienced, the concept of the FMEA (Design / Process / and Assembly has been considered a form of RM), however it has been relatively ineffective due to the lack of resources and in reality morphed into something that most companies due because it is a requirement rather than an effective concept.
In discussions with our Lead Auditor this year concerning the 2015 changes - what they will be looking for is evidence that relates to Key Process Characteristics (KPI's) as determined by you - that relate to your process and are measurable.
EXAMPLE: We have compression Press's that we measure the amount of scrap in relation to the amount of material used and track that number on a daily basis with our trigger being 3% or less is considered exceptable - and currently is at less than 2% which tells us that the press is functioning as designed with no short shots or other significant defects that would indicate that something is out of whack.
I would urge you to discuss this with your auditor for clarity.
Tom
Whooa... back the wagons up - we may be overthinking this the concept of Risk Management (RM) within the 9001-2015 changes.
As most of us have experienced, the concept of the FMEA (Design / Process / and Assembly has been considered a form of RM), however it has been relatively ineffective due to the lack of resources and in reality morphed into something that most companies due because it is a requirement rather than an effective concept.
In discussions with our Lead Auditor this year concerning the 2015 changes - what they will be looking for is evidence that relates to Key Process Characteristics (KPI's) as determined by you - that relate to your process and are measurable.
EXAMPLE: We have compression Press's that we measure the amount of scrap in relation to the amount of material used and track that number on a daily basis with our trigger being 3% or less is considered exceptable - and currently is at less than 2% which tells us that the press is functioning as designed with no short shots or other significant defects that would indicate that something is out of whack.
I would urge you to discuss this with your auditor for clarity.
Tom
Similar threads
