Family FMEAs (PFMEA specific)

INCase

Registered
hello, new to this forum but have been doing FMEAs for some time. Recently (1 year) working with Apis IQ-RM PRO. very handy and beats excel by a long shot once you get used to it.

background: per the AIAG/VDA book foundation and family FMEAs are allowed. Foundation FMEAs I agree with as it is the basis for building new FMEAs from and am working on building a version of one. Family FMEAs are more specific FMEAs that cover a group of FMEAs that are similar in fit, form, function and for the most part only vary by size (other posts on here on this already). we currently use neither. we are a very large corporation and it appears there is very limited use at the corporate level so little to no help internally even amoungst our "FMEA experts" so I'm looking for some outside help.

My concerns.
our plant manufacturing areas (process engineering) are pushing for family FMEAs. Due to: 1, no one has time and/or 2, they are lazy and/or 3, dislike FMEAs. My concern is they will use the Family FMEA as a "RUBBER STAMP" for all products from now on and will not review new projects, or revisions to current products to the generic Family FMEA(s). (No its not my job as the FMEA moderator to police that but no way I would not get dragged into 8D/5 why issue resolutions if an issue arises). We mold and assemble automotive parts. molding could in theory be broken down into 2/3 family FMEAs without alot of difficulty. our assembly side has at least 10 variations that could be combined in any combinaton as well as for about 6 different automotive OE customers (different rating tables and F's, F/C, G/C ect ect ) making that much more complicated. if fact even within one specific customer they have different special characteristic classifications depending on the export market.

now my question:
1, those of you that use family FMEAs, how do you manage documenting which parts go with a specific FMEA? Generic Family FMEA with a new cover sheet for each product? or I've seen a proposal to use a spread sheet that lists all products that go with an FMEA but not sure if that would be audit proof. especially if there is no control over that spread sheet document (seems too loose to me). or update the FMEA cover sheet by adding each new to it?

2, unused components. in other words since we have about 10 variations, many of which are adding/subtracting components, is it an issue to have components/processes listed in the PFMEA that are not on the specific product that the family FMEA is being applied to? would an auditor or customer Supplier quality engineer protest such things? (certainly could if a component was missing)

Thank you
 

Ron Rompen

Trusted Information Resource
Not sure if this will really address your problem or not, but here's something to consider.

Create 'common process' FMEA's for those things that don't vary from part to part, customer to customer (example, oven temperature as a single example) and use those to build your part-specific FMEA on. Yes, it will still require some work to make the final product acceptable to your customers needs, but it gives you a 'building block' to start with.
 

Tidge

Trusted Information Resource
now my question:
1, those of you that use family FMEAs, how do you manage documenting which parts go with a specific FMEA? Generic Family FMEA with a new cover sheet for each product? or I've seen a proposal to use a spread sheet that lists all products that go with an FMEA but not sure if that would be audit proof. especially if there is no control over that spread sheet document (seems too loose to me). or update the FMEA cover sheet by adding each new to it?
My "family" PFMEA (e.g. "Punching") had several features that made them look slightly different than more specific targeted PFMEA:
  1. The analysis was tied to the equipment that would be used in a general, commonly used process.. like "punching metal sheets".
  2. There was a general process map, this map included setup, line-clearance and tear-down steps as well as the actual "punch" the part
  3. The steps of the process map went to specific sections of the FMEA, many things done in the process aren't for specific parts so this saved effort of cutting and pasting identical lines with identical controls into many many different FMEA
  4. There was an index of parts that allowed specific tracing of failure modes to the particular harms depending on what the parts were actually for.
The last piece was key. Not all parts can lead to the same harms, even if the same general process is used to make the different parts. Most of the meaningful analysis was in that section of the FMEA. We felt it was important to NOT downplay how process steps like setup could lead to failure modes, but we didn't want to have to duplicate efforts for the thousands of different parts being made.

Said another way: We tried to use the one section to analize how specific non-conforming parts could lead to different harms/negative outcomes, and the other sections were mostly just accounting for obvious/typical risk controls relating to the general process.

I didn't think it was lazy to account for risk controls like preventive maintenance or oil changes only once in one document instead once in a thousand different documents. On the contrary, I thought it was very practical.
 

toniriazor

Involved In Discussions
My "family" PFMEA (e.g. "Punching") had several features that made them look slightly different than more specific targeted PFMEA:
  1. The analysis was tied to the equipment that would be used in a general, commonly used process.. like "punching metal sheets".
  2. There was a general process map, this map included setup, line-clearance and tear-down steps as well as the actual "punch" the part
  3. The steps of the process map went to specific sections of the FMEA, many things done in the process aren't for specific parts so this saved effort of cutting and pasting identical lines with identical controls into many many different FMEA
  4. There was an index of parts that allowed specific tracing of failure modes to the particular harms depending on what the parts were actually for.
The last piece was key. Not all parts can lead to the same harms, even if the same general process is used to make the different parts. Most of the meaningful analysis was in that section of the FMEA. We felt it was important to NOT downplay how process steps like setup could lead to failure modes, but we didn't want to have to duplicate efforts for the thousands of different parts being made.

Said another way: We tried to use the one section to analize how specific non-conforming parts could lead to different harms/negative outcomes, and the other sections were mostly just accounting for obvious/typical risk controls relating to the general process.

I didn't think it was lazy to account for risk controls like preventive maintenance or oil changes only once in one document instead once in a thousand different documents. On the contrary, I thought it was very practical.
You should definitely try to make your life easier and not have many FMEAs on similar/identical parts/ products. You can also agree how you will handle this subject with your customer. Your customer as well doesn't want to review hundreds of FMEAs during APQP/PPAP. In my experience it is fine to have like generic FMEA for similar products, since the failure modes and effects of failure could be the same. I also worked for automotive industry and we had many different products and part numbers, but agreed with our customer to handle everything in one single FMEA and highlight the inputs/outputs in the revision section for easier navigation. FMEA is a time-consuming and ongoing activity and it is better to spend more time doing the actual risk analysis in the manufacturing, instead of fulfilling all day excel tables.
 

JohnsonCM

JohnsonCM
Hello INCase. As a 24-year IQ-Software expert (user, trainer, consultant) I have a lot of insight to offer regarding FAMILY fmea's. In short, there are multiple ways to handle this concept using (separately or in combination), structure variants and perhaps the CARM Server complimentary software. Using the Variant Editor is a great help in managing the variant data and keeping it straight across multiple variants. Reach out to me at [email protected] and give us a chance to help.
 
Top Bottom