In this presentation we'll discuss the general approach to performing an FMEA.
In the third FMEA presentation, we'll walk through the specific steps.
Failure mode and effects analysis is typically done using a cross-functional team.
This ensures diverse knowledge and perspectives regarding the product, process,
or service in question.
If you're doing a design FMEA, that is, FMEA in the design stage,
it's important to have process experts on the team.
Likewise, if you're doing a process FMEA,
typically an FMEA done on an existing process or product,
it's important to have design experts on the team.
Typically five to seven team members is a good workable number.
If others are needed for their specific expertise,
they may be added as subject matter experts or ad hoc members.
Be sure to train the FMEA team members before starting.
It's important that this be a team effort.
Do not try to do it alone.
If you need expertise, don't hesitate to enlist the aid of subject matter experts.
Do not forget to listen to your customers
to determine how they intend to use your product.
When you start using FMEA,
a major effort is needed to standardize the scales
that you will use based on your type of business or organization.
Remember, this is a structured brainstorm.
Make sure the team brainstorms all the possible failure modes,
even if they might not happen often.
If two risks have the same RPN score,
the one with the higher severity rating should take priority.
When completing the FMEA,
the team will identify actions to mitigate some of the identified risks.
After the actions have been taken, the FMEA should be reassessed.
Finally, remember that FMEA is a living document.
If new risks are identified or if the product, process or services change,
it's necessary to repeat this analysis based on the new information.
Don't just copy scales from another industry or organization.
Analyze them and modify, if necessary, to make them work for your organization.
At the same time, if customization is not necessary,
if you find scales that will fit your purposes,
don't feel that you need to customize them.
Having standardized scales within your organization
as much as possible is helpful in comparing risks.
If you have trouble finding or creating one through ten scales that fit,
perhaps a one through five scale might be more appropriate for your organization.
You do not have to force fit a 10 point scale.
However, whatever scale you select should have the same number of levels of severity,
occurrence and detection.
Don't let the team get bogged down if there is a small difference in selecting a score.
If the team is one point apart, continue the discussion to analyze the impact.
If there's a wider differences, do not average the scores of different team members.
Again, continue the discussion for a deeper understanding.
Don't get too hung up on the numbers.
As with many team tools, the purpose of the tool is to facilitate team decisions.
The objective here is not the numbers; it's the management and mitigation of risk.
Do not do FMEA simply to comply with some internal or external requirement.
This is a tool for risk management.
It takes commitment to the process to make it work.
An RPN or Risk Priority Number is just that - a tool for prioritizing.
You will not have the time and resources to address every risk, nor should you;
but you will need to address the most important ones.
For this reason, your team may want to develop cutoff scores
after the initial RPN scores are determined.
This is a team decision.
If you set the cutoff score too low, you may waste resources.
If you set it too high, you may leave important risks unaddressed.
Sometimes there's a tendency to discount risks
that have high severity but a low probability of occurrence.
The Yellow Belt Handbook gives the example of the Fukushima reactor disaster,
which was caused by a tsunami triggered by an earthquake.
This is a low probability event, but it had severe consequences.
Low probability does not mean no probability.
These events happen.
Another example is the space shuttle Challenger, which exploded on takeoff in 1986.
The cause was a problem with the O-rings.
NASA was aware of the potential problem, but there was a low probability of occurrence.
And because they had previously had several successful launches,
the probability was discounted.
Every effort to improve quality
and performance requires leadership and management support.
And FMEA is no exception.