Risk Identification and Risk Assessment for any Process - Is it necessary?

[Jen Kirley]

So, My question is that, is it a requirement of ISO 9001 to do risk assessment on QMS processes? I know that we usually do risk assessment in some ways.

There is a pervasive myth that formal risk analysis is required for processes. A great deal of outcry on Linked In and other sites perpetuates the myth. Some of the loudest outcry is from consultants, who naturally want to exhibit their expertise and advocacy for the user.

But 6.1 of ISO 9001:2015 does not require a formal analysis. It does not require documentation. Guidance documents suggest risk to be handled as per ISO 31000, which probably helped build the myth.

An auditor will ask about risk, and what you do in response to it. If you have a checklist to ensure all requirements are met in the packaging and shipping process, produce it and describe its intent. Checklists are very good for helping to control transaction-type process risks.

The internal audit can help determine effectiveness of actions taken to reduce risk. If your packaging area and shipping area uses a checklist, the audit can include that and compare it to complaints, if any, about problems with shipped product. If your purchasing process relies on ISO certification for suppliers and you find contamination problems with a certain raw material from a certain supplier, that is data indicating your action to address risk may not have been sufficient and you must do more. If that is the case, describe that; you can use supplier CARs and related documents to help show documentation of this analysis.

If an auditor demands you to have a formal risk analysis for processes, ask "Where is the requirement?" The regulated industries will need process FMEAs (Failure Mode Effect Analysis) but without that requirement or a customer requirement, this is not required in 9001:2015. A corrective action stating otherwise should be disputed so the auditor can be corrected.

 

[Big Jim]

All of the posts after Sydney's 1st one give credence to his comments.

In response to the OPs question:

"So, My question is that, is it a requirement of ISO 9001 to do risk assessment on QMS processes? I know that we usually do risk assessment in some ways."

I would suggest the answer is no. I would further suggest that there is a requirement there, but the requirement is that risk awareness is required for all of the quality management system, including the processes. Assessment no. Awareness yes.

I would also suggest that most organizations already do this.

 

[Sidney Vianna]

but the requirement is that risk awareness is required for all of the quality management system, including the processes. Assessment no. Awareness yes.

I like the term Risk Awareness much better than Risk Based Thinking. Very well said, Big Jim.

With so much confusion about RBT, especially when it comes to the conformity assessment practices, there is a risk for clashes. Let me offer the following scenario, one that I bring here, now and then:

Company pays commissions to the sales force for sales volumes. Auditor interviewing a sales person finds out that orders are being accepted, despite the fact that customer expected receipt date of the product is way shorter than the typical lead (delivery) time the organization "guarantees" to customers. Auditor asks the sales person about the potential problem. Salesperson answer: My job is to sell. That's how I make my living. Orders are taken in and production is responsible for ensuring that orders are prioritized/expedited to satisfy the customer requested dates.
Auditor had already identified the fact that there had been numerous customer complaints concerning late deliveries.

Should the auditor identify the situation as a failure of the sales person to use RBT when accepting orders? Would you, as an auditor?

Please note that I am not identifying the auditor as a 3[sup]rd[/sup], 2[sup]nd[/sup] or 1[sup]st[/sup] party auditor.

 

[Big Jim]

I would write such a nonconformance. I don't think that RBT can be used as an excuse for not meeting a requirement. I would write it under 7.2.1 in the old standard or 8.2.2 in the new standard. There may be additional applications as well.

Not only would I write it, I have written them. In one such case I felt like I had thrown a grenade into the closing meeting and nearly immediately left. Their root cause was that their company was out of control. Their corrective action included establishing a means of tracking and scheduling production so that they could have better forecast lead times. It worked. They needed a wake up call.

 

[dhakadmilind]

Dear ,
I have the different opinion on this. In 2015 ,there is no Preventive action and it is get replaced by RBT topic. Now if we dont consider the processes in RBT then how we are going to find out the chances for improvement .
We are having the process for calibration and if we dont consider the Risk in calibration then how we are going face the audit i.e 4.1-4.2 to 6.1 for calibration process.
So as per my interpretation , We have to do the SIPOC and then remaining all clauses will be applicable to it by consider PDCA approach.
Pls need your valuable input on this.
Thanks

 

[howste]

Dear ,
I have the different opinion on this. In 2015 ,there is no Preventive action and it is get replaced by RBT topic. Now if we dont consider the processes in RBT then how we are going to find out the chances for improvement .
We are having the process for calibration and if we dont consider the Risk in calibration then how we are going face the audit i.e 4.1-4.2 to 6.1 for calibration process.
So as per my interpretation , We have to do the SIPOC and then remaining all clauses will be applicable to it by consider PDCA approach.
Pls need your valuable input on this.
Thanks

