TUESDAY, JULY 29, 2014
Font Size
Six Sigma Tools & Templates FMEA FMEA: Tool for Process Documentation and Discovery

FMEA: Tool for Process Documentation and Discovery

While the name of the failure mode and effects analysis (FMEA) concentrates on how a process fails, the real objective is to concentrate on assessing the effects and process controls for the root causes related to any given failure mode. Practitioners examine the root cause-failure-effect sequence by starting in the middle and working outward. During this evaluation, they not only discover root causes and prioritize them for action to eliminate risk, but they also come away with a valuable documentation of how the particular process works.

Assessing the Risks

People encounter risk in nearly everything they do. And while they often do not quantify consciously most of the risk in their lives, survival and personal success require that they assess each perceived risk to decide how to deal with it.

Risk assessment is an innately human activity and any nominal assessment of risk requires evaluating the severity of an event and factoring that severity by a probability that the event will occur. For example, being struck by lightning is an event that most people would prefer to avoid – one reason why people do not climb metal towers in a thunderstorm.

Risks, however, are balanced with the potential reward of a successful outcome, which is why many people are willing to play golf in a thunderstorm. Such risk analysis is intuitive to most people, and the FMEA simply involves taking that individual cognitive process and transforming it so that it can be performed, documented and repeated in a team environment.

The FMEA allows practitioners to identify an outcome (effect) and quantify it based on its level of severity, using an ordinal scale from 1 to 10. Then it asks: How likely is that effect to occur? Assuming that an effect is the result of a chain of events (root cause to failure mode to effect), then the likelihood of the effect depends on the difference between how often the chain of events is started and how often, once started, the chain of events is stopped. Frequency of occurrence is the term used to describe how often the chain of events is initiated by any root cause. The ability to halt the chain of events is called detectability. The overall evaluation of risk is a product of the severity of the effect, frequency of occurrence and detectability; the resultant value is the risk priority number (RPN).

Ironically, the arithmetic calculation of RPN has nothing to do with the failure mode (only the root cause and effect), but the derivation of the components of RPN has everything to do with the failure mode. The failure mode is often the element of the root cause-failure-effect chain that can be readily defined in the processes. Failure modes are the parts of the process which can be seen and are most appropriate for process teams to examine.

Deceptive Simplicity

The challenge with the FMEA is that it is not that simple in practice. It is easy for teams to confuse root causes with failure modes, and even failure modes with effects. Frequency of occurrence for root causes often cannot be quantified. Severity quantifications are subjective at best.

Actually creating an FMEA from scratch is one of the most painful endeavors a project team will undertake, but also one of the most rewarding. In the meticulous analysis and thorough discussions about extracting the various root cause-failure mode-effect sequences for each process stage, team members describe, synthesize and experience their processes in an entirely new way. It is this process view that drives breakthrough thinking and breakthrough results – and why the FMEA remains one of the staples in the Six Sigma menu of tools.

Deriving Value from the FMEA

In spite of this breakthrough potential, the FMEA as a process discovery and root cause prioritization tool carries a heavy price in team effort and time. But that risk can be managed if practitioners see the FMEA for what it really is: a process documentation tool. Standardized approaches in most industries use the FMEA as a process documentation tool, as outlined in Automotive Industry Action Group publications. This is a fine idea, although documentation alone does not create value. If FMEAs are used to create documentation that will be stored in a file and only produced upon the request of a customer, they are expensive devices for placating customer demands.

Fundamentally the FMEA has two value-enhancing applications: process management and process improvement. To the extent that the FMEA is applied as a process documentation tool, its primary value should result from monitoring process performance through fluctuations in RPNs. The risk of negative consequences will change daily based primarily on changes in frequency of occurrence for root causes; when root causes with high RPNs become top priorities, process team members can decide what actions will be addressed, by whom and when. This is called a response plan. FMEAs used as part of a response plan are particularly effective in DMAIC projects in the Improve and Control phases.

As discussed earlier, the FMEA also is very effective as a process discovery and root cause prioritization tool. This is not how the FMEA was designed to be used, but it can help when building process understanding concentrated on one or a few parts of the process. The area of focus for the FMEA should be guided by the use of process maps, fishbone diagrams, and cause-and-effect matrices. Application of the FMEA for root cause discovery should be limited to no more than eight process steps for a typical DMAIC project. This focus helps to conserve and contain the mental energy of the team, which needs to produce a viable list of prioritized root causes to the process problem noted in the problem statement. Once a DMAIC project moves into the Improve and Control phases, the original design intent of the FMEA can be applied as necessary, particularly if the format is already part of the organization’s standard process documentation or management system.

For companies that do not use the FMEA as part of a process documentation system, the Control phase of a DMAIC project is probably not the best time to put one in place. In that case, though, the FMEA should still be the tool of choice to document actions and monitor the impact of process changes on root causes identified in the Measure phase. Additionally, the FMEA can be used to examine and prioritize risks in the implementation of solutions.

Consider Tool Intent

When applying the FMEA in different stages of DMAIC, practitioners should consider the design intent of the tool and then determine what they need to get out of the tool. Then they must ask themselves: How can I use the tool to provide the process information I need?

Remember that the FMEA works best if it can be tailored for use for a particular situation and applied in a way that optimizes the value it brings. The FMEA can be a process documentation and a process discovery tool at the same time. As a process documentation tool it should be used in a disciplined way according to the organization’s documentation standards. To the extent that it is used as a process discovery and improvement tool, the team should feel free to judiciously manipulate it for maximum effectiveness.

Register Now

  • Stop this in-your-face notice
  • Reserve your username
  • Follow people you like, learn from
  • Extend your profile
  • Gain reputation for your contributions
  • No annoying captchas across site
And much more! C'mon, register now.

Leave a Comment



Login Form