Failure mode and effect analysis (FMEA)

A failure mode and effect analysis (FMEA) is a methodology to evaluate a system, a design or a process for possible ways in which failures can occur. For each bona fide or potential failure, an estimate is made of its effect on the total system and of its seriousness. In addition, a review is made of the action being taken (or planned) to minimize the probability of failure or to minimize the effect of failure.

This simple, but straightforward, approach can be very technical (quantitative) or very non-technical (qualitative), utilizing three main factors for the identification of the specific failure:

1. Occurrence. How often the failure occurs.

2. Severity. how serious the failure is.

3. Detection. How easy or difficult it is to detect the failure.

How complicated the approach is always depends on the complexity of the problem as defined by the following (Juran and Gryna, 1980):

• Safety. Injury is the most serious of all failure effects. In fact, in some cases, it is of unquestionable priority and of course, at this point it must be handled either with a hazard analysis and/or failure mode and critical analysis (FMCA).

• Effects on downtime. How are repairs made? Can repairs be made while the machine is off-duty or while the machine is operating?

• Access. What hardware items must be removed to get at the failed component? This area will be of great importance as environmental laws are changed to reflect world conditions for disassembly.

• Repair planning. Repair time, maintainability, repair tools, cost, recommendations for changes in design specifications all should be considered. Here, the Shingo approach, DOE or design for manufacturability may be considered.

To carry this methodology to its proper conclusion the following prerequisites in understanding are necessary.

• You must understand that not all problems are important. This is very fundamental to the entire concept of FMEA, because unless this concept is internalized, we are going to be "chasing fires" in the organization. We must recognize that some problems have a higher priority than others for whatever the reason. FMEA helps identify this priority.

• You must know the customer. The customer is usually thought of as the end user. However, a customer may also be defined as a subsequent or downstream operation, as well as a service operation. When using the term customer from a FMEA perspective, the definition plays a very major role in addressing problems. For example, as a general rule in the design FMEA, one views the customer as the end user, while in the process FMEA, the customer is viewed as the next operation in line. This next operation may indeed be the end user, but it does not have to be. Once you define your customer (internal, intermediate or external) you may not change it—at least, not for the problem at hand—unless you recognize that by changing it you may indeed have changed your problem and/or consequences.

• You must know the function. It is imperative to know the function, purpose and objective of what you are trying to accomplish. Otherwise you are going to waste time and effort in redefining your problem based on interpretations of specific problems or situations. If you have to, take extra time to make sure you understand the function or purpose of what you are trying to accomplish.

• You must be prevention-oriented. Unless you recognize that continual improvement is in your best interest, the FMEA is going to be a static document to satisfy your customer or market requirements. The push for this continual improvement makes the FMEA a dynamic document, changing as the design and/or process changes with the intent to always make a better design and/or process.

Why do we do FMEAs?

The propensity of our managers and engineers to minimize the risk in a particular design and/or process has forced us to look at reliability engineering to not only minimize, but also to define the risk. Perceived risk is driven by the following factors:

• Competition.

• Warranty and service costs.

• Evolving technical risks.

• Market pressure.

• Management emphasis.

• Customer requirements.

• Safety.

• Legal and statutory requirements.

• Public liability.

These risks can be measured through reliability engineering and/or statistical analyses. However, because of their complexity, the FMEA has extracted the basic principles without the technical mathematics and has provided us with a tool that anybody committed to continual improvement can utilize.

Statistical process control (SPC) is another tool that provides the impetus for the FMEA, especially for a process FMEA. SPC provides information about the process in regard to changes. These changes are called common and special causes. From an FMEA perspective we may look at the common causes as failures that are the result of inherent failure mechanisms, and as such, they can affect the entire population. In this case, this is a cause for examining the design (Denson 1992).

On the other hand, special causes are looked at as failures that result from part defects and/or manufacturing problems, and as such, they can affect a relatively small population. In this case, there is cause for examining the process.

Customer requisition is, of course, a very strong influence on why we may be doing a FMEA. For example, all major automobile companies in their supplier certification standards require a FMEA program from their suppliers.

Courts, through product liability, may require some substantiation as to how reliable the products and their performance are.

