Up to this point, we've been discussing FMEA in general terms. In this presentation we will go through the steps to perform the analysis. There are variations of the steps required depending on the author. Pyzdek and Keller in their 2010 Six Sigma Handbook identified ten steps. The Lean Handbook, and Six Sigma Yellow Belt Handbook, offer a more detailed 13 step process. Before you begin an FMEA for a product service or process, the subject should be well-defined. In the case of a process, it should be well-defined including its scope. Other tools, such as a SIPOC diagram, and a process map will help the team to document and understand the process before you begin the FMEA. So these are the 13 steps, review, brainstorm, list potential effects, assign severity ratings, list possible causes, assign occurrence rating. What are the current controls, assign a detection rating, calculate the RPN, develop an action plan, take action, recalculate the RPN, review and update. The first step is to make sure the team has a thorough understanding of the product, service, or process. We do that by reviewing documentation. In the case of a design FMEA, a block diagram of functions and their interfaces should be reviewed. In the case of a process FMEA, a process map will serve the same function. Regardless of the type of FMEA, we want to thoroughly brainstorm the question, what could go wrong? How could this product, service, or process fail? We want to identify any potential failure modes regardless of the probability. We then want to identify potential effects. If a particular failure mode occurs, what are the interim or immediate effects? What's the end effect? Severity is the first of the three values that we will assign and use to calculate our risk priority number. This is typically a 1 through 10 scale with 1 being low severity and 10 being high severity. This assessment by the team is based on the information from Steps 1, 2 and 3. For each failure mode, the team will identify probable causes. Note that a failure mode may have more than one cause and each should be treated separately. There are a number of team tools which we've discussed that can be used to identify possible causes. These tools include brainstorming, cause and effect diagrams, nominal group techniques, multivoting and others. The team can also use historical or experimental data and expert knowledge. Occurrence is the second value the team will assign and use to calculate RPN. Again, a 1 through 10 scale is used. A value of 1 represents a low probability of occurrence, and a value of 10 represents a high probability of occurrence. Once we have identified all of the possible causes, we need to assess our current ability to control that cause. There are two basic types of controls, detection and prevention. In either case, there are a number of possible methods for control, including sampling, statistical process control, mistake proofing, and so on. In Step 8, the team will assign the final value used in the RPN calculation. Having identified all the possible causes and the current controls, the team will assess detection. This is the ability to detect a failure after it has occurred, but before customers are affected. Again, we use a 1 through 10 scale, but it's applied a little differently this time. Note that the scale is reversed from the severity and occurrence ratings. In the case of detection, your ability to detect a failure is high, we assign the lowest number. If your ability to detect a failure is low, we assign a high number to detectability. This ensures that for each value, severity, occurrence, and detection, the worst situation has the highest number. Now we can calculate our risk priority number. We can multiple our severity, occurrence, and detectability values to get our risk priority number. The higher the number, the higher the risk. Some industries also use a criticality calculation, which is the product of severity and occurrence. When the RPNs have all been calculated, the team may want to determine a cutoff score. You won't be able to address every item on the list. If you set the cutoff too low, you may waste your resources. And if you set it too high, you may overlook important risks. In Step 10, the team needs to develop a plan to take action on the biggest risks. This may include action to improve on current controls, or to reduce the probability of occurrence. This could involve redesign of the product, service or process. After developing the action plan, it seems that this step would be simple. But it's at this step that lack of management support often rears its ugly head. The actions have to be implemented and the results validated. Often this requires prototypes or a pilot implementation. After the actions in Step 11 have been completed, the team will re-calculate the RPN based on new information. It may be useful to use other evidence like warranty claims, customer's feedback, etc, to enhance the reassessment. Ideally, every cause for every risk will be reduced below the cutoff that was previously determined by the team. As we mentioned before, FMEA is a living document. Review should be done periodically using updated data and information to verify that the risk priority number has not gotten worse, and to identify new risks. It's also necessary to reassess any time a change is made to the product, process, or service.
