"Demonstrating" Risk Based Thinking

Our procedures and work instructions now have icons that represents the risk of how things are being done. If we are not following these work instructions and policies the risk will be identified as either Quality or HSSE. The impact for quality will be the internal and external customers (that's risk-based thinking for us). We will see during the audit. I am positive that this will fly.

 

Exactly. It is unfortunate that the ISO Guidance documents on RBT are not great in clarifying the expectation on RBT deployment, but in my view, as already mentioned on this thread, RBT is the expected "mind-set/framework/thinking cap" to use when making some of the decisions that "haunt" QMS professionals for ages, such as:

• can I extended the calibration interval of some rarely-used devices?
• do I need to audit every process every year, as part of my internal audit program? Etc..

as indicated by the explanatory sentence below:

From Annex A4, ISO 9001:2015:

 

Hi,

Sidney. The point is that is the only requirement where ISO uses the term and yet that is where users seem to be fixated. So, turning it around, if we all concentrate on putting in place systems that identify and manage risks (in the sections of the QMS covered by the ISO 9001 sections I quote) then we will have satisfied the principle of RBT and the only requirement is for top management to support all this good work.

 

It should have been, indeed, a principle listed in ISO 9000. Too bad they did not have the vision to define RBT as the 8th QMP.

 

What particular value will be added by RBT to a client? QMS certified to both 2008 and 2015 versions will consistently provide products that meet customer and applicable statutory and regulatory requirements and will aim to enhance customer satisfaction.

 

Let's consider the same mature organization which was certified to 2008 version and now is certified to 2015 version. What advantages and benefits should RBT bring in terms of QMS performance? In both cases conformity of products and enhancement of customer satisfaction is ensured.

 

The same advantages they already have for using RBT while certified to 2008.
The 2015 standard names it...2008 didn't. AFAIK, that's pretty much the only change here.

I keep reading FMEA, Risk Matrix, Documentation of RBT and it makes me cringe.

The world was round long before the Europeans "discovered" the fact.
Si could be doped to have useful electrical gate properties long before the word transistor was coined.
Air was softer than metal long before there was an airbag.
North America existed long before it was on a map.
...and RBT was in wide spread use long before the 2015 standard was written.

It makes me wonder where the burden of proof will lie during an audit. Must I prove that I use it, or must the auditor prove that I don't?
Evidence that I use it has all around the plant for decades. Someone is going to have a very hard time proving that RBT is not used.
Be darned if I'm going to write and edit hundreds of documents just around someone's new choice of words.

 

It was discussed at some length and we decided that it didn't warrant a principle all on its own as all of the content was covered elsewhere. There was a lot of what has turned up in 9001 in 'Context' covered in Customer focus (to include interested parties and their expectations), Improvement (including a risk based approach) and Relationship Management.

As with any decision there are pros and cons, I just hope we came to an acceptable balance.

 

Hi QMSmaster,

We (my customer and I) did the risk assessment and creating the register with a bottom up approach. We held risk identification sessions with every department to allow the employees to come up with the risks for their part of the business. This allowed us to develop a pretty clear register including the ideas from higher management.

We created a case study out of the approach. Feel free to check it out.

http://blog.qooling.com/iso9001-2015-practical-guide-for-risk-assessment/

 

Not sure how to understand this sentence. If RBT was something that was easily understood and stood on it is own, we would not have all of these discussions about what RBT entails in the websphere, isn't it? As I see it, RBT would have been THE PRIME candidate to be treated as a QM Principle.

You know very well some people claim that the vagueness in the standard is intended so "additional guidance can be sold" in the form of books, webinars, Technical Specifications, etc. The TC 176 could kill that myth in no time, if they developed and released PRAGMATIC, AUTHORITATIVE Free Guidance Documents. Their first attempt to "explain" RBT was a nonsensical "crossing the road" example. The RBT Presentation is definitely a much better document, but in my estimation, it does not put the issue to rest with the user community and the evidence, once again, is the number of threads and discussions taking place all over the specialized fora.

 

Andy, by "mature" I meant a well developed organization.

Bev, I asked to compare QMS-2008 with QMS-2015. The former implements 8.5.3 Preventive action. The latter implements RBT. The organization is the same. What value will be added by implementing RBT as compared with corrective actions toward potential nonconformities?

 

If the preventive action requirement was accomplishing it's objective, why did they dropped it from the standard? Many of us here used to participate in the best web space ever created for quality professionals and, over the years, we had numerous and prolonged discussions on "compliance with 8.5.3". Many of us (myself included) actually were on the record stating that 8.5.3 should be dropped from ISO 9001. While they will NEVER admit it in public, I have no doubt that our discussions in the Elsmar Cove were read by some participants of the TC 176 and our wishes have been answered.

Preventive action requirements (as phrased in 8.5.3 of ISO 9001:2008) created more problems than it solved. RBT is an attempt to maintain a preventive mindset in problem avoidance. But, because ISO provides no AUTHORITATIVE guidance, opinions will continue to clash on what (if anything) is required to comply with it...as this thread exemplifies, together with hundreds of others elsewhere in the websphere.

 

Ahhhh, finally....

Mindset.
Not document
Not Risk Assessment team
Not deployment
Not satisfying a requirement
Not committees
Not paperwork
Not implementation
.......Mindset.

Thank you Sidney.