Archive for July, 2008

Actions on FMEA

Tuesday, July 29th, 2008

The sequence of when to take an action is illustrated on our website. I have imported the picture below to explain to all of those who have asked about the order:

Can you determine the order of need for change in the following three examples?

FMEA and the Control Plan

  • Severity (5), Occurrence (4), Detection (2) = 40
  • Severity (9), Occurrence (2), Detection (2) = 36
  • Severity (8), Occurrence (1), Detection (8) = 64

The correct order for action is #2, #1, #3. To find out why, please contact us or sign up for our value driven training on FMEA.

The order is Severity First  (item 2) (9 and 10) without any occurrence or RPN - the purpose for this is to find a design or process change that eliminates the Failure Mode. This is very difficult, but possible; an example is Tire Blowout, where the mitigating action is to put a “run flat” tire on the car/truck.

Item 1 is next because of the Occurrence linked to the 5 in severity. Reduction in Occurrence is the second responsibility of the design or process team when looking at an FMEA. The RPN is  not relevent. Poka Yoke, or reduction in variation or conversely tolerance relief will reduce the Occurrence. This relates to error proofing and if it is not feasible then capability improvement (CP index > or = to 1.67)

Finally the detection number is addressed, but generally only when a design or process has been determined to have a high enough occurrence and a high enough severity to be concerned about the risk. Target should be 3 or below.

If there any specific questions, just email me and I will address them in a future blog post.

 Lee

8D at Hertz

Thursday, July 24th, 2008

I was returning a car the other day at Hertz at the Detroit airport. And lo and behold, on the wall upstairs were large poster sized examples of how to do an 8D. 8D, as you may know, is a great way to get to a root cause of a problem by working it from the Symptom to the Problem Statement using the “5 why” process. From there the statement is converted to a problem description using an IS/IS NOT analysis. The IS/IS NOT gathers facts about the what, where, when and How Big. This analysis is more about finding out what the problem is not as opposed to looking for the root cause initially.

The root cause is only agreed upon after developing theories based on the facts and the differences and changes that have taken place. Change is usually where the problem is. The fact that change takes place without proper verification and validation makes the 8D process very effective. The team does not have to be Six Sigma experts to use it effectively, but it ties in nicely with six sigma process.

I hope Hertz uses the process effectively and I wish them good luck and applaud the effort to find the root cause and fix it at that level.

8D and the FMEA

Monday, July 7th, 2008

Just another note on the 8D relationship to the FMEA, I am sitting in a facilitation of the Lean FMEA approach and one of the matrix items is the 8D inputs. The past failures is one item in the 3 cases for doing an FMEA.

The  FMEA and more appropriately the Lean design Matrix for the FMEA family should always be present for the 8D development. The brainstormed causes already present in the FMEA can shorten the root cause activity by at least one and possibly two layers of the “WHY” discussions.

Keep in mind that the FMEA will be updated at D7 (prevention) or if done most efficiently in real time at D2 and D4 as the 8D progresses.

Lee

FMEA handbook Fourth Edition (AIAG)

Monday, July 7th, 2008

Just got an oppurtunity to look over the new handbook and am very pleased with the outcome. The inclusion of prework documents and clarification in the RPN useage (to not to for actions), clarification on Design FMEA detection ratings and some improvement in Severity explanation ( groups like 5 and 6, 7 and 8, and 9 and 10 will make it easier to select Severity initially.)

The most interesting item is the new forms in the back I am especially interested in the Form that had the design or process controls prevention side by side with the cause and then the Occurrence column. This is the most logical of all. The prevention controls impact occurrence so it should appear before the occurrence column as in the new formats.

Over all a good job and an excellent update. It appears the team at AIAG is doing the right thing for the future of FMEA. Bravo…

Lee