Too much info in DFMEA 1

[hygear]

It is my understanding that the primary purpose of a DFMEA is to act as a checklist of items to consider/check when designing and testing. This is the way I have always utilized a DFMEA, but my current employer wants to use it to capture design history. Because of this, our DFMEA template has expanded to include a "Results" columns for Current Design Controls and columns to link to test reports, problem reports, and various other information. Basically, it is completely out of hand and a pain in the ass to manage now.

My question is how do the rest of you manage this sort of information? It is essentially the results of conducting all the items in the DFMEA, but I don't believe it should be in the main DFMEA form. Any thoughts?

 

[MintJulep]

my current employer wants to

That sort of sums it up doesn't it?

 

[TheTick]

People like to cram information on to familiar documents. They don't care what the purpose of the document is, they just like to find everything in one place. Happens with drawings all the time.

 

[HPost]

We(major UK Automotive OEM) use a foundation DFMEA that captures all of the lessons learnt from previous projects. That document serves as basis for all new projects that are scored on their own merits.

If your employer wants to do it another way, it's their prerogative.

HPost CEng MIMechE

 

[ivymike]

our DFMEA template has expanded to include a "Results" columns for Current Design Controls and columns to link to test reports, problem reports, and various other information

That's about where we were 10 years ago ... since then we have developed in-house software to help keep all the info "attached" correctly. Works pretty well.

 

[dgallup]

A project I've been working on recently incorporated a DFR (Design for Reliability) document in addition to the DFMEA. That is where we put all the associated testing and progress tracking throughout the development program. It was new to me but I found it very useful.

----------------------------------------

The Help for this program was created in Windows Help format, which depends on a feature that isn't included in this version of Windows.

 

[MikeHalloran]

On a slightly related note, if you are a manufacturer subject to FDA regulation, you are required to maintain a database (of some sort) with all the details of what exactly went wrong with all of the products you have ever made.

... and you are required to test each new product to verify that the product has a defense against each and every failure mode of each and every past product, and you have to maintain documentation of each and every test and assumption.

This has been going on since before DFMEA had a name, and you don't have to use any particular form or any particular documentation system, but you do have to have a documented documentation system.

But the point that's important to you is that you don't get to dream up your own checklist. You do that, sure, but in addition to that your checklists also have to cover your entire history. I think that's where your boss is going.

None of this stuff is infallible, of course, and the FDA acknowledges that. If you make a new mistake, you just deal with the consequences and move on.

If you repeat an OLD mistake, the FDA will shut you down for six or more months while an army of lawyers goes over all of your documentation in excruciating detail and interviews, okay cross examines, your entire workforce. You won't soon forget an experience like that.





Mike Halloran
Pembroke Pines, FL, USA

 

[Lou Scannon]

There is a DFMEA manual developed and maintained by a consortium of north american auto manufacturers {AIAG?] that defines the purpose and methodology of DFMEA within that industry. Based on my understanding of the latest edition of that manual to which I had exposure, there is little place in the DFMEA process for what your "current employer wants".
At the end of the day, the DFMEA is a CYA document. The first goal is to be able honestly to say, that you conducted a DFMEA, and that you acted on the high RPN items, successfully lowering them. What constitutes a "high" RPN and "successfully lowering" is highly arbitrary and company-specific. The point is that a sincere, informed, and fruitful effort was made.
DFMEAs are generally not meant for consumption outside one's own company, although sometimes they are shown (not given) to customers. Typically the customer does not expect to be given a copy, and probably does not want one. They just want to be able to document on their side that they did their due diligence to ensure that their supplier did his due diligence.
So from the CYA point of view, you need to be able to attest that, yes, you conducted a DFMEA, and [hopefully] that you know roughly what a DFMEA is and what it entails.
The second goal is to actually improve the design, from a robustness and safety point of view, which is a natural outcome of going through the process with some awareness and sincerity.

"Schiefgehen will, was schiefgehen kann" - das Murphygesetz

 

[TheTick]

The basic problem is that your employer wants a single document to do the job of what should me many documents in a controlled system.