Talk:Failure mode and effects analysis

The article orginally stated that "D" is the ability to detect. That implies to me that 10 is a high ability. This does not make sense.

I have updated this to state inability, which makes more sense to me.

--David n m bond 00:18, 6 October 2005 (UTC)

add a table

usefull in the overview can be a typical schematic FMEA which is used in industrie:

Part |Function|Potential Failure Mode|Potential effects of failure| SEVERITY|Potential causes of..

---

name |function| something | bang | point 1-10 | smoke...

..failure|OCCURRENCE|How will the potential failure be detected?|DETECTION|RPN|Actions|

---

          | point1-10  |   smell    |                           | point 1-10  |S*O*D| do this|

this is the key FMEA of a system, this has to be performed on all parts... 130.161.165.66 13:48, 22 February 2006 (UTC)

FMEA and fault tree

With experience from several products for the aviation industry: I would object to the statement that FMEA is a fault tree method, which is the first sentence in this article. FMEA is usually tables, and does not neccessarily completely cover a system to component and lowest level function level -while a fault tree (at least in e.g. ARP4761) usually does. A tree is a tree, a table is a table and system blocks are more typical in the tables -while lower-level stuff are more typical in trees. Any other opinions? Nordby73 20:53, 20 April 2006 (UTC)

Another source to back up my statements above is NUREG-0492. -And yes, I also have a little experience with FMEA and ISO9000. Nordby73 21:09, 20 April 2006 (UTC)

As there was no commendts to this, I made a change to see if it sticks. Nordby73 21:25, 3 May 2006 (UTC)

Why is there a load of text in what appears to be Bulgarian at the bottom of this page? Nfmccourt 20:49, 7 May 2007 (UTC)

I agree with Nordby73, but note that FTA and FMEA discussions are now in the 'disadvantages' section. FMEA diadavantages include: 1. It really only deals with single failures - FTA is complementary as it is able to model multiple failures 2. FMEAs should be written in line with a stated 'operating context'. This is often overlooked and does not form part of the format of how FMEAs are laid out. Why do we need an operation context definition, because many assets or equipments may be used in completely different ways, in different environments, which have a high influence on the predominance of failure modes. 3. The relationships in the FMEA between functions, functional failures and failure modes are 'many to many', the FMEA structure is essentially a 'one to many', because it has to be laid out as a table on a piece of paper. Therefore the format does not represent the true state of the relationship between the attributes within a FMEA Charlie —Preceding unsigned comment added by 90.195.213.115 (talk) 16:46, 24 August 2008 (UTC)

External links

I've removed the following external links per WP:EL. If these links were used as sources for text in this article, please see Wikipedia:Footnotes to find out how to reference these sources for WP:VERIFY. --SueHay 03:56, 3 June 2007 (UTC)

• Lean Six Sigma Tools & Tutorials - "Lean6" the tool for FMEA
• International Automotive Task Force - IATF publications, including the FMEA reference manual
• FMEA Info Centre
• PlanTech Incorporated
• Quality Plus FMEA Software
• FMEA and FMECA Information
• iSixSigma FMEA page
• FMEA/FMECA Reliability forum and FAQ
• FMEA Training
• FMEA Consulting & More
• design and process fmea software- TDC Software
• APIS IQ-FMEA Software
• software and services, information - Knowllence

---

Cited External Link Address Changed / Source Incorrectly Identified

As my company's webmaster, I was looking at a Google report of incoming links to our website and I noticed that this article had a link to one of our pages ("History of FMEA"). Our website was recently redesigned from the ground up and as a result many of the page or directory names have changed. The incoming link from this article referred to an old page on our site and had become a dead link (http://www.quality-one.com/services/fmeahistory.cfm). I changed the address of the link on the FMEA wiki article to the new address (http://www.quality-one.com/services/fmea.php). The information from our website that is cited in this wiki article is still on the new page so the inclusion of this citation should still be relevant. Also, the name of our company was incorrectly cited. The author(s) had identified us as the Quality Associate Institute when really our name is Quality Associates International, so I fixed this as well.