International standards such as the ISO-9000 series may define for you the program of documentation in your design. For example, the Product Liability Directive of the European Community in 1985 stipulates that manufacturers of a product will be held liable, regardless of fault or negligence, if a person is harmed or an object is damaged by a faulty or defective product (this includes exporters into the EC market). This liability directive essentially reverses the burden of proof of fault from the injured to the producer. Quality systems incorporating specific tools such as FMEA or fault tree analysis (FTA) or failure mode and critical analysis (FMCA) with safety prevention provisions, will be particularly important in protecting a company from unfounded liability claims. Furthermore, proposed safety directives would oblige manufacturers to monitor the safety of their products throughout their foreseeable life (Stamatis 1992).

Other benefits of the FMEA are:

• Improves the quality, reliability and safety of the products.

• Improves the company's image and competitiveness.

• Helps increase customer satisfaction.

• Reduces product development time and costs.

• Helps select the optimum system design.

• Helps determine the redundancy of the system.

• Helps identify diagnostic procedures.

• Establishes a priority for design improvement actions.

• Helps identify critical and/or significant characteristics.

• Helps in the analysis of new manufacturing and/or assembly processes.

Even though all of these reasons are legitimate, the most important reason for writing an FMEA is the need to improve. Unless this need is part of the culture of the organization, the FMEA program is not going to be successful.

Vocabulary of FMEA

To understand the FMEA one must understand its language. There are several terms that one must understand.

Function. The function is the task that a component, subsystem or system must perform. This function is very important in understanding the entire FMEA process. It has to be communicated in a way that is concise, exact and easy to understand—no jargon. To facilitate this, it is recommended that an active verb be found to best describe the function. The active verb, by definition, defines performance, and performance is what a function is—for example, position, support, retain, lubricate.

Failure. The failure is the problem—that is, the inability of a component, subsystem or system to perform to design intent. This inability can be defined as both a known failure and a potential failure. Typical failures are identified as no function; partial function, over function, degraded over time, intermittent function and unintended function. When potential failures in terms of functional defectives are identified, the FMEA is fulfilling its mission of prevention.

Functional defectives are failures that do not meet the customers' requirements, but we ship those products with the failures to them anyway because:

• The customer will never know the difference.

• The customer will never find out.

• The customer will find out, but the failed product that is delivered can still be used.

• The customer will find out, but the failed product that is delivered has to be used because there are no alternatives.

Examples of failures are: broken, worn, corrosion and noise.

Causes of failure. Next to the function, the cause of failure is perhaps the most important section of the FMEA. It is indeed here that we point the way toward preventive and/or corrective action. The more focused we are on the root cause, the more successful we are in eliminating failures. In this section, we must be careful not to be too eager for solutions, because we are going to fall victim to symptoms and short-term remedies, rather than completely eliminating the real problems. What is of supreme importance here is that we must be able to find an actionable root cause. Otherwise, we will fall victims of analysis paralysis. Examples of design causes of failure include wall thickness, vibration, torque specifications and shock loads. Examples of process causes of failure are voltage surge, dull tools, improper set-up and worn bearings.

Effects of failure. This is the outcome of the failure on the system and/or the product. In essence, the effects of the failure have to do with what happens when a failure occurs. We must understand, however, that the effects of the failure must be addressed from two viewpoints. The first is local, in which the failure is isolated and does not affect anything else. The second is global, in which the failure can and does affect other functions and/or components. This creates a domino effect. Generally speaking, the failure with a global effect is more serious than a failure of a local nature.

The effect of the failure will also define the severity of a particular failure. For example, a local failure might be a parking light bulb going out; a global failure would be if the power brakes went out. In the first case one can identify a nuisance; in the second case, a catastrophic event is likely to occur.

Product validation controls. These controls exist to prevent the causes of the failure from occurring and to validate repeatability for certain processes, especially with the FDA.

Current controls. These controls exist to prevent the causes of the failure from occurring in the process phase. Some examples are any of the SPC tools, capability and any testing including nondestructive testing.

Design verification controls. These controls exist to prevent causes of the failure from occurring in the design phase—for example, design guidelines and design review specifications.

Relationship between FMEA and other tools

Fault tree analysis (FTA). Fault tree analysis is a deductive analytical technique. It uses a "tree" to show the cause and effect relationships between a single undesired event (failure) and the various contributing causes. The tree shows the logical branches from the single failure at the top of the tree, to the root cause or causes at the bottom of the tree. Standard logic symbols are used.

After the tree has been constructed and the root causes identified, the corrective actions required to prevent or control the causes can be determined. The FTA always supplements the FMEA and not the other way around. In general, the FTA is used to identify the root factors that could cause a failure and their interdependent relationships. Other benefits of the FTA may be to:

