Lean Sigma: A Practitioners Guide

2017-07-07 02:10:07

35. Process FMEA

Overview

Failure Mode & Effects Analysis (FMEA) is a type of risk management. There are at least four types of FMEAs used in the Lean Sigma world, each considering the failure of different project related elements:

Market FMEA. Considers the risk of failure of a product offering entering a particular market segment during the development process through things like Customer acceptance, technology immaturity, and competitive landscape.

Design FMEA. Considers the risk of failure of a product design or system design characteristic (a measure of performance of the product) during the development process due to supplied raw material capability, process capability, and the robustness of the design itself.

Project FMEA. Considers the risk of failure of meeting a project deliverable in any type of project whether it be Lean, Six Sigma, or a major Engineering project.

Process FMEA. Considers the risk of failure of an input to a process step.

This Lean Sigma guide is aimed at process improvement and the focus here is the Process FMEA.

Logistics

This is a Team activity and should include representation for all the key areas affecting the process. Choose those individuals who live and breathe the process every day, not just process owners who might not be close enough to it to know the details.

It typically takes a morning to complete the preliminary FMEA, but as a tool, FMEA should be revisited at every project meeting for at least ten minutes to identify new risks and to follow through on the action items.

It is tempting for the Belt to create a straw man of the FMEA prior to working with the Team. This is typically a mistake because the Team doesn't feel buy-in to the FMEA and the overall result is usually not as rigorous as it needs to be.

For the initial construction it is usually best to use sticky notes and then transfer the creation into a spreadsheet. The scoring can be done by projecting the computer image onto a screen.

Roadmap

The stages to the construction are as follows (see Figure 7.35.1):

Figure 7.35.1. Steps 15 for construction of the Process FMEA.

Step 1.

List the process steps and their associated Xs in Column 1 and 2. These come directly from the Cause & Effect Matrix and represent an already slimmed down and ranked list. This gives immediate focus to the more important Xs.

Working systematically one X at a time, complete Step 2 through Step 10.

Step 2.

For the X in Column 2, list all the ways that the X can fail, known as the Failure Modes. The most common mistake here is to list why it would fail as opposed to how. Example Failure Modes for any X are

X is too high (light too bright)

X is too low (light is too dim)

X is intermittent/variable (light flickers)

X is missing (no light at all)

Any X can have multiple Failure Modes and each must be dealt with separately by adding additional rows in the FMEA. A good place to look for potential Failure Modes is the Murphy's Analysis.

Belts with Transactional projects often struggle at this point, specifically when the X they are considering is a resource (person) who does a particular process step. The pitfall here is that a person is not really a single X, but a group of Xs, which should have been expanded when creating the Process Variables Map. A better X related to the person might be their skill level (Failure Modes: too highly skilled, too low skilled, patchy skills, no skill) or their availability perhaps (Failure Modes: intermittent availability, constant low level of availability, not available at all).

Step 3.

