Narrow(er) Focus

When teaching failure mode and effects analysis (FMEA), I start by determining who in the class has participated in creating one. Typically, more than half of the students raise their hands. Next, I ask how useful or accurate their FMEAs were. Responses usually include grumbling, a few shrugged shoulders and at least one thumbs-down. Rarely do I receive a positive response. Finally, I ask how much fun the FMEAs were. This question always produces a round of laughter and more thumbs-downs.

Virtually everyone recognizes the potential value, power and utility of FMEAs, but rarely do they see that potential realized. Frequently, I hear creating an FMEA is time consuming, torturous and often confrontational, and the end product never meets expectations. Team members become tired and frustrated, and the overarching goal evolves into simply finishing it. If you feel an affinity, rejoice. It doesn’t have to be this way.
Three problems
There are three common FMEA problems. The first two are performing the wrong depth of analysis and working without a process map. When you correctly address these first two problems, you can seamlessly avoid the third problem, which I believe to be the most serious: identifying the potential failure mode (PFM).

To resolve this third issue, there’s the 7PFM failure model, a significantly different approach that resolves failure mode identification issues.
To begin, focus on creating a process map. The abridged FMEA process map in Figure 1 doesn’t address preparation, team selection, customizing severity, occurrence and detection (SOD) scales or taking action. These are important, but not the focus of this article. The steps are predicated on rapidly building a robust FMEA by resolving the three problems.
First, however, I want to address the debate surrounding construction by row versus by column. I was taught to use columns, but camps appear to be split about 50-50. Approaches really should be combined.

The team begins with failure modes, working in columns. Next, the team populates the effects, causes and controls columns, working in rows. When a failure mode has multiple effects, causes or controls, however, the team completes the effects, causes and controls in columns for that failure. Next, the team continues on with the rows or to the next failure mode. The last thing the team does is score the SOD scales in columns. Combining approaches will create continuity within each process step.
Because all FMEA types generally possess the same structure and problems, the techniques presented in this article apply to all FMEA types. For example, in place of a process map, design FMEAs can use a design document, such as a boundary diagram.

Problem one: depth of analysis
Problem one concerns the depth of analysis the FMEA must focus on (process map step one). Too often, teams dig too deeply. The intended use of the FMEA determines the depth of evaluation. Typically, it is the FMEA requester or owner who establishes the appropriate scope and level of analysis with the help of the FMEA team leader and a quality leader.

Analysis depth can be defined as system level, subsystem level or component level. In class, I frequently describe FMEA focus as analysis at the 10,000-meter level working down to the molecular-component level. Often, I encounter an FMEA team that needs its FMEA to focus at the 10,000-meter level, but the team is determined to identify actions at the molecular level. This results in a huge FMEA and much wasted time, effort and frustration for everyone.

Typically, those who know the process extremely well feel compelled to take the deep dive and identify every possible molecular-level problem they have ever seen or imagined. These subject matter experts (SME) just can’t stop thinking about part transfers, clamping, coolant and the limit-switch arm that fell off in 2008. As the team digs deeper into the process, it begins to experience exponential increases in failure complexity. This complexity leads to all sorts of frustration and problems.

When the FMEA is focused on a specific problem in a specific location, the focus will be at the molecular level—for example, Six Sigma projects. To find the specific problem location, however, you may need to start at the 10,000-meter level. If you need to satisfy an International Organization for Standardization requirement or audit, you will probably select a higher-level system FMEA.
Select logical start and finish locations, and describe each system-level process step, machine or location as a black box. Even if multiple operations happen inside, you just need to know what is supposed to come out.

For example, a part is transferred into a system-level operation called operation 101. The part is transformed in one or more ways, and then exits. End of story. One or more quality specifications determine whether it was a successful transformation.
What goes on inside the black box doesn’t matter at this level. All that must be described is the transformations performed inside operation 101 in a verb-noun format. The verb-noun descriptor is the process goal.

"Drill hole," "machine face," "thread hole" or all three are examples of verb-noun descriptors. On an assembly line, the transformation may be "install turbo." In a warehouse, "pick part." In an office, "complete Form 200, Part B." If this is a design or machine FMEA, the verb-noun rule still applies, but describes functions instead of operations. All you must know are the goals as defined by the specifications.

