Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo Especially for content not in the forum
Such as files in the Cove "Members" Directory

Practical guide to scan for Risks in all QMS systems without missing any

Q

QAMTY

#1
Hi all

In trying to detect risks, I thought it would be enough to analize processes shown in the general process map.
Considering that normally main processes are there.

Now I see that there is some difficulty because it is supposed that processes are documented in procedures, but there may exist requirements which are not in documents, moreover that now some documents are not needed.

What will ve a practical guide to scan risk in all the system without missing them?
Could you provide a guide?
Should we check every clause?

Thanks
 
#2
Good morning.

The 3rd party auditor who just conducted our re-certification audit told us to use the FMEA form for everything when assessing risk. Of course, he then advised us to use a FMEA of the FMEA, to have a plan in case we did forget something in the original FMEA; sort of like a 'Plan B', if you will.
 

ousgg

Starting to get Involved
#3
A couple of things to consider here:

1) There is no obligation on you to encapsulate ALL relevant risks in your risk-management approach. An auditor cannot write you a nonconformity for a risk you have omitted from your system, providing your system has some structure and consistency. It is emphatically NOT an auditor's job to try to identify risks you have missed by nitpicking and/or using their own arcane knowledge - keep your eyes open for this sort of practice, because it's worryingly common.

1b) My advice - start with Top Management. Discuss what the major risks to the business are. Get those properly documented and associate them with action plans. Make sure Top Management communicate this to middle management. This alone should be enough to make you compliant to the requirements, but you can then talk to middle management about how their departments/processes contribute to this risk and identify deeper causes and risks. Some areas will be more fruitful for drilling into than others.

2) Using FMEA for everything is a terrible idea. The inputs to an FMEA need to be structured, otherwise you end up with a free-for-all that is no help to anyone. I recommend you only use FMEAs where they were intended: in product designs and for individual clearly-defined granulated processes (ie - ones with a process flow chart).

2b) My advice - break down Risk Management by business process. In my QMS, Risk Management is part of each process design, and can take different forms depending on the process - some do FMEAs, some do a simpler risk assessment, some just do SWOT. The Risk Management for our despatch department, for example, is simply a list of contingency delivery plans. I have one show-off process owner who has done fault-tree analysis, but then his process is entirely driven by data, so it makes sense in context. You will probably already have a top-level business contingency plan which can slot quite neatly into this structure and might also overall guidance for the process-level documents if it is comprehensive enough.​
 

dsanabria

Quite Involved in Discussions
#4
Hi all

In trying to detect risks, I thought it would be enough to analize processes shown in the general process map.
Considering that normally main processes are there.

Now I see that there is some difficulty because it is supposed that processes are documented in procedures, but there may exist requirements which are not in documents, moreover that now some documents are not needed.

What will ve a practical guide to scan risk in all the system without missing them?
Could you provide a guide?
Should we check every clause?

Thanks
Go to AIQG website (International Aerospace Quality Group) and open the link for Supply Chain Management Handbook and go to section 7.3 Risk Assessment.

Supply Chain Management Handbook - Terms of Use
 
#5
In trying to detect risks, I thought it would be enough to analize processes shown in the general process map.
Considering that normally main processes are there.

Now I see that there is some difficulty because it is supposed that processes are documented in procedures, but there may exist requirements which are not in documents, moreover that now some documents are not needed.

What will ve a practical guide to scan risk in all the system without missing them?
Could you provide a guide?
Should we check every clause?
The short answer is that you are overthinking it. Risk is so diverse and so permeated into everything we do that you could never in your lifetime list it all.
 
#6
Good morning.

The 3rd party auditor who just conducted our re-certification audit told us to use the FMEA form for everything when assessing risk. Of course, he then advised us to use a FMEA of the FMEA, to have a plan in case we did forget something in the original FMEA; sort of like a 'Plan B', if you will.
Gross example of overthinking it. In this case overthinking solutions. This is even worse than turning every instance of a nonconformance into a corrective action.
 
#7
A couple of things to consider here:

1) There is no obligation on you to encapsulate ALL relevant risks in your risk-management approach. An auditor cannot write you a nonconformity for a risk you have omitted from your system, providing your system has some structure and consistency. It is emphatically NOT an auditor's job to try to identify risks you have missed by nitpicking and/or using their own arcane knowledge - keep your eyes open for this sort of practice, because it's worryingly common.

