FMEA Revisions - Recommended Actions to Actions Taken

sephodwyrm · Mar 28, 2014

Hi all, this is my first forum post and I'm sure that we have some experienced Quality Engineers here who can help answer this.

I'm working in an IC assembly and manufacturing firm, and I've been recently put in charge of reviewing the Process FMEAs of our company. From what I know, we've been doing this for several years but we end up with a lot of OFIs and Minors for the way we write our documents.

Having reviewed at about a dozen PFMEAs, things seem to going well until my manager decided that I give a refresher course on the FMEA methodology. A lot of points were raised on the way I review the FMEAs (I try to adhere to the 4th Edition AIAG Manual that we subscribe to, given that we're TS 16949 compliant):

My approach:
1. Recommend Actions for high risk causes, assign Responsibility and Target Date
2. Once the Target Date is up, review the actual actions implemented, and write it down in the Actions Taken, and re-score the S, O, D and RPN.
3. During our periodic annual reviews, we would again confirm the actions taken and update the S, O, D, and RPN and Current Controls (Preventive or Detection). In other words, for completed actions that have become standard practice, recommended actions, resp and target date, and actions taken will be erased (NONE for Rec. Actions).

Voice of my colleagues:
1. Same for 1, except we are to predict the RPN (some of our automotive clients from Germany demanded this).
2. Once the Target Date is up, review the actual actions implemented, write it down in the Actions Taken, and ERASE the Recommended Actions and Responsibility. Hence, the only the Actions Taken cell would have contents.
3. Same thing for the annual review.

I personally disagree with erasing the Recommended Actions when the actions have been taken, since I am certain that there are possibilities where actions taken do not match that of the Recommended Actions. Leaving the Rec. Actions would remind me (the reviewer or auditor) what our Mfg Engineers have proposed and compare it with what they did in future reviews. The samples I've seen in both the Ford FMEA Handbook and AIAG Manual also left the Recommended Actions column untouched when Actions have been taken.

Now I've been ganged up 4 against 1, and even my manager isn't so confident. I really need to clarify this with your help!

John Broomfield · Mar 28, 2014

sephodwyrm said:
Hi all, this is my first forum post and I'm sure that we have some experienced Quality Engineers here who can help answer this.

I'm working in an IC assembly and manufacturing firm, and I've been recently put in charge of reviewing the Process FMEAs of our company. From what I know, we've been doing this for several years but we end up with a lot of OFIs and Minors for the way we write our documents.

Having reviewed at about a dozen PFMEAs, things seem to going well until my manager decided that I give a refresher course on the FMEA methodology. A lot of points were raised on the way I review the FMEAs (I try to adhere to the 4th Edition AIAG Manual that we subscribe to, given that we're TS 16949 compliant):

My approach:
1. Recommend Actions for high risk causes, assign Responsibility and Target Date
2. Once the Target Date is up, review the actual actions implemented, and write it down in the Actions Taken, and re-score the S, O, D and RPN.
3. During our periodic annual reviews, we would again confirm the actions taken and update the S, O, D, and RPN and Current Controls (Preventive or Detection). In other words, for completed actions that have become standard practice, recommended actions, resp and target date, and actions taken will be erased (NONE for Rec. Actions).

Voice of my colleagues:
1. Same for 1, except we are to predict the RPN (some of our automotive clients from Germany demanded this).
2. Once the Target Date is up, review the actual actions implemented, write it down in the Actions Taken, and ERASE the Recommended Actions and Responsibility. Hence, the only the Actions Taken cell would have contents.
3. Same thing for the annual review.

I personally disagree with erasing the Recommended Actions when the actions have been taken, since I am certain that there are possibilities where actions taken do not match that of the Recommended Actions. Leaving the Rec. Actions would remind me (the reviewer or auditor) what our Mfg Engineers have proposed and compare it with what they did in future reviews. The samples I've seen in both the Ford FMEA Handbook and AIAG Manual also left the Recommended Actions column untouched when Actions have been taken.

Now I've been ganged up 4 against 1, and even my manager isn't so confident. I really need to clarify this with your help!

sephodwyrm,

Instead of recommending actions on the fly, issue a preventive action request in each case so a team can identify and remove the root causes of each high priority failure mode.

Then record the actions taken for each PAR and rerun the FMEA, repeat to manage the adverse risks down to acceptable levels.

That way you have two organizational learning tools at work for the benefit of customers and other stakeholders.

John

sephodwyrm · Mar 28, 2014

Thanks John for your input.

Our recommended actions are proposed by our Engineers, and our FMEA S, O, D and RPN scoring is also based upon Pareto Analysis of our top defects with PPM data. Our engineers on the floor would also conduct root cause analysis to propose the actions.

Now our issue right now is whether to ERASE the recommended actions when the actions have verified and the Actions Taken column filled in.

I personally intend to keep the Recommended Actions where they are right now since allows me (the designated reviewer from the quality department) to know what our engineers have proposed and verify it against what they actually did, and then we would put the improved (hopefully) S, O, D, and RPN scores in the respective places on the right hand side.

The AIAG Manual example keeps them there, but it would be great if I have a few more actual examples from other FMEA for manufacturing processes.

Chennaiite · Mar 28, 2014

sephodwyrm said:
Thanks John for your input.

Our recommended actions are proposed by our Engineers, and our FMEA S, O, D and RPN scoring is also based upon Pareto Analysis of our top defects with PPM data. Our engineers on the floor would also conduct root cause analysis to propose the actions.

Now our issue right now is whether to ERASE the recommended actions when the actions have verified and the Actions Taken column filled in.

I personally intend to keep the Recommended Actions where they are right now since allows me (the designated reviewer from the quality department) to know what our engineers have proposed and verify it against what they actually did, and then we would put the improved (hopefully) S, O, D, and RPN scores in the respective places on the right hand side.

The AIAG Manual example keeps them there, but it would be great if I have a few more actual examples from other FMEA for manufacturing processes.

As it goes, there is no 'One' right way, while there are so many wrong ways. To me, retaining the recommended actions makes sense for exactly the reason that you indicated. What is the justification on the other side of the argument?

I am pretty much sure, this cannot just be the only point of disagreement in FMEA within your team. Keep bringing up more.

John Broomfield · Mar 29, 2014

sephodwyrm,

Yes, accepting recommendations from the Engineers seems faster.

But, as you do not invoke preventive action, do the root causes of the potential failure modes remain in the system?

I see no evidence of the design processes being improved by your FMEAs. Perhaps you are running Lesson Learned sessions to help drive improvements?

John

sephodwyrm · Mar 30, 2014

From John:

do the root causes of the potential failure modes remain in the system?

I (like our Customers), would ask Engineers from the floor to provide actual performance after the actions have been taken. This would allow us to see if the issue has been successfully resolved.

But as you've mentioned, our FMEA is driven by actual problems happening on the floor. There's no evidence showing that it is capable of preventing errors before they happen (hence, it is not meeting the desired objective of the FMEA methodology).

For example, our Engineers on the floor still wouldn't consider updating FMEA a top priority when they improve the process. As a result, the Process FMEAs may have missing or redundant steps when our product is released for mass production. And this would only be highlighted when the Customer reviews our FMEA documents. This is also why I've been brought on to the job.

It certainly does not help when the QA department disagrees with each other over things like whether to keep the content of Recommended Actions after having verified the Actions Taken. >.<

FMEA Revisions - Recommended Actions to Actions Taken

sephodwyrm

John Broomfield

sephodwyrm

Chennaiite

Never-say-die

John Broomfield

sephodwyrm

Similar threads