The Quality Blog

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?

• 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

Back in the USA and teaching at one of the Japanese automaker’s design facilities in the Detroit Area today. The topic came up as to how the Test plan can be affected by the Design FMEA activity.

My response to the question was as follows:

One of the Design FMEA’s jobs is to determine that the testing and prevention methods are adequate to either prevent a failure mode and cause mechanism from happening, (Prevention affects Occurrence) and to determine if a test or groups of tests will excite a failure mode either directly or through a cause which was deemed probable during the analysis (This is the Detection number) A detection ranking is assigned to each test and the lowest number is placed in the Detection column. Here is where the process goes wrong.

The purpose of the the detection ranking is to give an honest assessment of the tests to determine if they are harsh enough and have the causes which have high Occurrence represented within it. If the test does not consider a cause that has a high Occurrence then the ranking should climb. A ranking greater than 3 (my opinion not to standard) then an action should be considered to improve the test to make it more representative of how the team invisions a failure. The Detection action (with no regard to RPN) is captured and given a timing and responsibility for follow-up. The RPN has nothing to do with determining if a test improvement is necessary.

The RPN is assigned to the action (not the other way around) and the resulting RPN after the action is taken is compared to the original for overall relative risk improvement. In fact the RPN is the only way to tell (numerically) if actions were successful in general. The RPN has each element where actions can be taken so it represents a good overall risk reduction comparison. The key word is comparison. OOOPs getting off topic here. Back to testing.

The test improvements are intended to excite the failure mode with the high occurrence causes present in order to fail the part or system, etc… On the other side the design engineer, knowing a risk exists takes an action to prevent a failure so the two opposing forces are equaled. What do I mean by this? The test guys are trying to fail the part with excitation (within specification limits of course) and the product design guys are trying to prevent the failure by strengthening the area (cause) that was determined to have risk. So try as they might, the test guys will experience a pass not a failure.

Remember we should not learn anything through this test  plan as we are trying to verify that the design is acceptable. The design verification should be confirmed or backed up by the test after having first gained confidence in the design through prevention means (standards, FEA, Best practices and Product DNA) 

It amazes me as to the usefulness of FMEA across many industries. I am sitting in the lobby of a major defense contractor for the second day of a FMEA risk mitigation event for the Hummer replacement. The new designs are intended to reduce the effectiveness of IED’s or Improvised Explosive Devices. The FMEA is being used to reduce the probability of failure of various systems as they contribute to the potential failure. In other words a systems approach. Some systems have greater responsibility to deliver protection and survivability than others, but all are responsible for some of the functional requirement.

The outputs of FMEA in these examples are extracted from the FMEA and managed through a risk management method embedded within the project management system. This is a great way to get the value from FMEA and then populate the Design Reviews with the actions, responsibility and timing. Follow-up is most likely to occur in these cases. This is a major flaw with using FMEA alone as some folks simply forget to review the actions in a timely way.

Always remember to update the FMEA after the actions have been taken as this assures future considerations of the actions taken in new FMEA development.

Just a note while on the road in New York about prevention and detection controls. Some confusion exists about these two very distinct types of controls.

Prevention controls include things that help you do it right the first time without having to physically test. These include FEA, Modeling technology, Product DNA, and Standards that can be followed. Note that FEA in a iterative design process as opposed to using a the design process. These Type 1 controls affect the Occurrence number and are not to be evaluated for the Detection ranking.

Detection controls or type 2 controls are used to detect design weakness and potential errors. Tests and formal protocols, physical representations of parts, past test results etc… each is rated independantly of each other for each cause and failure mode. the lowest value is used for the detection ranking to be included in the FMEA. More on Process FMEA in my next post

Working in China this week. The FMEA process is just starting to take off in China. The concept of FMEA is always somewhat hard to start with. The design engineers here still struggle with the same issues that design communities everywhere else struggle with. Why do this? I am a good design engineer. I won’t make mistakes.

The message here is the same everywhere: The design engineer should never do their own Design FMEA. Think about it. What will they find? And if they find something, why did they not find it before the FMEA? The design engineer should be doing the FMEA in his or her head as the design process progresses. The Design FMEA is done by a team of people including other design personnel that provide the questions and drive for doing a good job. The design engineer responsible for the design is required for two reasons:

1) They are in the best position to know when the FMEA should be performed: roughly 50% of design completion time or earlier.

2) They need to provide the team with the philosophy of the design direction and choices made.

They must never drive the FMEA as the result will follow the the design engineers lead, and that would diminish the value of FMEA for uncovering possible failure modes, their causes and mechanisms and the actions that will be suggested to make the design better.

Your comments are always welcome!

Just a note while waiting for an airplane to Beijing in Kuala Lumpur. I have been doing alot of work with customers on Special Characteristics lately. One confusing point that requires clarification: what makes a characteristic Special? Is it how important it is? There are several good definitions and it is my opinion several of them work. One such definition is related to control of Variation and if the customer can see value or improvement with this variation minimized. That one is OK, but is this not true of all variation?