1b) My advice - start with Top Management. Discuss what the major risks to the business are. Get those properly documented and associate them with action plans. Make sure Top Management communicate this to middle management. This alone should be enough to make you compliant to the requirements, but you can then talk to middle management about how their departments/processes contribute to this risk and identify deeper causes and risks. Some areas will be more fruitful for drilling into than others.
Excellent advise
 
#8
2b) My advice - break down Risk Management by business process. In my QMS, Risk Management is part of each process design, and can take different forms depending on the process - some do FMEAs, some do a simpler risk assessment, some just do SWOT. The Risk Management for our despatch department, for example, is simply a list of contingency delivery plans. I have one show-off process owner who has done fault-tree analysis, but then his process is entirely driven by data, so it makes sense in context. You will probably already have a top-level business contingency plan which can slot quite neatly into this structure and might also overall guidance for the process-level documents if it is comprehensive enough.
Even this could be overthinking.

To quote Randy, it isn't rocket science.

Use any of the tools (SWOT, FEMA, etc) when appropriate. Trying to come up with a heavy duty response for every instance every time isn't just impracticle, it is a terrible waste of time and leads to not only ineffeciency but to inadequate answers for the ones that matter.
 
Last edited:
Q

QAMTY

#9
Thanks dsanabria, office35o and Big Jim I appreciate your feedback

Specially referring to what dsanabria suggested, I read briefly such documents, and they are very complete, but consider risk as a formal management,

I wanted to have a simple guide to follow considering how the 2015 version considers the risk, not a really risk management.

Trying to have some guides, I got the next information, have in consideration that I already have 2008.

This is an extracted info from the ISO/IAF document (Auditing Practices Group) regarding to Risk auditing.

what an auditor should look,
In Italic (between rows), is shown what I have planned to do.

An auditor should act in accordance with the following steps and collect objective evidence as follows:

What inputs are used by the organization for risk and opportunity determination?

These inputs should include the following:

_ analysis of external and internal issues

By using SWOT, I got the risks and opportunities and will be registered
with its analysis and treatments in List of risks.
The weaknesses will need some attention, some actions plans, will be carried out.
For sure, some output issues from SWOT will be inputs for the quality objectives.


_ the strategic direction of the organization.

For the strategic direction, I think is a term which expect too much, I´ll make it simple, for that , I will show actions derived from the SWOT analysis and maybe
A piece of paper where I have written the vision, mission of my business.
In this point, I think the auditor will not expect to see complex business analysis, at least in my business ( 30 employees) steel parts manufacturing.



_ interested parties, related to its QMS, and their requirements, also
related to the QMS.

Ok, will be considered what will be detected

_ the scope of QMS of the organization.

Ok, will be considered

_ the processes of the organization.
Is Ok, inviting to owners of all the processes including the top management
I think is good idea that all process owners, participate in detecting risk and opportunities in each process, this way would more effective.

Thanks again
 

Joe Cruse

Mopar or No Car
#10
1) There is no obligation on you to encapsulate ALL relevant risks in your risk-management approach. An auditor cannot write you a nonconformity for a risk you have omitted from your system, providing your system has some structure and consistency. It is emphatically NOT an auditor's job to try to identify risks you have missed by nitpicking and/or using their own arcane knowledge - keep your eyes open for this sort of practice, because it's worryingly common.
:applause: I'm not seeing the "shall" to put together a list of EVERY possible permutation of risk and write that list into your QMS, and definitely not the registrar auditor's job to go out and find all the risks you didn't formally define. To me, your system should be built with the structure and consistency that allows for your business to define, assess, and address the risks to your processes/QMS, AS they get identified. It's not supposed to be a one-time, catch-all list that you build up and add to the QMS for an auditor to see and approve of or get an NC on you from, for failing to document a specific risk that THEY see.
As part of your ongoing, regular QMS/process planning (production planning, etc) you'd generally go through the risks associated as a general course, and if you (or your internal auditors, or an NC incident, etc) identify another risk, well, that's all part of improvement, isn't it?
 
Top Bottom