• Determine the probability of occurrence for each of the root causes.

• Help visualize the analysis.

• Help identify the reliability of higher-level assemblies or the system.

Failure mode analysis (FMA). Failure mode analysis is a systematic approach to quantify the failure modes, failure rate, and root causes of known failures. Usually, the FMA is based on historical information such as warranty, service, field or process data.

The FMA is used to identify the operation, failure modes, rates and critical design parameters of existing hardware or processes. Because of its ability to utilize historical data and known failures, the FMA is used primarily on current production, as opposed to the FMEA, which is used on changed and new designs or processes.

Both the FMA and the FMEA deal with failure modes and causes. However, the FMA is usually done first, and the information gained is fed into the FMEA.

Failure mode and critical analysis (FMCA). The failure mode and critical analysis is a systematic approach to quantify the failure modes, rates and root causes from a criticality perspective. Criticality is the product of severity and occurrence. It is very similar to the FMEA in all other respects.

The FMCA is used primarily with government contracts based on the MIL-STD-1629A, where the identification of critical, major and minor characteristic is of importance.

Block diagrams and process flow diagrams. A block diagram illustrates the physical or functional relationships as well as the specific interfaces within a system or assembly under analysis.

The block diagrams used in FMEA are:

• System. This diagram is for identifying the relationships between major components and subsystems.

• Detail. This diagram is for identifying the relationships between each part within an assembly or subsystem.

• Reliability. This diagram is for identifying the series dependence or independence of major components, subsystems or detail parts in achieving required functions.

Block diagrams are not intended to illustrate all the functional relationships which must be considered in the FMEA. The diagrams should be made as simple and explicit as possible.

Whereas the block diagram assists in the definition of scope and the definition of interfaces in the system or design phase of development, the process flow diagram does the same thing, but in a given process.

P-diagrams, interface diagrams and FMEA. A P-diagram (parameter diagram) is a tool that helps the experimenter focus on robustness. It relates inputs (signals) to energy transformation to outcomes (responses). Also, it identifies the noise and control factors, as well as the error states. The error states are the failures.

The interface diagram is a visual tool that helps the FMEA team evaluate interactions between the following considerations: physical proximity, energy transfer, material differences and communication.

Design of experiments (DOE). DOE is a special way of conducting an experiment or a study by which certain independent variables are varied to a predefined plan, and the effects are determined on the dependent variable.

DOE is used in reliability testing and can identify the primary factors that are causing an undesired event. The optimum use for DOE in FMEA applications is when there is a concern about several independent variables or an interaction effect of the causal factors.

Control plan. A control plan is a written summary of the producer's quality planning actions for a specific process and/or product. The control plan lists all process parameters and design characteristics considered important to customer satisfaction and which require specific quality planning actions. The control plan describes the actions and reactions required to ensure the process is maintained in a state of statistical control (as agreed between customer and supplier).

It is the FMEA that identifies the critical and significant characteristics and is, therefore, the starting point for initiating a control plan—it is never the other way around.

Mechanics of FMEA

Team. To do a complete job with the best results, an FMEA must be written by a team. The reason for this is that the FMEA should be a catalyst to stimulate the interchange of ideas between the functions affected. A single engineer or any other single person cannot do it.

The team should be made up of five to nine persons (preferably closer to five). All team members must have some knowledge of group behavior, the task at hand, some knowledge about the problem to be discussed, and some kind of either direct or indirect ownership of the problem. Above all, they must all be willing to contribute. Team members, must be cross-functional and multidisciplined. Furthermore, whenever possible or neccessary, the customer or the supplier should actively participate.

Design FMEA. A design FMEA is a systematic method to identify and correct any known or potential failure modes before the first production run. A first production run is viewed as the run where you produce a product or service for a specific customer with the intent of getting paid. This definition is important because it excludes part submission warrant (PSW), initial sample runs (ISR), trial runs, sometimes the prototype runs, etc. The threshold of the first production run is important, because, up to that point, to decide to modify or change the design is not a major thing. After that point, however, the customer gets involved through the letter of deviation, waiver of change or some other kind of formal notification.

Once these failures have been identified, we rank them and prioritize them.

The leader (the person responsible for a design FMEA) should be the design engineer, primarily because he or she is the most knowledgeable about the design and can best anticipate design failures. To facilitate the meeting, the quality engineer may be designated as the facilitator.