I like to suggest it is those characteristics that are at risk of not delivering something important. My example would be:

Is your heart rate important for your survival? Sure it is. Is it special? I think not. Why you might ask? I think it is in control and stable for most of us. Most of us do not get up in the morning and plot a control chart or calculate Cpk on our heart rate. If we are normal (fitting the normal distribution) our heart rate would have a Cpk greater than 2 for sure for what is expected to be normal. However if I were to try to lose 40 pounds by going on a treadmill or walking program, the need to monitor increases due to the increased risk that I just put myself under. A diabetic must monitor and control blood sugar, so that is a special characteristic.

How do I know there may be special characteristics? Design FMEA gives us the best hope of finding them if they exist. When done correctly the DFMEA will give us a clue, but will not be explicit as to where the characteristics are. When should I look for them? Before the design is finished for sure, but also including the manufacturing and assembly peoples input for mitigating the risk by making changes to the Design, Process or both. Error Proofing is our first mitigation obligation, Improved stability and capability the second, and finally special control strategies when risk has not been reduced to an acceptable level. Want to know more? Give us a call at (248) 280-4800 and ask for Michelle.

What do I mean by this statement? Using RPN thresholds to take actions is not the intent of the FMEA tool. This is according to AIAG, SAE and other authorities. There are three paths that one takes when developing an FMEA:

1. Severity first when 9 or 10
   • Take action to error proof to eliminate the Failure Mode
2. High Occurrence (4 or higher) when linked to higher severity 5 or more
   • Take action to error proof the cause or make it more capable
3. Detection number too high greater than 3 when a Cause and Failure Mode combination indicates testing or inspection for a probable cause is not adequate.
   • Take action to improve testing (DFMEA) or Inspection methods (PFMEA)

RPN’s are then assigned to the Actions from the three above action drivers. The new RPN calculated after the action is compared to the RPN assigned to the action to see what the delta or difference is. Improvement is expected in the category that the action was developed.

If there are any comments to this strategy please write and comment or give us a call at (248) 280-4800. (more…)

I am in my living room on a Saturday morning and was just thinking about how often things go wrong in our fast paced world. Case in point, I was at my doctor for my full physical and we started discussing Quality Control and Quality Assurance and the topic came up as to medical procedure quality. I have been involed in FMEA developement for hospital process and surgical protocol and have noticed a fairly strong CONTROL emphasis as a result of those activities. Control in the sense of preventing a failure. An example would be the double checking of your bar code on your wrist and the additional questioning by the care giver regarding your name and purpose of your hospital stay. These controls and the FMEA process outputs driving this level scrutiny has made your hospital alittle more safe.

Can the FMEA process be lean? Based on many experiences with many types of industries, I can say that the vast majority of activity is redundant. Team activity in FMEA should be restricted to only 4 items of discussion only.

• New Content
• Changes to current content
• Past failures
• Increased demand stresses on Carry-over or processes.

The last of these will be my topic of the day. What are increased demand stresses? Demand stresses are based on the noise factors (not audible generally) that are not controlled by the engineer. Noises like Customer usage, Degradation over time, Interfaces with other systems, Environment, and variation sensitivity, are the bases of Robust Engineering. The engineer must attempt to understand these NOISES as they may affect his or her design. The ability of the design (its capacity) to deliver the desired outcomes in the presence of the Demand stress (expected and unexpected) determines how effectively the design satisfies customers. This sounds alittle technical but think of it this way. If an unknown demand on a carryover part is present when the product or process is being used may translate in failure. This means that carryover products and processes which did well in the past may actually fail in the future deployment. Some of my customers indicate that up to 40% of failure comes from what worked in the past but now does not. In order to include these items in future analysis we still need to consider NOISES and their impact on current processes and products.

Currently many companies lean out the FMEA process by creating family FMEA’s. This is not wrong but it can drive the type of behavior that does not consider new or changed NOISES (Increased DEMAND Stress). Currently a cut and paste mentality exists where it does not allow for a efficient review of current designs with respect to new Demands.

In Summary, Lean FMEA is not about cut and paste but instead organization of knowns Causes and Failure Modes, both potential and actual. The additional review of these knowns in relation to new DEMANDS is necessary to assure success.

In Beijing this week teaching 40 or so engineers and suppliers development people in APQP.The tools used in APQP such as FMEA and Design for Assembly were of great interest. I was very pleased at the level of intensity that was demonstrated by the participants. (trying not to fall asleep) But seriously, these tools which have been introduced are not well understood even though many examples exist of their use. I suspect they are filling in the form without getting much value from the tool (FMEA) What is really rewarding to me is when they “get it” and they begin to listen and ask questions and you can see that they will now be using the FMEA as it was intended - to prevent failure and improve controls.