I would also like to say hello to everybody as this is my very first Wikipedia edit! I have been a loyal reader from the start but never considered editing an article until I saw these two items and decided to take the plunge. Hi all!!!
-- Jdvernier 13:22, 6 October 2007 (UTC)

Failure Modes

I'm puzzled by the weird addition made recently to the introductory paragraph, suggesting that mode is a "reference to the alert which signals the failure.This is similar to an Andon. An example for a mode would include playing particular theme music for a specific failure to stimulate required correction."

At best this looks like a total misunderstanding of FMEA, and at worst, possibly vandalism as an excuse to promote the Andon article.

A failure "mode" is essentially the mechanism by which the failure is initiated, nothing to do with playing theme music.

Comments anyone? LyallDNZ 09:14, 21 October 2007 (UTC)

BTW the Wikipedia entry for "Failure Mode" is really: "Failure modes are characterizations of the ways a product or process can fail." LyallDNZ 10:12, 21 October 2007 (UTC)

I made that addition. I'll provide the citation tonight. If your version is correct then FMEA is nothing more than Fishbone diagrams with weighted branches.

Updated the primary use of the phrase Failure Mode with the official definition within Logistics: Principles and Applications, J. W. Langford, McGraw Hill, 1995, pp 48.

I currently hold a Masters degree in Industrial Engineering with a focus on Logistics. Although the current business culture is applying FMEA this is a logistical topic and should be handled as such. Please do not delete any edits to WIKI without discussion. Much work can go into the process and to walk into a page, delete what someone has written is beyond reproach. We can discuss the definition of "Manner".

To confront the topic I have to initiate a discussion to decipher the following found within the citation. I would ask that everyone interested help to clarify and distinguish the following so that the topic of FMEA can progress.

Failure detection method. "A description of the methods by which occurence of the failure mode is detected by the operator should be recorded. The failure detection means, such as visual or audible warning devices, sensing instrumentation, other indications, or none, should be identified."

Failure mode. "The manner by which a failure is observed; it generally describes the way the failure occurs and its impact on equipment operation."

Now, these are both direct quotes. I believe the distinguishing words include:

1. manner
2. method
3. means

If these are clarified I think the page will progress more smoothly. My personnal belief is that the manner consists of a method which requires a means. I'm open for interpretation and expert input.

This is I think the only way to resolve the conflict. —Preceding unsigned comment added by CWDURAND (talk • contribs) 02:44, 7 November 2007 (UTC)

In its most general form a failure mode is essentially the mechanism by which a failure is initiated. The ways in which failure modes are observed may be of interest, but how it's observed does not necessarily characterise the mechanism (e.g. corrosion, etc). It was in that context I was not supportive of the addition of the "Andon" references, which didn't help the understanding of this article. LyallDNZ 12:03, 8 November 2007 (UTC)

I'm starting to agree with that determination. I have meditated on it for some time now. The how is method I think. And I would, at this point, assign to the means devices or signals. It is still subtle in all three and I hope to establish that the mode is some sort of word phrase recognized by personnel. Thanks for the input. CWDURAND. —Preceding unsigned comment added by 68.89.254.242 (talk) 18:52, 12 November 2007 (UTC)

Failure Detection Method

This is an academic discussion of the 3 distinct terms employed and described by FMEA. In particular how possibly could one identify the Failure detection methods may help to distinguish the term?

Consider an Ishikawa (cause and effect) diagram. It contains about 5-6 branches, one of which is a Method, and all of which possibly contribute to the Effect. This means that there is a list of methods all tied to a particular effect. In addition there is a list of personnel or manpower associated with the Effect. Since we are trying to describe how these methods detect a failure we can then take the set of methods and fully detail how (if at all) they identify the failure. It will most likely follow that there is a series of Effects having similar methods on the Methods branch. I assert now that the how is the Failure detection means, to which Langford refers. CWDURAND