The minimum make-up of the team for the design is the design engineer and the process or manufacturing engineer. Anyone else that can contribute, or whom the design engineer feels would be appropriate, may also participate. A typical design team consists of:

• A design engineer.

• A manufacturing engineer.

• A test/development engineer.

• A reliability engineer.

• A material engineer.

• A field service engineer.

Of great importance in the make-up of the team is that the team must be cross-functional and multidisciplined. There is no such thing as the perfect team for all situations. Each team is unique. Each organization must define its optimum team participation, recognizing that some individuals may indeed hold two or more different positions at the same time.

The focus of the design is to minimize failure effects on the system by identifying the key characteristics of the design. These key characteristics may be found as part of the customer requirements, engineering specifications, industrial standards, government regulations and courts—through product liability.

The objective of the design FMEA is to maximize the system quality, reliability, cost and maintainability. It is important here to recognize that in design we have only three possibilities to look at defects, which are:

• Components—the individual unit of the design.

• Subsystem or subassembly—two or more combined components.

• System or assembly—a combination of components and subsystems for a particular function.

Regardless of what level we are in the design, the intent is the same: no failures on the system. To focus on these objectives, the design team must use consensus for their decision, but more important they must have the commitment of their management. The timing of the design FMEA is initiated during the early planning stages of the design and is continually updated as the program develops. As a team, you must do the best you can with what you have, rather than wait until all the information is in. By then, it may be too late.

Process FMEA. A process FMEA is a systematic method to identify and correct any known potential failure modes before the first production run, which, as discussed in the previous section, is the run where you produce a product or service for a specific customer with the intent of getting paid. Once these failures have been identified, we rank them and prioritize them.

For the process FMEA, the leader should be the process or manufacturing engineer, primarily because he or she is the most knowledgeable about the process structure and can best anticipate process failures. As with the design FMEA team, the quality engineer may be designated as the meeting facilitator.

The minimum make-up of the team for the process is the process or manufacturing engineer, the design engineer and operators. Anyone else that can contribute, or the process engineer feels appropriate, may also participate. A typical process team is:

• Process or manufacturing engineer.

• Design engineer.

• Quality engineer.

  • Reliability engineer.

  • Tooling engineer.

  • Operators.

As with the design FMEA, the team must be cross-functional and multidisciplined. Each organization must define its optimum team participation, recognizing that some individuals may indeed hold two or more different positions at the same time.

The focus of the process FMEA is to minimize production failure effects on the system by identifying the key variables. These key variables are the key characteristics of the design, but now in the process, they have to be measured, controlled, monitored, and so on. This is where SPC comes in.

The objective of the process FMEA is to maximize the system quality, reliability and productivity. The objective is a continuation of the design FMEA—more or less—since the process FMEA assumes the objective to be as designed. Because of this, potential failures that can occur because of a design weakness are not included in a process FMEA. They are only mentioned if those weaknesses affect the process, and they appear under the root cause column.

The process FMEA does not rely on product design changes to overcome weaknesses in the process, but it does take into consideration a product's design characteristics relative to the planned manufacturing or assembly process to ensure that, to the extent possible, the resultant product meets customer needs, wants and expectations.

A process FMEA is much more difficult and time-consuming than a design FMEA. The reason for this is that in a design FMEA we have three possibilities of analysis, (i.e. system, subsystem, and component) and in the process we have six, and each one of them may have even more subpossibilities. The six major possibilities for process are:

• Manpower.

• Machine.

• Method.

• Material.

• Measurement.

• Environment.

To show the complexity of each one of these possibilities let us take the machine, for example. To assess a machine failure, a team may have to examine some or all of the following contributing factors, and this list is by no means complete:

• Tools.

• Workstations.

• The production line.

• The process itself.

• Gauges.

• Operators.

Again, just like in the design FMEA, the process team must use consensus for their decision but more important they must have the commitment of their management.

To facilitate this consensus and gain the commitment of their management, the team in both design and process FMEAs must set specific improvement goals. To do that, the leader of the team must use the following specific behaviors:

• Focus the team on result areas. The leader should stress the importance of goal-setting for focusing team efforts and discuss possible result areas the team may choose.

• Review existing trends, problem areas and goals. The leader should share with the team data that could shed light on the team's performance and indicate possible areas for improvement.

