 |
Related Topics: |  |
 |
 |
|
 |
 |
 |
The following list describes the basic analysis procedure for FMEAs and these steps are described in more detail in the sections that follow.
Identify the functions, potential failure modes, effects, causes and current controls.
Evaluate the risk associated with the potential failures and prioritize issues.
Follow up to make sure that corrective actions are performed and re-evaluate risk.
Before you can begin the FMEA, you must decide what you are going to analyze. Determining the scope of the analysis is an extremely important step because it helps to identify which FMEA(s) will be performed and then, for each particular FMEA, the boundaries for what issues will be considered and the approach that the analysts will take during the analysis. The determination of the scope may be based on a variety of factors, including (but probably not limited to) timing, complexity and characteristics of the design, risk/importance, available budget, customer requirements, etc. The tools available for determining the scope will vary depending on whether you are performing a design FMEA or a process FMEA.
If you are performing a design FMEA, you may wish to start by defining the system configuration. For example:
System
Subsystem A
Component A.1
Component A.2
Subsystem B
Component B.1
Component B.2
Early in the design process, you may wish to perform a high-level FMEA on the entire system. As the design matures, it will be possible to perform more detailed FMEAs on individual assemblies or components. A change point analysis or preliminary risk assessment may help to focus the analysis effort on the aspects of the design that have the greatest risk and/or have the greatest potential benefit from design improvements. Factors may include:
New technology or new application of existing technology
Potential for safety or regulatory issues
History of significant field problems
Mission-critical applications
Supplier capability
Etc.
Tip: There are many different ways that the preliminary risk assessment can be performed. The Risk Discovery Analysis in RCM++ supports two possible methods: one based on a series of yes/no questions and another based on rating scales.
For each individual FMEA that you will perform, it is useful to define what components and interactions will be included in the analysis. A boundary diagram (or block diagram) shows the physical and logical relationships between the components in the system or assembly. It can identify relationships and dependencies between components as well as critical inputs and outputs.
Tip: In RCM++, you can use the Attachments feature to provide easy access to boundary/block diagrams that have been created with other software tools (such as Visio or PowerPoint).
Alternatively, you can use the FMEA Block diagram feature to create the diagram and link it to the rest of the analysis
If you are performing a process FMEA, you may start by identifying the steps in the process and the operations that must be performed at each step. For example:
Assembly Line
Station A
Operation (Step) A.1
Operation (Step) A.2
Station B
Operation (Step) B.1
Operation (Step) B.2
In most cases, the scope of the PFMEA will be the entire process. However, in some situations, the organization may choose to exclude low-risk portions of the process.
The process flow diagram (PFD) provides a logical, visual depiction of the process that is being analyzed. The diagram typically uses specific symbols to describe different types of activities (e.g., operation, decision, inspection, storage, etc.). It also may include an identification of the product or process characteristics that need to be monitored at each step (e.g., temperature of the oven, thickness of the wax, diameter of the hole, etc.) and the possible sources of variation (e.g., incorrect setup, contamination, machine maintenance, etc.). Such diagrams can be useful to determine the steps in the process that will be analyzed in the PFMEA and to determine the functions and critical characteristics that will be considered in the analysis.
Tip: In RCM++, you can use the Attachments feature to provide easy access to process flow diagrams that have been created with other software tools (such as Excel, Visio or PowerPoint).
Alternatively, you can use the process flow diagram feature to create the diagram and link it to the rest of the analysis.
One of the first steps in performing an FMEA is to assemble a cross-functional team of knowledgeable individuals to perform the analysis. The team should be large enough to make sure that relevant viewpoints and knowledge are represented but not too large. If the team is too large, it will be difficult to have productive discussions during meetings and it will be a waste of an extremely valuable resource – the time and patience of your organization’s subject matter experts. Team members should be familiar with the FMEA analysis process, as it is practiced by the organization. In addition, a skilled facilitator can help to make sure that team meeting time is used effectively and the analysis is performed correctly.
The composition of the team at any particular meeting may vary depending on the focus of the discussion. This may include representatives from:
|
|
|
|
|
|
|
|
|
|
Tip: In RCM++, you can use the analysis plan feature to document the members of the analysis team for each FMEA.
Before beginning the analysis, the team should discuss (and probably document) the underlying assumptions of the analysis and specific ground rules for how the analysis will be performed. Some of these guidelines may be determined already by the organization’s standard practices for FMEA and some may be specific to the particular analysis project. Some of the questions that might be considered include (but are not limited to) the following:
What will be considered a failure?
What are the assumed environmental and operating conditions?
Will the analysis consider failures that result from abuse?
What is the budget and timescale for the project and what are the project deliverables?
What other activities within the organization will the team need to interact with and have the necessary communications been established?
When and where will the team meet?
Will there be a facilitator?
How will decisions be made within the team and how will conflicts be resolved?
What will be the format of the analysis worksheet and what rating scales will be used?
How will the organization track the completion of recommended actions?
And so on...
This list is provided as an example. Other issues may be applicable for your particular situation.
Tip: In RCM++, you can use the analysis plan feature to document the ground rules and assumptions for each FMEA.
Taking the time to gather and review available information before the analysis meetings begin can help to make the most efficient use of team meeting time and achieve an analysis that is thorough and accurate. The appropriate resources will vary depending on the type of FMEA that you are performing and the specific product or process that you are analyzing. If you are performing a design FMEA, some of the resources that you may wish to consult include (but are not limited to) the following:
Bill of materials
Customer requirements, business requirements, functional specs, technical specs
Design schematics, drawings
Feasibility studies or trade-off analyses
Information from similar designs, including field data, FMEAs, etc.
Documentation or contracts from suppliers
Applicable government or safety regulations
If you are performing a process FMEA, some of the resources that you may wish to consult include (but are not limited to) the following:
The process flow diagram
The relevant design FMEA(s)
FMEAs and control plans from similar processes
Customer requirements, business requirements, functional specs, technical specs
Design schematics, drawings
Guidelines, standards and other information about best practice methodologies (e.g., error-proofing)
Lessons learned about the source of non-conformance in similar designs in the past
Applicable government or safety regulations
These lists are provided as examples. Other resources may be applicable for your particular situation.
Tip: In RCM++, you can use the Attachments feature to provide easy access to supporting documentation that may be relevant to a particular analysis.
For each item or step that will be analyzed, the analysis team will use engineering and business judgment to identify the functions, failure modes, effects, causes and controls that will be considered in the analysis.
Function: An intended function or purpose, as described by a required standard of performance.
For design FMEAs, this will include the established functional requirements and may also include ways that the product is commonly misused (i.e., functions that the customer assumes the item will have).
For process FMEAs, it may be appropriate to use the following structure for function descriptions:
Do this … (operation)
To this … (part)
With this … (tooling/equipment)
Failure Mode: The inability to perform a function within the specified limits. Depending on the definition of failure that has been established within the analysis team, failure modes may include:
Failure to perform a function.
Inadequate or poor performance of the function.
Performing an unintended function.
Effect: The anticipated consequences if the failure mode occurs. Depending on the analysis requirements, this may be a single description of the effect of the failure on the entire system/process or the effects may defined at three levels:
Local Effect: The effect on the item.
Next Higher Level Effect: The effect on the next higher level assembly.
End Effect: The effect on the top level item or system.
In the case of process FMEAs, some practitioners have chosen to identify the effects on the assembly plant, the assembly/system and the end user.
Cause: The specific reason for the failure. This may be found by asking "why" until the basic mechanism that brings about the failure is determined. In many cases, there are several levels of detail that could be used to describe the cause of failure. In general, it is best to choose the level at which the organization is able to control the condition and/or take corrective action.
Current Control: A method or action that is planned or currently in place to reduce or eliminate the risk. In many cases, the current controls are classified as "Prevention" or "Detection," where:
Prevention Controls are intended to reduce the likelihood that the problem will occur.
Detection Controls are intended to increase the likelihood that the problem will be detected before it reaches the end user.
Tip: In many situations, an existing document may contain information that would be useful to import directly into your FMEA analysis (such as a requirements document, a process flow diagram worksheet, an FMEA from a similar product/process or a predefined "phrase set"). RCM++ provides numerous features to help you find and import this information. These features are described in Importing and Exporting.
A typical FMEA incorporates some method to identify and evaluate the risk associated with the potential problems identified through the analysis. Risk Priority Numbers (RPNs) and criticality analysis are the most commonly used methods for this.
To use the Risk Priority Number (RPN) method to assess risk, the analysis team must:
Rate the severity of each effect of failure.
Rate the likelihood of occurrence for each cause of failure. This rating should take into account any controls that may be in place already to reduce the probability of failure (i.e., prevention controls).
Rate the likelihood of detection for each cause of failure. This rating should take into account any controls that may be in place already to increase the likelihood that the failure will be detected before it reaches the end user (i.e., detection controls).
Calculate the RPN by obtaining the product of the three ratings:
RPN = Severity x Occurrence x Detection
RPN rating scales usually range from 1 to 10 (or 1 to 5), with the higher number representing the higher seriousness or risk. Sample rating scales are provided in the major industry standards and various textbooks and manuals that address FMEA analysis. In addition, the scales may be created/modified by the analysis team to fit the organization’s requirement or the characteristics of a particular analysis.
In some cases, the RPN may be used as a "threshold" to trigger corrective action. For example: "If the RPN is greater than <?>, corrective action is required." Another approach is to start from the issue with the highest RPN and work down the list. Other organizations might establish policies that require corrective actions to be evaluated for the top 20% of issues. And so on....
However, it is important to remember that the RPN is the product of three subjective ratings and different circumstances may produce similar or identical RPNs. For example, an RPN of 100 could mean:
Severity = 10, Occurrence = 10, Detection = 1
Severity = 2, Occurrence = 5, Detection = 10
Severity = 1, Occurrence = 10, Detection = 10
…
When you consider the different situation posed by each of these scenarios, it is easy to see that basing decisions solely on the RPN may not be appropriate. Therefore, many FMEA practitioners have chosen to look at the ratings and RPNs in other ways. Some of these alternative approaches are described next.
S x O Metric: A metric calculated based on the product of the severity and occurrence ratings only.
SOD Value: A value that displays the severity, occurrence and detection ratings together in the same column of the worksheet. This is not a calculated value. Rather, if the severity is 7, the occurrence is 5 and the detection is 6, for example, then the resulting SOD will be 756. When the issues are sorted in descending order, they will be prioritized first by severity, then by occurrence and then by detection.
SD Value: A value that displays the severity and detection ratings together in the same column of the worksheet. This is similar to the SOD value described above except that it is based on severity and detection only.
Occurrence / Severity Matrix: A graphical chart that displays issues based on their severity and occurrence ratings. It includes thresholds for high, medium and low priority issues.
Ranking Issues by a Single Rating: Tables or graphical charts that rank issues by the severity of the effect or the likelihood of occurrence. For example, all issues with a very high severity rating might receive a high priority even if the occurrence and detection ratings are low.
Customized Risk Ranking Logic: A logic that sets the priority of each issue based on some combination of factors (e.g. "If the severity rating is greater than <?> and the RPN is greater than <???> then the issue is high priority").
With whatever approach is selected, it is important to remember that RPN ratings are relative to a particular analysis. An RPN in one analysis is comparable to other RPNs in the same analysis but an RPN may NOT be comparable to RPNs in another analysis. RPNs are a tool to evaluate risk and prioritize corrective action. The goal of the FMEA is to reduce risk, not just RPN.
Tip: RCM++ provides an extensive array of features to support risk assessment based on RPN and related metrics. These are described in detail in Risk Priority Numbers (RPNs).
The MIL-STD-1629A document describes two types of criticality analysis: qualitative and quantitative. Both types of criticality analysis consider the probability that the failure will occur and the severity of the potential failure. However, the "quantitative" method incorporates the item’s unreliability, which can be determined quantitatively.
To use qualitative criticality analysis to evaluate risk and prioritize corrective actions, the analysis team must a) rate the severity of the potential effects of failure and b) rate the likelihood of occurrence for each potential failure mode. It is then possible to compare failure modes via a Criticality Matrix, which identifies severity on the horizontal axis and occurrence on the vertical axis.
To use quantitative criticality analysis, the analysis team considers the reliability/unreliability for each item at a given operating time and identifies the portion of the item's unreliability that can be attributed to each potential failure mode. For each failure mode, they also rate the probability that it will result in system failure. The team uses these factors to calculate the criticality for each potential failure and for each item.
Tip: RCM++ supports quantitative and qualitative criticality analysis patterned after the concepts in MIL-STD-1629A. This functionality is described in detail in the Criticality Analysis topic.
The next step is to identify, assign and track the completion of recommended actions that will help to reduce the risk associated with potential failures. In some situations, it may be possible to take an action that will reduce the severity of the effect when the failure occurs but in most cases, the recommended actions will be designed to either reduce the likelihood that the failure will occur or to increase the likelihood that it will be detected and controlled before the problem reaches the end user. When selecting the actions to recommend, the team may consider:
Existing controls.
The relative importance (prioritization) of the issue.
The cost and potential effectiveness of the corrective action.
Tip: One of the most costly mistakes among FMEA practitioners is the failure to follow up and track the completion of recommended actions. RCM++ provides multiple features that will help to ensure that your organization implements the actions suggested by the analysis in order to achieve the benefits that come from improving the design and reducing the risk. These are described in Actions.
In many cases, it may be appropriate to revise the risk assessment after the recommended actions have been completed (or based on the results that the analysis team expects to achieve when they are completed). This will provide an indication of the effectiveness of corrective actions and the benefits achieved by performing the FMEA. To use revised RPNs for this purpose, the analysis team will:
Assign revised severity, occurrence and detection ratings.
Calculate a revised RPN.
Compare the initial and revised RPNs.
The % reduction in RPN can be calculated with the following equation:
FMEAs are typically reported in a tabular (worksheet) format. The style varies depending on the standard/guidelines and the terminology used during the analysis. In addition to the worksheet, other tabular reports can be useful to support decision-making and communicate the results of the analysis, such as Assigned Actions, Causes Ranked By RPN, etc. Pareto (bar), pie and matrix charts also can help to visualize analysis results.
An FMEA is most effective when it is a "living" document. When completed, the analysis should be distributed as appropriate throughout the organization so that it can be used as a resource for other activities. Your organization invested too much effort and knowledge to bury the document in the file cabinet!
Tip: In RCM++, you can use the Reports window and the Query Utility to create the reports that you will use to distribute the results of your FMEAs.
In addition, the Plot Viewer provides a variety of charts to present the information graphically.
In general, the FMEA should be reviewed and updated:
When there is a change to the design.
When other factors change (such as the operating conditions or the intended application).
When new information from the field is available.
Tip: In RCM++, there are several ways to manage revisions to an existing analysis, including a formal change log that can automatically record all revisions to an existing analysis and facilitate a process for electronic approval tracking. These features are described in Change Logs.
After the completion of an FMEA project, it can be a good idea to have an expert in the FMEA methodology evaluate (audit) the FMEA. In addition, you may wish to solicit feedback from the team members who participated in the analysis in order to identify issues that should be addressed in future analysis projects. A suitable checklist could be obtained from the FMEA literature or your organization may choose to develop its own audit requirements.
Tip: In RCM++, you can use the analysis plan feature to document the results of the quality survey for each FMEA.
© 1992-2013. ReliaSoft Corporation. ALL RIGHTS RESERVED.