Which ones? Everyone?
Looking at risks and opportunities, IMHO, is a far bigger issue than this. It could mean the viability of the business...
Informational Is Identification of Risks and Opportunities required for QMS Processes?
- Thread starter morteza
- Start date
Your organization’s management system is meant to help the people working for the organization to fulfill its mission; generalized as “converting the needs of stakeholders into cash in the bank”. Right here you have an axample of risk-based thinking that is focused on winning and exploiting opportunities to serve.
When you develop your organization’s process-based management system (from scratch, to improve performance or to bring about project success) you and your colleagues focus on those processes that are essential to the success of the organization; this is an example of risk-based thinking but you may have glossed over that fact because it is so obvious.
Having determined the cross-functional processes essential for organizational or project success you and your colleagues will name the most knowledgeable person as the owner of each process. Again this is RBT.
Working with each process owner you’ll determine the objectives of each process; again this is RBT. You’ll then capture (perhaps in a deployment flowchart linked to any instructions and forms) who are involved and what they actually do to plan the work, do the work and check the work while making corrections and improvements as necessary.
The process owner will then walk this partially documented procedure across the functions or departments responsible so the process team can ensure it is accurate. Some new processes may be necessary so the documented procedures defining the design of these processes would be reviewed by the process team members for their feasibility.
As you can see, when developing the system, quality planning or designing processes you’ll see lots of evidence of risk-based thinking quite naturally.
Going beyond such practical thinking may confuse others or yourself.
John
When you develop your organization’s process-based management system (from scratch, to improve performance or to bring about project success) you and your colleagues focus on those processes that are essential to the success of the organization; this is an example of risk-based thinking but you may have glossed over that fact because it is so obvious.
Having determined the cross-functional processes essential for organizational or project success you and your colleagues will name the most knowledgeable person as the owner of each process. Again this is RBT.
Working with each process owner you’ll determine the objectives of each process; again this is RBT. You’ll then capture (perhaps in a deployment flowchart linked to any instructions and forms) who are involved and what they actually do to plan the work, do the work and check the work while making corrections and improvements as necessary.
The process owner will then walk this partially documented procedure across the functions or departments responsible so the process team can ensure it is accurate. Some new processes may be necessary so the documented procedures defining the design of these processes would be reviewed by the process team members for their feasibility.
As you can see, when developing the system, quality planning or designing processes you’ll see lots of evidence of risk-based thinking quite naturally.
Going beyond such practical thinking may confuse others or yourself.
John
The old "preventive action" requirement was responsible for some of the longest, most controversial and inconclusive threads we had (and for the sake of knowledge management, still have) at The Cove. It is disheartening to see (imo) that risk based thinking will now become the "die-hard" subject for ISO 9001. Easy to see that we will have (the same) endless, inconclusive, protracted discussions on RBT.
I had suggested a few years ago that RBT should had never made it to ISO 9001. It should have been codified as a (broken link removed) in ISO 9000. Inserting into ISO 9001 without proper guidance, just creates confusion in the marketplace, as we can easily see here.
The word risk(s) appear 25 times in ISO 9001:2015, 33 times in ISO/TS 9002:2016; our friends in the ISO TC 176 created a number of free, downloadable files such as:
And, not surprisingly, confusion still permeates practitioners the world over. It is about time the TC 176 should reflect on the quality of their products and react accordingly. Because if (requirements) standards, guidance standards and guidance documents don't deliver on the intended outcome of making their products clear and value added system standardization, there is a problem to be solved and with new chairmanship in the SC2, maybe this is the time for things to happen.
I had suggested a few years ago that RBT should had never made it to ISO 9001. It should have been codified as a (broken link removed) in ISO 9000. Inserting into ISO 9001 without proper guidance, just creates confusion in the marketplace, as we can easily see here.
The word risk(s) appear 25 times in ISO 9001:2015, 33 times in ISO/TS 9002:2016; our friends in the ISO TC 176 created a number of free, downloadable files such as:
And, not surprisingly, confusion still permeates practitioners the world over. It is about time the TC 176 should reflect on the quality of their products and react accordingly. Because if (requirements) standards, guidance standards and guidance documents don't deliver on the intended outcome of making their products clear and value added system standardization, there is a problem to be solved and with new chairmanship in the SC2, maybe this is the time for things to happen.
Andy,
As soon as I hear the word plan I think risk.
So, I guess missing the risk management that I thought was implicit in BS 5750:1979 depends on your background.
When did risk management become something ignored unless explicitly specified?
John
Without getting too far off track, John, you have to go back to the reason for having BS5750/ISO 9001 in the first place. To that, I'd add that the ONLY place the standard referenced "customer" was in response to customer complaints. Even the ISO guidance says risk is "implicit" - in whose eyes? The first few iterations of ISO 9001 were nothing more than a one-size-fits-all supplier quality handbook so that SQAs didn't have to do supplier development and suppliers didn't have to have multiple quality programs. Nothing else. Nothing else was implied, but then not many were around in the beginning, involved at the creation, to know that.
Andy,
The really useful part was covered by clause 4.2.3 Quality Planning as I recall.
But I agree, the rest was much as you describe.
John
The really useful part was covered by clause 4.2.3 Quality Planning as I recall.
But I agree, the rest was much as you describe.
John
And largely avoided because it was too difficult...
This quality planning clause prompted the development of our people>processes>system approach for developing project management systems (as we worked mainly with architects, civil engineers and construction contractors) initially and gradually this approach evolved into my firm’s methodology for developing process-based management systems in other types of organization.
We first published this methodology for all to use and improve in 1986.
14 years later the process approach became the norm.
And Rede Group - who wrote one of the first ever Lead Auditor courses consulted on this basis - and still a large population didn't (and don't) get it...
Similar threads