Failure Mode

The mode is the culprit here. According to the definition it describes the way and the impact on equipment. So what can we use for a Failure mode? Perhaps a phrase such as "Containment Failure on number 2 compactor from corrosion". Isn't this just a combination of cause and effect from the fishbone diagram? And so every mode requires a method of detection and a means of displaying. For example how to we know that "Containment Failure on number 2 compactor from corrosion" --->the Failure mode occurred? Well {{we use a pressure gauge -->method} that turns on a {flashing light-->means} on our monitor} --> Failure detection method.

I would like to think of other modes in this light but inevitably I am confounded by the subtle distinctions between the 3 terms. At some point they are all the same and at another they are all interweaved like the parts of a leg. It is unlikely that Langley was confused on the matter and made effort to maintain the distinction in his work. CWDURAND

Likelihood and probability

They are two different things. Please clarify the respective bullet point. --Sigmundur 21:05, 29 October 2007 (UTC)

I also had these as 2 different things with a link to both. It is apparent that the Wiki article has been hijacked by 1 person with 1 persons view of the method.

CWDurand —Preceding unsigned comment added by CWDURAND (talk • contribs) 13:17, 5 November 2007 (UTC)

History

I'm interested in this history. It seems like it's related to the modern Damage Control and the Damage Control Information Display System (DCIDS) used by the Navy. To see the relation look up the term Interfaces. I would love to see a link here that shows a pure link in the history. If anyone is into historical contexts and progression please chime in. —Preceding unsigned comment added by 68.12.170.28 (talk) 02:32, 6 November 2007 (UTC)

Added a link

Hi fellow Wikipedians,

Our company (Quality Associates International) is cited in this article under the "History of FMEA" section and a link to our webpage appears in the "notes" section.

We recently developed a short, free web based training course that describes what an FMEA is and what the individual columns are used for in the FMEA form. I added a link to this presentation in the "references" section of the FMEA article.

I did not add this link as an ad for our company or for Google purposes, but because we were already cited in the original article and I feel that our free presentation adds to the discussion that begins in this article.

John —Preceding unsigned comment added by Jdvernier (talk • contribs) 14:48, 25 March 2008 (UTC)

Zoe Murphy keeps vandalising this page, watch out fo

I love this article.

This is a classic case where the "references needed" tag at the beginning degrades the quality. The article is incredibly useful, but the tag adds an appearance of invalidity while expert discussion actually validates the material quite well. The discussion even introduces debatable issues which adds even more to validity.

The often mis-ballyhooed "verifiability" be damned. Verifiability ought to be subordinate to VALIDITY. Wikipedia chooses the wrong path when they allow so many misapplications of that awful "verifiability not truth" maxim. Besides, verifiability is attainable by means other than the over-vaunted inline citations. In this case the article is verifiable by way of visibility/modify-ability by numerous actual experts, by actual modification by them, and by their entries on the discussion page.

72.93.169.246 (talk) 20:36, 15 October 2009 (UTC)

Example FMEA Worksheet, the CRIT column

What is the column headed "CRIT" with "N" in the content. The other columns are explained in the text or self-explanatory, but this one is neither unless I missed something obvious.

PKJ 130.228.251.10 (talk) 08:00, 30 November 2009 (UTC)

Implementation

In the Implementation section, the purpose of FMEA is currently stated as:

The purpose of the FMEA is to take actions to prevent or reduce the likelyhood [sic] of failures, starting with the highest-priority ones. It may be used to evaluate risk management priorities for mitigating known threat vulnerabilities. FMEA helps select remedial actions that reduce cumulative impacts of life-cycle consequences (risks) from a systems failure (fault).

Without intending to argue semantics, I think this might be better described as the goal (use or result), while the purpose (intended benefit) of FMEA is to reduce the cost of product development by providing a systematic method of uncovering and addressing, as early as possible, those potential failures that the design team should "know" about, or be able to anticipate, from prior experience, thereby avoiding more costly redesigns (i.e. rework) later in the development process.

