Informational How the addition of "Risk" will affect ISO 9001:2015

[somashekar]

Good lead from Jennifer ...
Similar to the "5 why" analysis that if often applied for the root cause analysis, think of a "What if" analysis for your process / area / work to determine how good they are to handle them. One can thereafter determine changes and build the strength, and continue with timely "What if" analysis to assess suitability. No paperwork necessary in all these. One must be able to talk through the process / area / work and be good to detail questions about most of the "What if" ...
If you are blank OR dodge with some off the hat responses, the auditor will be competent enough to know the RBT is hardly understood.

 

[Mike S.]

Colin, as must of us know, the TC 176 SC2 has released a paper on ISO 9001:2015 and Risk.

As usually happens with the "papers" issued by that body, the document does very little, in my estimation, to clarify "acceptable approaches" on "dealing with RBT". The silly example of RBT when crossing a road does not assist people to extrapolate and abstract it to a business setting. A wasted opportunity to truly help the ISO 9001 users community. When will they learn to develop papers that are useful?

Sidney -- I agree with ya. Imagine how helpful it would be if someone who really understands this subject well took the time to re-write that paper with a useful example or examples! Fame would surely come their way....

 

[charanjit singh]

Thanks to all for the posts in response to my doubts. Actually while trying to find out how the CBs. may interpret the new requirements, I came across the following link:

https://lawrence-international-llc.blogspot.in/2015/04/risk-based-thinking-how-are-registrars.html

Given the present scenario, I wonder whether we may be able to satisfy third-party auditors on new requirements. It is fine to say we can explain how we are trying to mitigate the risks in a given case. But what prevents an auditor from asking for written (hard copy or soft) evidence? It could turn out to be a case of bringing in requirements, e.g. for PFMAs, Control Plans PPAP and so on, through the backdoor, so to say, even though not called for in the standard.

 

[Marc]

Thanks for the link. I rarely comment on links, but this essentially echo's my thoughts. RBT is going to be one of those "I know it when I see it" things which will cause a lot of confusion. I will repeat what I have said in the past - As long as at least one person in the company can speak to it, and is ready to explain to the auditor how the company "complies", no problem.

The question I have at this point is - If an auditor gets a "deer in the headlights" reply, how will the auditor write it up as a non-conformance?

 

[Marc]

Just a quick "bump" - It's 2016 now, heading towards 2017 in a few months.

How do you folks see this now?

 

[John Broomfield]

RBT applied to contract review:

"With this customer we see the risk of having the pay the price of nonconformity as low. Therefore, we will ignore the costliest requirements in our quality planning. Our planning team will also apply the results of their risk-based thinking (RBT) in accordance with our new quality policy."

 

[Kronos147]

How do you folks see this now?

Like most of the requirements, most successful organizations are doing things that meet the requirements, the challenge is setting the stage for it (manual or procedure) and capturing evidence.

I am a HUGE believer in the process approach, so I see RTB applied at the process level, rather than some centralized Risk process.

I plan to capture evidence in our current methods. For example, contract review and production planning. A few changes in wording in the procedure and form explains why looking at capacity is a risk assessment.

 

[charanjit singh]

As we all know, any successful organisation would ensure they take action needed to keep their customers satisfied. They would therefore naturally take into account any potential risks that could impact their ability to do so.

Coming to the satisfaction of the external auditors, one approach could be to list out potential risks along with the probability of occurrence of each. If the probability is very low/remote, it wouldn't justify investing into mitigation of the same. And if the probability is moderate to high, the organisation would already have taken corresponding and proportionate mitigation action. So all that is needed is to prepare such a list and show the same to an auditor if he insists on seeing something in black & white.

 

[Helmut Jilling]

Most good companies have already been doing some degree of Risk based Thinking. Conceptually, it is not that new. But, they have not kept very cohesive records in each case.

I have been suggesting clients develop a simple multi-column matrix that shows what risks were identified, and what actions were taken. Add some simple columns for dates and responsibilities, and use it for each new project. Very similar to a Corrective Action Tracker.

I also recommend clients should analyze each process in their system, for any remaining risks, and consider if any actions should be taken. The same matrix can be applied to that exercise.

 

[Jen Kirley]

I do agree with documenting the risks identified, not to satisfy the auditor but to help keep all of the responsible persons, as well as new process members, appraised of the status and determined areas of focus.

I have spent a fair amount of my time encouraging my clients to take credit for that which has already been done; checklists, as lowly as they seem, are absolutely fair to point to as RBT as long as people can describe their role in helping to control risk. RBT need not be complex to be effective, but people in the processes do need to understand it within the extent of their responsibility and authority.

This standard provides us with a chance to demystify system management and make it more holistic. There has been a great deal of uncertainty, mostly among those who gravitate toward complexity.