For each Failure Mode, list the Effects that the Failure Mode would have on the downstream Customer(s). These can remain grouped in one cell in the spreadsheet as you consider them as a whole and focus on the worst case of them as you proceed (i.e., don't create additional rows in the worksheet at this stage).

Step 4.

For each Failure Mode list the Cause of the Failure Mode. Each Failure Mode can have multiple Causes. Unlike the Effects column, the Causes are all dealt with separately, and an individual row should be created for each Cause (see Figure 7.35.2). The Cause is the "why" the Failure Mode occurs.

Figure 7.35.2. An example of a Standard Scoring Table.
Rating	Severity of Effect	Likelihood of Occurrence	Ability to Detect
10	Lose Customer	Very high: Failure is almost inevitable	Cannot defect
9	Serious impact on customer's business or process	Very high: Failure is almost inevitable	Very remote chance of detection
8	Major inconvenience to customer	High: Repeated failures	Remote chance of detection
7	Major defect noticed by most customers	High: Repeated failures	Very low chance of detection
6	Major defect noticed by some customers	Moderate: Occasional failures	Low chance of detection
5	Major defect noticed by discriminating customers		Moderate chance of detection
4	Minor defect noticed by most customers		Moderately high chance of detection
3	Minor defect noticed by some customers	Low: Relatively few failures	High chance of detection
2	Minor defect noticed by discriminating customers	Low: Relatively few failures	Very high chance of detection
1	No effect	Remote: Failure is unlikely	Almost certain detection

At this point we have a three step causal chain: the Cause, which causes the Failure Mode, which in turn causes the Effect.

Step 5.

For each individual Cause list the current set of Controls for the causal chain Cause Failure Mode Effect. Be specific about the Controls. Sometimes Belts mistakenly list that no Controls are in place when in reality the operator might, for example, see a visible impact, thus forming the basis of a detection mechanism albeit informal.

Step 6.

After a process step has been examined, transfer the Failure Modes, Effects, and Causes from the sticky notes to an Excel spreadsheet ready for scoring. The Severity, Occurrence, and Detection rates are scored based on a scoring matrix. There are many of these available (see Figure 7.35.2). If at all possible, a standard should be set for certain types of projects across the organization, or better still one standard for all projects.

Step 7.

For each Failure Mode score the severity of the worst case of the list of effects associated with the Failure Mode as per the scoring table (see Figure 7.35.2 and Figure 7.35.3). Severity ratings are from 1 (best case) to 10 (worst case).

Figure 7.35.3. Steps 710 for construction of a Process FMEA.

Step 8.

For each Cause (usually multiple per Failure Mode), rate the likelihood of occurrence as per the scoring table. Occurrence ratings are from 1 (best case) to 10 (worst case).

Step 9.

For each Control group (one group per Cause), list the detection rate of the combined group of Controls. Detection ratings are from 1 (best case) to 10 (worst case). The Controls are considered on their ability to impact the causal chain Cause Failure Mode Effect. The further back up the chain (in the direction of the Cause), you move towards prevention; thus a lower score is given. The further down the chain (in the direction of the Effects), you move towards the Customer detecting the chain of events for you; thus, a higher score is given. If absolutely no controls are in place at all (not even operator vigilance), then the score is a 10.

Step 10.

The Risk Priority Number (RPN) is calculated as RPN = Severity x Occurrence x Detection

Step 11.

Sort the whole FMEA on the RPN Column so that the highest RPNs come to the top.

Starting with the highest RPNs and working downwards, row by row, complete Step 12 for each row until a point is reached down the FMEA that is considered to have a negligible effect on the process (i.e., down in the noise).

Step 12.

Identify what action is required to reduce the RPN (see Figure 7.35.4). Focus is usually in the order Detection (Controls) first, then Occurrence, then Severity. Each action should have

An owner

A due date

An associated cost

An associated benefit

At this point the preliminary FMEA is complete; however, this is an evolving tool that should be revisited at every Team meeting to sign off on completed actions and to add new Failure Modes, and so on, if appropriate. After an action has been completed, the Team recalculates the Severity, Occurrence, Detection, and subsequent RPN (which should have lowered or otherwise the action was worthless). The lower RPN should be enough to drop it out of the danger zone and down into the noise. If not, then this particular Cause Failure Mode Effect chain should be revisited after the higher RPNs have been actioned.

Figure 7.35.4. Step 12 for construction of a Process FMEA.

Interpreting the Output

The primary output of any FMEA is the set of actions and the implementation of those actionsanything else is just theory. If the FMEA is not to be acted upon then its construction was a complete waste of time.

An FMEA might span multiple pages with many, many related action items. It is not required that the Team complete all of the actions. At some point down the FMEA (based on the RPN), actions "get down in the noise." Only the meaningful (higher leverage) actions should be completed, or the Team goes on ad-infinitum.