I believe that if you implement your system per your interpretation the system would meet the risk-based thinking requirements. But to say we "have to" have SIPOCs or any other tool is adding to the requirements.

The requirements we need to meet include considering risk throughout the system and taking appropriate actions. What an organization does to meet these requirements is left up to them. I have personal preferences in ways to do it, but none of them are mandatory.

 

[Big Jim]

Dear ,
I have the different opinion on this. In 2015 ,there is no Preventive action and it is get replaced by RBT topic. Now if we dont consider the processes in RBT then how we are going to find out the chances for improvement .
We are having the process for calibration and if we dont consider the Risk in calibration then how we are going face the audit i.e 4.1-4.2 to 6.1 for calibration process.
So as per my interpretation , We have to do the SIPOC and then remaining all clauses will be applicable to it by consider PDCA approach.
Pls need your valuable input on this.
Thanks

You are dramatically overthinking this. You prepare for calibration by meeting the requirements of 7.1.5. What is in 7.1.5 are requirements, not suggestions that you apply risk consideration to if you don't meet the requirements.

 

[Sidney Vianna]

Well, Sidney has made quite a few posts in which he for all intents and purposes has said that this version is poorly written (to say the least).

ISO and IEC standards are supposed to follow the ISO/IEC Directives Part 2 Document - Principles and rules for the structure and drafting of ISO and IEC documents. Section 5.5 stipulates:

Requirements shall be objectively verifiable. Only those requirements which can be verified shall be included.

The prolongued and numerous discussions we have on RBT can be attributed, in my estimation, to the failure in creating RBT-related text in 9001:2015 which is easily and readily verifiable.

I have been a member of the Cove for 16 years. For over 12 years, I have been providing pointers to guidance documents, interpretational papers, etc... but I have also pointed out that many of them don't offer pragmatic, actionable, conclusive and authoritative assistance. To pretend otherwise is counterproductive, in my view.

 

[Jen Kirley]

ISO and IEC standards are supposed to follow the ISO/IEC Directives Part 2 Document - Principles and rules for the structure and drafting of ISO and IEC documents. Section 5.5 stipulates: The prolongued and numerous discussions we have on RBT can be attributed, in my estimation, to the failure in creating RBT-related text in 9001:2015 which is easily and readily verifiable.

I have been a member of the Cove for 16 years. For over 12 years, I have been providing pointers to guidance documents, interpretational papers, etc... but I have also pointed out that many of them don't offer pragmatic, actionable, conclusive and authoritative assistance. To pretend otherwise is counterproductive, in my view.

True, that. I keep sending the links because the documentation, however wonkish, is from the technical committee and not just the opining of a consultant (who might have a questionable agenda). I do also recommend the book ISO 9001:2015 In Plain English, which I think does a very good job of explaining it.

 

[Sidney Vianna]

True, that. I keep sending the links because the documentation, however wonkish, is from the technical committee and not just the opining of a consultant (who might have a questionable agenda).

In my opinion, there are some decent papers offered by the TC 176, but, then, there are some useless material as the paper on ISO 9001:2015 and Risk. To use the example of crossing a road as the scenario to exemplify RBT is a huge mistake. Some of the people developing these papers are so afraid (scared actually) of being called wrong that they never develop authoritative guidance. They are always on the fence. Why not create several scenarios in the business world, scenarios typical users of the standard can relate to? Crossing a road? Gimme a break.

Let's also remember that the introduction of RBT came up as a result of the ISO TMB decision to "enforce" a common structure of the ISO Management System Standards via Appendix 2 of the Annex SL of the ISO/IEC Directives Part 1 Document.

That "mandatory template" stipulates the following:

6.1 Actions to address risks and opportunities
When planning for the XXX management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to:
— give assurance that the XXX management system can achieve its intended outcome(s);
— prevent, or reduce, undesired effects;
— achieve continual improvement.
The organization shall plan:
a) actions to address these risks and opportunities;
b) how to:
— integrate and implement the actions into its XXX management system processes;
— evaluate the effectiveness of these actions.

Nothing there about RBT. RBT was a mental construct, dreamed to replace preventive action, but it just adds to the confusion. There is NO RBT.

Let's correlate this with the ISO 14001:2015 standard that has to follow the same structure. How do organizations comply with 6.1 in ISO 14001:2015? Via assessment of relevance, significance and materiality of impacts and aspects? We should just adapt the same mindset for quality management.

When it comes to producing products that conform to requirements and satisfying customers, there are aspects of the business processes that might impact such objectives more directly than others. Manage your business process appropriately and, by definition, you are assessing and managing your Q risks.