FMEA Recommended Action

After Recommended Action in FMEA was completely done and the new RPN was accessed, should the "Recommended Action" be moved to be in the "Current Control" column or it should be still remain in the Recommended Action column.

I got different opinion from various customer audit and I do not know which one is the accurate comment.
Any theory in written that I can make reference when I discuss with customer?

 

I have not found anything in AIAG FMEA manual, so it is up to organization.
Personally I would move it to "Current control" during next scheduled/unscheduled review or revision of PFMEA.

 

I have done for both but there is different customer has different opinion, I am not able to serve such different opinion at the same time.
I just need to settle this by having something for reference that can explain to customer to be clear that what I do is correct.

 

Good question @Pongsakorn ;
My professional experience has caused me to not be a fan of the "recommended action" column. I see this as AIAG's attempt to redundantly capture change point control within the PFMEA itself and imply that organizations have no change point/document control system (to which I ask, who reviewed the change?, who reviewed the risks associated with the change?, who was involved in the change?, who approved the change? what project management records exist associated with the change, etc...etc...) I would much rather see the revision activity captured in a change control data base or other system specific to the most recent revision of the document.

Alas, I digress and rant...please forgive me. Regardless of my opinions, the AIAG template does indeed include the dreaded fruitless "recommended action" column.

My experience has resulted in the following professional opinion...
I council companies to put the change activity (if a change point control data base/system exists, I recommend simply putting the CPC number [discrete identifier] in this column and not the redundantly repeat the actual details) into the "recommended changes" column and leave it there, UNTIL that particular process/function is revised again. The next time that particular process/function is revised I then recommend moving the previous "recommended changes" into the "current controls" column and then identify the next change in the "recommended action" column.

Hope this helps.

Be well.

 

John,
Thanks for sharing your experience. I did both way and change back and forth to follow customer comment.
I am tired now to depend on customer that has different opinion and I have no reference to stop customers to request base on their own opinion.
I actually need AIAG to clarify this and I may send my concern to AIAG.

 

I agree with John. Let's consider the part print instead. If you have a design at rev B and find out there's problems, you of course modify the design and release rev C. But you don't LEAVE the rev B stuff on the print, you REPLACE it. (You may leave a trail, but the print itself is replaced).

The purpose of this is to avoid confusion. You don't want to risk building the part the wrong way.

The question becomes - why would you NOT do this with the PFMEA? And for what it's worth, the AIAG books say that the PFD, PFMEA and CP in them are examples, not requirements. But ... it's sometimes easier to do what everyone else does than to do things better. Don't get me started on the process flow diagram. I cannot stand that example. It's redundant and unclear.

 

If page 64 of the 4th edition of the AIAG FMEA Manual specifies below:



What will be your take on this?

 

My take:

It's an excellent thing to do. HOW you are going to do this - that's a different story. The biggest problem with FMEA being a living document that I have seen is the "read across" problem. You're making gizmos and widgets and you're using the similar process for both - say you are a CNC machining house. The tools and steps may be different, but the overall process is the same - machining.

You get a quality spill on your gizmo line and you learn an important thing from the root cause. Let's say you learn that you need to run coolant to control your hole sizes (excuse the simplicity of the example).

At this point, what you SHOULD do is a proper read across. You should check your widget line with this new information (we need coolant) and see if it applies there.

That's not typically done. What's worse - what if the widget line goes to another customer? Now you have to PPAP to them, too, you're changing your PFMEA .... And, it's absolutely the RIGHT thing to do. But ... our customers have trained us to avoid changes, not do the right thing. You broach a PPAP to the customer in a bad mood and they may say "no changes, we are too busy to approve your PPAP." OR they may want a cost savings, your internal scrap rate should go down. So you get inadvertently trained by your customers to isolate your processes from one another. A conflicting stance to true read across efforts.

If I could start over with this FMEA stuff, what I would do is:

1) Set up a "master" FMEA that had each process you performed. In a CNC Machine shop this would look like:
Drilling - Vertical Axis
Drilling - Horizontal Axis
Reaming - Vertical Axis
etc....
You could say "Drilling". But if horizontal vs vertical drilling behaved differently, you'd want to distinguish them.

2) Do your SEV, OCC, DET on your MASTER FMEA.

3) Now, build you part FMEAs by linking to your master. You could do this in Excel with Master Codes and a VLOOKUP command in your individual ones.

In this way, if you learn something about one of your process, changing your master would cascade update all your follow on FMEAs. And in this way, building one for a new part would be easy. You then take the time you would waste on the paperwork and spend it coming up with ways to reduce occurrence or improve detection.

If you could get away with them being functional, that would be even better. If my gizmo has 3 holes of different sizes and my widget has 8 holes, again, different, by the rules I need a line item for each of these operations. But an FMEA is about risk. And the risk is the same. (You'd have to consider size, you may need small, med, large holes). But the point is - why list EACH one? That's an opportunity for a mistake. Why not: This part using drilling, here's how we mitigate drilling risk. But THIS part uses drilling and reaming, so here's the additional reaming information.

Why regurgitate the same statements for the 6 mm hole AND the 8 mm hole?

Because our customer wants us to. And that demand drives it into being a pencil whipping exercise instead of it's true intent - a plan to mitigate risk.

My take? They're a fantastic concept that is miserably executed in the real world driven by the customers lack of understanding.