Force and Effect Chart
Duffy: Beyond the Basics
Root Cause Analysis
A Process FMEA identifies potential failure modes, effects, and causes that may prevent the manufacturing processes from producing a new design that meets all of its design objectives. It is a process that identifies potential process variables in order to focus controls for prevention or detection of potential failures. The process FMEA is to be considered a living' document that is changed and updated as the process evolves and matures. Risk assessment via the use of risk priority numbers is completed in order to prioritize preventative and detection actions.
A Design FMEA identifies potential failure modes, effects, and causes that may prevent a new design from meeting all of its design objectives. The design FMEA is a process that analyzes the product's design characteristics relative to their intended function to ensure that the resultant product meets customer needs and expectations. When potential failure modes are identified, action must be initiated to eliminate or reduce their occurrence. Risk assessment via the use of risk priority numbers is completed in order to prioritize the actions.
General Description of FMEA
Failure mode and effects analysis (FMEA) is a systematic procedure paralleling the mental discipline of the design process. The procedure is divided into three parts, system FMEA, design FMEA and process FMEA. These FMEAs should be completed prior to release of the product to manufacturing, between the concept and development design reviews, and should include customer specific requirements as applicable.
1. INSTRUCTIONS FOR CONDUCTING FAILURE MODE AND EFFECTS ANALYSIS
1.1. Documenting the FMEA
The FMEA is documented by the completion of the top portion (header) of the applicable QMD Forms. The other blocks are completed as needed. The assignment of an FMEA Number by the business unit is optional. Other forms may be used to document the FMEA provided they are acceptable to the local business unit or the customer. Computer software providing the ability to document and update the FMEA may be used in lieu of the more traditional paper forms if desired.
1.2. Component (Process)
Identify and list all components of the product or (process steps) under study. Include part name and number. A very simple product may consist of only one component, whereas a complex product might have numerous components.
1.3. Component (Process) Function
Specify the intended function(s) of the component (process step) with respect to each functional requirement of the product, whether it is an individual component or a component within a complex product, and also whether/how it applies to process function(s).
1.4. Failure Mode
Describe each potential failure mode identified. The assumption is made that failure could occur and not necessarily will occur. A review of the quality history of similar products (processes) including any design or process FMEAs is recommended as a starting point.
1.5. Effect(s) of Failure
Describe the failure in terms of what the customer (internal and/or external) would notice or experience. The description must be stated as specifically as possible.
1.6. Severity of Failure (S)
Evaluate the severity of each potential failure using a scale of 1 to 10. A 1 indicates the failure would be relatively minor, and a 10 indicates severe total failure. See Figures 1, 4 or 7 for suggested severity ratings to be used in FMEAs.
1.7. Cause(s) of Failure
List all of the causes assignable to each failure mode. Care should be taken to assure that the list is inclusive so that remedial efforts will be aimed at all pertinent causes.
1.8. Frequency of Occurrence (O)
The occurrence rating is based on the probability of the failure cause occurring, and in absence of active intervention, leading to the failure mode. Evaluate the frequency of occurrence using a scale of 1 to 10. A 1 indicates a low frequency, and a 10 indicates very frequent failure. See Figures 2, 5, or 8 for suggested occurrence ratings to be used in FMEA's.
1.9. Prevention Controls
List methods utilized which will prevent or reduce the likelihood of occurrence of the failure cause or the failure mode/effect. These controls will affect the frequency of occurrence rating (see Paragraph 1.8.) and must be considered when evaluating frequency of occurrence. In design, examples of prevention controls are use of design standards, use of existing components with established history of good performance, use of design features to eliminate or reduce likelihood of a given failure mode, etc. In process, examples of prevention controls include error proofing, process capability and performance analysis prior to production, design of experiments (DOE), preventive maintenance, etc.
1.10. Detection Controls
List the methods utilized which will detect the failure cause in time to take corrective action or which will detect the failure mode before the failure effect results. Detection controls must be considered when evaluating the detection rating (see Paragraph 1.11.). In design, examples of detection controls include engineering analysis such as finite element analysis (FEA), tolerance analysis, testing, etc. In process, examples of detection controls are inspections, workmanship standards, etc.
1.11. Detection (D)
Estimate the probability that the failure would be detected before it reaches the customer using a scale of 1 to 10. A 1 indicates a high probability that the failure would be detected before reaching the customer. A 10 indicates a low probability that the failure would be detected before reaching the customer. Customers includes both internal users such as downstream manufacturing processes and external users such as the purchasing customer. QIP Inspection should not be considered for design FMEAs unless 100% inspection is utilized. A Quality Inspection Plan can be used for process FMEA. See Figures 3, 6, or 9 for suggested detection ratings to be used in FMEAs.
1.12. Risk Priority Number (RPN)
The product of the estimates of severity, occurrence and detection (SxOxD) forms a risk priority number which provides a priority of the potential failure modes. These estimates are relative only, having no significance in absolute terms. The purpose is to identify which potential failure modes are most likely to cause problems either internally or for the customer. In general, higher risk priority numbers indicate more serious consequences. The RPN provides a means of ranking failure modes in order of their relative importance.
1.13. Recommended Action
Using the RPN and the results of the potential failure mode verification studies, determine which failure modes need action. Enter a brief description of the action on the FMEA form. Items, which require further action, shall be documented using Action Item Form or other documentation methods acceptable to the local business unit or the customer and their status shall be monitored as a part of the design review process. Items requiring no corrective action may be noted as none on the FMEA form.
1.14. Area or Individual Responsible and Completion Date
For each recommended action, identify the responsible area or individual that will complete the action and an expected completion date.
1.15. Action Taken
Following completion of the recommended action, enter any results or design (process) changes. Include reference to any ECs, engineering or test reports, and supporting documentation.
1.16. Severity, Occurrence, Detection and Risk Priority Number
A. For any completed recommended action, use these columns to re-evaluate the probability of severity, occurrence, and detection to determine the new RPN.
B. To reduce the severity number, the cause or entire failure mode must be eliminated. To reduce the occurrence number, remove or control the cause of the failure mode through design (process) changes. To reduce the detection number, new or improved verification or prevention techniques must be implemented.
2. FMEA RECORDS
2.1. System FMEA, design FMEA and process FMEA record files may also be maintained by business unit and responsible team function as follows:
A. Design assurance (development/product engineering) function.
B. Quality/reliability engineering function.
C. Process/manufacturing engineering function.
2.2. System FMEA, design FMEA and process FMEA revisions, updates, and/or corrective actions, must be issued and distributed to the business unit and responsible team functions listed in Paragraph 2.1. above.
A system FMEA identifies potential failure modes, effects, and causes that may prevent a system from meeting all of its system objectives. The system FMEA is a process that analyzes the customer’s requirements/characteristics relative to their intended function to ensure that the resultant product meets customer needs and expectations. When potential failure modes are identified, action must be initiated to eliminate or reduce their occurrence. Risk assessment via the use of risk priority numbers is completed in order to prioritize the actions.
Action Item Form Description
An action item is a documented activity, event, or task. Action items are discrete entities that can be dealt with by a single person.
Action items are typically created during a discussion by a group of people such as a project team who are meeting about one or more topics and during the discussion it is discovered that some kind of action is needed. The act required is then documented as an action item and usually assigned to someone, such as a member of the group. The person to whom the action is assigned is then obligated to perform the action and report back to the group on the results.
Action items are usually documented in the meeting minutes and are recorded in the task list of the group. As people complete action items, the items are documented as being completed and the item is removed from the list of outstanding action items.
A usual format for an action item is to record an action item number, the date when the action item is identified or created, the name of the person to whom the action is assigned, a title description of the action, and a more detailed description of the action and its outcomes. The action item number may be the date of the meeting followed by a sequence number with each action item for that date being assigned a unique sequence number. For instance, a meeting held on September 03, 2008 may generate three action items whose identifying numbers would be 2008090301, 2008090302, and 2008090303 using a YYYY (year), MM (month), DD (day), NN (sequence number) format.
An action item can be considered a more general form of various types of action/issue/defect tracking methods.