• Ask the group to identify possible areas for investigation. The leader should actively and constantly encourage complete participation from all team members. The more the participation, the more ideas will surface. Brainstorming, affinity charts and force-field analysis are some of the tools that can be used by the leader to facilitate an open discussion by all.

• If possible, ask the team to identify the goal. The leader, after a thorough discussion and perhaps ranking, should have the team agree on the selected goal. This will enhance the decision and will ensure commitment.

• Specify the goal. It is the leader's responsibility, once the goal has been set, to identify the appropriate measures, time and amount of improvement. As a general rule, cost is not considered at this stage. The cost is usually addressed as part of another analysis called value engineering.

In the final analysis, regardless at what level the FMEA is being performed, the intent is always the same: no failures on the system.

The timing of the process FMEA is initiated during the early planning stages of the process before machines, tooling, facilities, etc. are purchased. The process FMEA, just like the design FMEA is continually updated as the process becomes more clearly defined.

Forms

In this section the forms will not be discussed primarily because there are no standards available. Each organization has their own forms, except the automotive industry, which uses the Automotive Industry Action Group approved form. A typical FMEA form is shown in Figure 4.7.

Description	Failure Mode Analysis							Action Plan
Part name or process step & function	Potential Failure Mode	Potential Effect of Failure Mode	S	CLASS	Potential Cause of Failure Mode	O	RPN	Recommended Action & Responsibility	Target Finish Date	Actual Finish Date	Actions Taken	Remarks

Figure 4.7: Typical FMEA Body

FMEA Guidelines

Because most organizations use their own individualized guidelines for FMEA, a discussion of specific guidelines is impossible. In general, however, the guidelines are numerical values based on certain statistical distributions that allow us to prioritize the failures. They are usually in two forms: the qualitative and the quantitative. In the qualitative form, one bases the meaning on theoretical distributions such as normal, norm-log (skewed to the left) and discrete distributions for the occurrence, severity and detection respectively.

In the quantitative form, one uses actual statistical and/or reliability data from the processes. This actual data may be historical and/or current. In both cases, the numerical values are from 1 to 10 and they denote set probabilities from low to high.

Occurrence. Under occurrence we look at the frequency of the failure as a result of a specific cause. The ranking that we give to this occurrence has a meaning rather than a value. The higher the number, the more frequent the failure.

Severity. In severity we assess the seriousness of the effect of the potential failure mode to the customer. Severity applies to the effect and to the effect only. The ranking that we give is typically 1 to 10, with 1 usually representing a nuisance and 10 representing a very major non-compliance to government regulations or safety item.

Detection. In detection we assess the probability of a failure reaching the customer. The numbers 1 to 10 again represent meaning rather than value. The higher the number the more likely your current controls or design verification were unsuccessful in containing the failure within your organization. Therefore, the likelihood of your customer receiving a failure is increased.

A general complaint about these guidelines is frequently heard in relation to consensus. For example, how can a group of people agree on everything? The answer is that they cannot, but you can still use consensus to decide the issue at hand. For example, if the decision falls in an adjacent category, the decision should be averaged out. If, on the other hand, it falls in more than an adjacent category, you should stick to the consensus. A problem at this point may be that someone in the team may not understand the problem, or some of the assumptions may have been overlooked, or maybe the focus of the group has drifted.

If let us say one person says that the severity is 7 and someone else says it is 8 or 6. These numbers are adjacent to each other therefore the average of the numbers is sufficient. (7 + 8 = 15, 15/2 = 7.5 or rounded off to 8; 7 + 6 = 13. 13/2 = 6.5 or 7). On the other hand, if one person says that the severity is 7 and another 3, there is a major problem in understanding and/or assumptions. The difference cannot be averaged out. It must be discussed and agreed upon before moving on to a different item.

If no consensus can be reached with a reasonable discussion with all the team members, then traditional organizational development processes (group dynamic techniques) must be used to resolve the conflict. Under no circumstances should a mere agreement or majority be pushed through, so that an early completion may take place. All FMEAs are time-consuming and the participants, as well as their management, must be patient for the proper results.

Risk priority number (RPN)

This number is the product of the occurrence, severity and detection. The value should be used to rank order the concerns of the design and/or process. In themselves, all RPNs have no other value or meaning.