For operation 101, the goal is to drill a hole. According to the specifications, a successful operation will result in a one-inch hole (+0.005"), drilled one inch deep (+0.005") into the exact center of the part (+0.005"). If any of these requirements are not met, the part is defective. If the part face is also machined, add the verb-noun descriptor, "machine face," with specifications.
If defects occur too often, you might be given a new project to fix operation 101. Then you would create a new FMEA and probe more deeply into the individual components and levels of action. Then you focus on part transfers, clamping, coolant and limit switches.
Problem two: no process map
Start the FMEA by creating a process map (process map step two). The process map serves as the guiding document for the FMEA team. It controls the agreed-on start and finish locations and level of analysis. As with any good map, it must depict the terrain at the appropriate level with absolute accuracy. Post it and ask for feedback from operators, maintenance, engineers and supervisors.

After the team agrees the process map accurately represents the process or design, FMEA construction begins. Each process step will have an identifier and one or more verb-noun descriptors.

Prior to the next FMEA meeting, the leader or scribe prepopulates the FMEA template step or function column by following the process map. A one-to-one relationship exists between the process map and the step or function column. If your FMEA template does not already contain a requirements column, add one. As shown in Table 1, having the requirements visible keeps the team focused on what is required.

Problem three: infinite potential failures
There is good reason to believe PFM identification is the most significant, confounding issue hindering FMEA development. Just do one and notice when your time, frustration and emotions converge.

This problem emerges when the team attempts to select potential failures from a nearly infinite universe of real and often hypothetical modes of failure. Predicated on collective knowledge, a sequestered SME team attempts to predict everything that could potentially fail. That task is fraught with problems and frustration.

Now, add job commitments, personality differences, team dynamics and, often, a lack of leadership. It’s enough to make any team frustrated and a bit testy. Fortunately, a powerful tool exists that resolves the problem.

Enter 7PFM
The tool to use is the 7PFM model. I was originally introduced to 7PFM by its originator, quality consultant John Lindland. If you’re familiar with Lindland’s work, you’ll notice I’ve made some of my own modifications.

The magic of the 7PFM is that it intrinsically reduces the near-infinite universe of potential failures to a manageable and panoptic seven. The 7PFM takes the approach of asking, "What are the fundamental types of failure?" as opposed to, "What could potentially fail?"

7PFM eliminates bizarre failure mode proposals and ensuing discussions. Like me, you have probably heard some strange failure modes proposed and debated through the years.

Using 7PFM, "drunken operator" won’t be a failure mode, only a personal mode of failure at the molecular level.
The methodological beauty is that the leader or scribe prepopulates the FMEA template directly from the process map and 7PFM model before the FMEA meeting (process map step three). With the failure mode column prepopulated, the team simply reviews each PFM’s applicability by column and discards those that don’t apply (process map step four).

You’ll be surprised how quickly and smoothly this process goes. It eliminates most arguments and hours of frustration from the FMEA creation process. If team members reach an impasse, just leave in the failure mode: Err on the side of too many, not too few. Dubious PFMs will get sorted later in the SOD scale scoring (process map step six).

Working by row and column, the team now identifies and completes the failure mode effects, causes and controls for each PFM (process map step five). Finally, the SOD scales are completed by column to maintain scoring continuity.
7PFM model

The 7PFM model is grouped into three disparate domains of failure: failures of quantity, quality and time. Each PFM is combined with the process step (or function) verb-noun descriptor. This creates a clear description of the failure called a failure mode statement (for example, "Did not drill hole"). Each PFM then will have its own assigned effects, causes and controls. Table 2 summarizes the 7PFM model.

It might be helpful to envision all seven PFMs in terms of an energy or resistance model, depicted in Figure 2. The incorrect application of energy or resistance manifests itself as a failed (noncompliant) action result. An action, for example, may fail due to no applied energy or infinite resistance. No energy or infinite resistance equates to no action. Conversely, too much energy or too little resistance may deleteriously increase an action outcome.
The first failure domain identifies failures of quantity. Quantity is comprised of three failure modes: "did not," "too much" and "too little." From previous examples, combine "drill hole" with the three failed actions to form three failure mode statements:
1. Did not drill hole.
2. Drilled hole too much.
3. Drilled hole too little.

Analyze these three failed actions by asking how each would manifest itself in the real world. If the team decides it would be impossible or doesn’t care whether the hole is drilled too much, discard the failure mode. When in doubt, keep it.
Next, failures of quality describe how an outcome deviated from what was planned. They manifest themselves as both common and special causes, the arch enemies of Six Sigma. Failures of quality frequently combine with other failure modes within the same operation. This tends to confirm a high probability of failure.

There are two failure modes of quality. The first, inaccuracy, is defined as an inaccurate application of energy or resistance within a single part, event or application. Inaccuracy could happen to subsequent parts or events, but you’re only interested in the single event. Envision energy or resistance being applied to a transforming operation so inaccurately that it causes a failed outcome. For example, drilling a hole inaccurately could describe inaccuracy in a starting-point location, ending-point location or both.
The second quality failure is inconsistency, which describes variation that happens during the transformation or between transformations. There are two variants:

1. Variant one describes variation during one action in one part. A drilled hole started out at one inch but ended smaller.
2. Variant two describes variations between two or more actions in one part. Part one’s hole one is perfect, but part one’s hole two is off location.

Finally, failures of time manifest themselves as "too fast" or "too slow." There are two variants of each. "Too fast" can describe cycle time and timing. Something happened early, for example. Conversely, "too slow" can describe a slow cycle time, or the action was completed late. Frequently, a failure of time will be legitimate but not applicable.

Drilling a hole too slowly may not have an impact on quality, for example, but it will have a profound impact on productivity. If the FMEA focus is on only quality, the failure "too slow" can be discarded. Likewise, "drill hole too fast" might explain shortened tool life (high speed or feed), but it’s not relevant to quality. "Too fast" or "too slow" timing can be legitimate factors contributing to blocking or starving adjacent operations.

Deselect the inappropriate
Determine scope and depth of analysis, develop a process map and use it to guide and build your FMEA. Use the 7PFM model to deselect inappropriate failure modes and complete the FMEA using a column and row approach. Every operation will exhibit one or more of the seven failures—usually more. Selecting four or five failure modes is common, and all seven is not uncommon.
I’ve seen a lot of poor-to-useless FMEAs. Early on, I helped create some pretty poor ones myself. I eventually found the 7PFM model to be almost magical when applied to FMEAs and error-proofing. Add these techniques to your quality toolbox and have more fun.

Article Reference: QP