[校稿]第七篇——FMEA Can Add Value in Various Project Stages

本帖最后由 小编H 于 2011-7-19 15:12 编辑

请对以下文章有翻译兴趣的组员留下你的预计完成时间，并发短信息联系小编H，以便小编登记翻译者信息以及文章最终完成时的奖惩工作。
PS：原文有图表，请翻译者务必联系小编，以便把原文文档发到翻译者邮箱~~~


原文：

FMEA Can Add Value in Various Project StagesAlthough it is typically taught in the Improve stage of training, the FMEA has a place in other phases as well. But before practitioners can gain varied benefits from the tool, they must first be clear on how to use it.By Luca Bencini and Steve PautzThe failure mode and effects analysis (FMEA) tool has several variations. In transactional environments, it is sometimes referred to as an EMEA – where E stands for human errors. Other variations include the process FMEA (pFMEA) and design FMEA (dFMEA). The fundamental purpose of any FMEA, however, is to identify, evaluate and take actions to reduce risk of failure.Just as there are many variations of the FMEA, there are also many uses for the tool within Six Sigma projects. Although it’s typically taught in the Improve stage of training, it has a place in other phases as well. But before practitioners can gain varied benefits from the tool, they must first be clear on how to use it.How it WorksBefore proceeding with how to use an FMEA within the different phases of a Six Sigma project, it is best to review some key FMEA terms:Failure mode – The way in which a process can failEffect – The impact on the process or customer requirements as a result of the failureSeverity – The impact of the effect on the customer or processRoot cause – The initiating source of the failure modeOccurrence (or frequency) – How often the failure is likely to occurDetection – The likelihood that the failure will be discovered in a timely manner, or before it can reach the customer.Risk priority number (RPN) – The value computed by multiplying the values assigned to Severity, Occurrence and DetectionIn a pFMEA, failures (or errors) occur at a process step. The effects of the failure may be felt immediately after the failure occurs, or they may be felt downstream of the process. Conversely, root causes of the failure may occur immediately before the failure, or way upstream in the process.Severity is always associated with the effect of the failure. What causes confusion is how to rate occurrence and detection. Occurrence can be associated with the failure mode or root cause, and detection can be associated with the root cause, failure mode or effect. To simplify the association, it is best to associate occurrence and detection with failure mode because usually the root causes have not yet been properly identified. The following is a user-friendly example of a pFMEA:
Process StepFailure ModeOccurrenceDetectionEffectSeverityRPN
Wrong destination on tag35Suitcase goes to the wrong destination345
Putting tag on suitcaseTag does not adhere to suitcase (falls off)23Does not leave airport and goes to lost and found530

This simplifies the template in that occurrence and detection follow immediately after the failure mode and severity follows the effect – there is no ambiguity. A process step can have one or more failure modes, and each failure mode might have one or more effects. This means that if a spreadsheet is used, rows are added as failure modes and effects are added. It also allows practitioners to sort by RPN.
Other columns can be added to the FMEA, such as root causes, controls, actions, responsible party and recalculated RPN based on actions. But for Six Sigma projects, the core of the FMEA is relatively simple and usually is sufficient for the Measure and Analyze phases.
As far as the numbers used in the FMEA, there are no generic scales for the three parameters (Occurrence, Detection and Severity). Each FMEA needs its own set of scales and when done in a brainstorming environment, a scale of 1 – 5 is usually sufficient; a scale of 1 -10 tends to increase complexity without additional benefit.
Flexible FMEA FocusWhile the overall approach of the FMEA does not change depending upon the DMAIC phase, the focus of its use does change.
In Measure, the FMEA can be used as a prioritization tool to understand and fine tune the focus of a Lean Six Sigma project. In addition, it also can be used to determine what can go wrong with the process, and what data the team should collect as part of its process metrics.
Example: A team launched a project to reduce reprocessing of materials in a sterilization line. To determine where to focus the initial efforts, the team created a detailed process map, followed by an FMEA to identify failure points in the process that resulted in re-sterilization. Once the FMEA was created, resulting in severity, occurrence and detection estimates, the team focused their project on four areas to eliminate or mitigate failure points.
In Analyze, the FMEA helps to address where to look for root causes. It should be noted, however, that an FMEA is not a tool to identify root cases; but, frequently practitioners can document root causes in an FMEA.
Example: Most processes are not stable, due to the existence of special cause variation. By identifying special causes (sometimes referred to as root causes), practitioners can work to eliminate them, resulting in a stable or more predictable process. For instance, a financial institution had unacceptable variation in its cycle time for processing loan applications. The Six Sigma team completed an FMEA for the whole process, which led to three problem areas (receipt of applications, location where the applications were received and type of loans) to focus on. Subsequently, they collected data and built detailed cause and effect diagrams to help identify root causes for these problem areas.
In Improve, the FMEA may be used to test a solution or process improvement. This testing can make the solution or process more robust, and help identify corrective, preventive and mitigative actions should failures or errors crop up later.
Example: In DMAIC projects and especially in Design for Six Sigma (DFSS) projects, a relatively easy way to “test” a solution is to do a table top exercise (rather than a pilot or full implementation). An FMEA can serve as such an exercise and help identify possible weak points. One example involves a process designed for individuals to send money overseas to relatives. It was a rather complex process in that it had to have proper checks and balances to minimize fraud and to provide an audit trail. Once the process was designed and reviewed by subject matter experts, the Six Sigma team did a detailed FMEA to find potential weak spots. As a result of this effort, changes to the process were made. Subsequently, the process was piloted and the FMEA was updated with the results of the pilot.
In the Measure, Analyze and Improve phases, an FMEA is typically the result of brainstorming because quantitative data is usually not available. However, in Control, an FMEA is updated based on real data and is helpful for continuous and ongoing improvement.
Example: By this stage, the Six Sigma team is ready to close out the project and transfer it to the process owner. It is critical, when appropriate, to also transfer the FMEA (typically the one done in the Analyze phase) to the process owner. This means that the process owner needs to understand the FMEA and, more importantly, how to update the FMEA based on real experiences and data. For instance, a manufacturing plant that produces gasoline tanks made out of plastic resin was experiencing a high level of regrind – meaning tanks that did not meet standards were recycled through a regrinding process. However, there was a limit to how much reground resin could be mixed with virgin resin, so there also was a high scrap rate, as not all the reground resin could be reused. The team made a number of changes to the process (temperatures, pressures, flow rates, curing time, etc.) and used the FMEA to help develop standard operating procedures (SOP). The process owner – who also was a project team member – understood the FMEA well and reviewed and updated it every six months based on process performance. Additionally, this activity resulted in further enhancements to the process.
About the Authors: Luca Bencini and Steven Pautz are Master Black Belts and senior managing consultants with IBM in the Strategy & Change practice. Luca has more than 25 years of experience in Lean Six Sigma as a practitioner and consultant. He also has degrees in chemical engineering and economics from MIT and an MBA from Harvard. Steve has 30 years of experience working in quality in service, manufacturing and government organizations. He has an engineering degree from Pratt Institute and an MBA from Southern New Hampshire University. They can both be reached at mailto:IBMLean@us.ibm.com.