A threshold of pursuing failures is a RPN equal to, or greater than, 50 based on a 95 percent confidence. (Although there is nothing magical about 50, by convention many companies use 50 as a threshold, only because it is the traditional statistical confidence of choice.) We can identify this threshold by any statistical confidence. For example, say 99 percent of all failures must be addressed for a very critical design, what is our threshold? There are 1,000 points available (10 x 10 x 10) from occurrence, severity and detection, 99 percent of 1,000 is 990. So, anything equal to, or over, 10 as a RPN must be addressed. On the other hand, if we want a confidence of only 90 percent then, 90 percent of 1,000 is 900. So, anything equal to, or greater than 100 as a RPN must be addressed. This threshold is therefore organizationally dependent and can change, not only with the organization, but with the product and/or the customer.

If there are more than two failures with the same RPN, then we use severity, then detection, and finally occurrence as the order of priority. Severity is used first because it deals with the effects of the failure. Detection is used over the occurrence because it is customer dependent, which is more important than just the frequencies of the failure.

A very important exception to this rule is in the automotive industry, which does not accept any threshold. Rather, the risk is identified through severity first, criticality (severity ﾗ occurrence) second and last through the RPN.

Recommended action

When the failure modes have been rank ordered by RPN, corrective action should be first directed at the highest ranked concerns and critical items. The intent of any recommended action is to reduce the occurrence, detection and/or severity rankings. Severity will change only with changes in design, otherwise, more often than not, the reductions are expected in either occurrence and/or detection. If no actions are recommended for a specific cause, then this should be indicated. On the other hand, if causes are not mutually exclusive, a DOE recommendation is in order.

In all cases where the effect of an identified potential failure mode could be a hazard to manufacturing and assembly personnel, corrective actions should be taken to prevent the failure mode by eliminating or controlling the causes. Otherwise appropriate operator protection should be specified.

The need for taking specific, positive corrective actions with quantifiable benefits, recommending actions to other activities and following-up all recommendations cannot be overemphasized. A thoroughly thought-out and well-developed FMEA will be of limited value without positive and effective corrective actions. It is the responsibility of all affected activities to implement effective follow-up programs to address all recommendations.

Completing an FMEA

To complete an FMEA effectively, one must follow a systematic approach. The recommended approach is an eight-step method that facilitates the system, the design and process FMEAs (Stamatis, 1995).

1. Brainstorm. Try to identify in what direction you want to go. Is it design or process? What kind of problems are you having with a particular situation? Is the customer involved or are you pursuing continual improvement on your own? If the customer has identified specific failures, then your job is much easier, because you already have a direction. On the other hand, if you are trying on your own to brainstorm and/or to define the cause and effect of a problem, you may have a difficult time, since what you will end up with is your opinion and nothing else. It is therefore important when you brainstorm to have a team that has ownership of the problem.

2. Develop a process flow chart. Make sure everyone in the team is on the same wavelength. Does everyone understand the same problem? The process flowchart will focus the discussion. If nothing else, it will create a baseline of understanding for the problem at hand.

3. Prioritize. Once you understand the problem, the team must begin the analysis of the flowchart. What part is important? Where do we begin?

4. Begin data collection. Begin to collect data of the failures and start filling out the appropriate form.

5. Perform analysis. Focus on the data and perform the appropriate and applicable analysis. Here, you may want to use QFD, DOE, another FMEA, SPC and anything else that you, as a group, may think suitable.

6. Obtain results. Based on the analysis, you derive the results. Make sure the results are data driven!

7. Confirm, evaluate and measure. Once the results have been recorded, it is time to confirm, evaluate and measure success or failure. This evaluation takes the form of three basic questions:

   • Are we better off than before?

   • Are we worse off than before?

   • Are we the same as before?

8. Do it all over again. Regardless of how you answer step 7, you must pursue improvement all over again, because of the continual improvement philosophy. Your long-term goal is to completely eliminate all failures, and your short-term goal is to minimize your failures, if not eliminate them entirely. Of course, perseverance for those goals have to be taken into consideration in relation to the needs of the organization, cost, customer and competition.

Conclusion

As we have seen, the FMEA is a tool to identify the priority of failures in both design and process. It demands that a team be utilized to identify several points of view and a corrective action. Furthermore, it utilizes some qualitative and quantitative approaches to prioritize these failures.

Finally, it always focuses on the corrective action with the intent of eliminating failures from the design, system or the process. This focus is prioritized through an evaluation of the failure in terms of severity, occurrence and detection. Therefore, to have the best results, the FMEA is positioned very early in the quality planning agenda to prevent failures from occurring downstream in the system, design or process. The interrelationships are quite obvious.