I realize that this stands in stark contrast to how FMEA are often completed: after the design is finished, just to check off some documentation requirement.

Anyone have an objection to adding this version of the purpose to the introduction paragraph, and updating the Implementation section to read "the goal of the FMEA…" instead of "the purpose of the FMEA…?" Tom Hopper 18:39, 17 April 2010 (UTC) —Preceding unsigned comment added by Thopper (talk • contribs)

___________________________

Tom, how would you consider this in the context of process FMEA's, where usually an already-existing process is being explored? --80.152.162.81 (talk) 09:30, 30 April 2010 (UTC)

Information Quality of FMEA!

In my own work with FMEA, I have discovered that FMEA numbers are sometimes "picked from the dart board", so to speak they are even less accurate than gut feelings, therefore invalidating the entire purpose of the FMEA.

The same goes for the descriptive columns which may just be filled in by someone who might just think they know what is going on, leading data-driven improvement astrasy from the beginning.

Personally, I have gone over to add an extra "information quality" column which again I rank from 1-10, where 1 is "proven data" and 10 is "random guessing". I then factor in that number into the total RPN, because risks we don't really know much about are a bigger threat towards improvement projects than risks that we understand well.

--80.152.162.81 (talk) 09:27, 30 April 2010 (UTC) (Michael)

Types of FMEA

Why so many types of FMEA? Why do we need all those different types of FMEA when they have the same type of content?

In the end, there are processes and outputs. An FMEA is fundamentally different whether the purpose is exploring the process itself or exploring the outputs of a given process, which are either tangible or intangible products.

• What is a Design? Either the design process - or a product, which is either the target's specification or the end product itself.
• What is a Concept? Either the concept development process - or a product, a concept specification.
• What is equipment? I'd say they are products, though typically not produced by their user.
• What is a service? It is typically the process of performing some actions - but may also be a product, the result of servicing.
• What is a system? It is either the processes existing within a structure, or a product - the structure itself.
• What is Software? In this context, we are either talking about the SDLC process - or the deliverable product!

This is a challenge to all the experts out there, but I say that these two types of FMEA (process + product) are completely sufficient, and every other type of FMEA is a variant of one or both of the above, simply with different labels on the table.

I boldly put up the statement that all those types of FMEA are just fads created by people who claim to have invented the wheel when all they did was put a different label on something that existed a long time ago.

Prove me wrong!

--80.152.162.81 (talk) 09:50, 30 April 2010 (UTC) (Michael)

Risk priority number calculation

RPN = S × (O + D) since the inability of checking system increase the possibility of occurance —Preceding unsigned comment added by 119.167.58.241 (talk) 02:05, 31 May 2010 (UTC)

Overdesigned managerial nonsense

The following is opinion and you can freely remove it. I've applied FMEA as a result of adopting CMMi and it's probably the least effective and most counterproductive technique I've ever seen in business analysis. Invariably, the technique results in endless meetings with people who only vaguely have an idea of things that may go wrong, producing a ridiculously long worksheet with risks and numbers. Next, when something goes wrong, nobody ever cares about the document to draw back to the identified action.

Yes, every technique should be correctly applied, but it is my experience and believe that FMEA holds ineffectiveness in its heart, by focussing on quantification (with multiplied ordinals becoming utterly meaningless), artificial thresholds and overdesigned table sheets. FMEA participants get all caught up in applying the details of the technique, that the purpose is completely forgotten about. I think FMEA would benefit of a more qualitiative, dynamic and common sensical approach. This is experience from one company, in the knowledge industry.

It is not that I'm a kind of rebel against all business analysis techniques. I found great value in agile processes, while they can also be misapplied and carry some inherent risks. Also, for my own businesses, I find a light weight SWOT analysis often helpful and I also have drawn some techniques from the game of Go. 194.78.35.195 (talk) 08:06, 19 October 2010 (UTC)