IATF requirements for FMEA's and Control Plans.

I have been reading though ISO 9001:2015, and IATF 16949:2016, and I have some questions.

Some of our customers require PFMEA’s, and Control Plans for each process. Other customers do not.

The customer who require it are the big OEM’s, and we have all that because it was part of our many PPAP’s, but some of our customers are aftermarket companies who don’t care about ISO, IATF, Risk Analysis, etc.

Do we need to do FEMA's and Control Plans for all of our process even if the customer doesn’t require it?

Can we put in our procedure that we only do this for customers who require it? Or would that be a nonconformity?

What about test equipment that we design and use internally? Do we need DFMEA's for that stuff?

Here is what it says in the standard (see below). I’m pretty sure the answer is: Yes, we need these documents for all processes, and projects whether the customer requires it or not, but I want to be sure before I start such a big undertaking.

8.3.2.1 Design and development planning-supplemental

The organization shall ensure that design and development planning that includes all affected stakeholders within the organization and, as appropriate, its supply chain. Examples of areas for using such a multidisciplinary approach include but are not limited to the following:

a) Project management (for example, APQP OR VDA-RGA);

b) Product and manufacturing process design activities (for example, DFM and DFA), such as consideration of the use of alternative designs and manufacturing processes;

c) Development and review of product design risk analysis (FMEAs), including actions to reduce potential risks;

d) Development and review of manufacturing process risk analysis (for example, FMEAs, process flows, control plans and standard work instructions)

8.3.5.1 Design and development outputs-supplemental

The product design output shall be expressed in terms that can be verified and validated against product design input requirements. The product design output shall include but is not limited to the following, as applicable:

a) design risk analysis (FMEA)

8.3.5.2 Manufacturing process design output

The organization shall document the manufacturing process design output in a manner that enable verification against the manufacturing process design inputs. The organization shall verify the outputs against manufacturing process design input requirements. The manufacturing process design output shall include but is not limited to the following:

a) specifications and drawings;

b) special characteristics for product and manufacturing process;

c) identification of process input variable that impact characteristics;

d) tooling and equipment for production and control, including capability studies of equipment and process(es);

e) manufacturing process flow charts/layout, including linkage of product, process, and tooling;

f) capacity analysis;

g) manufacturing process FMEA;

h) maintenance plans and instructions;

i) control plan (see Annex A);

 

IATF is only applicable to your automotive customers. It won't apply to aftermarket or other customers. So you definitely should put an "out" in your procedure.

If you are not design responsible (i.e.; make to customer's print), you only need to worry about manufacturing process design. And again, only for applicable automotive customers.

 

I went to IATF Lead Auditor training last week and ask my instructor about it.

He said if we have a customer that doesn't require PFMEA's, and Control Plans, that we don't have to make have them, but we need a waiver signed by the customer.

I have been looking online for a waiver to use as a template, but I am not having any luck.

Anyone have a good waiver I can use?

 

Most of us have been "doing" them a long time. Just not in the AIAG format. Kind of hard to operate without anything. But, the AIAG format can be cumbersome and overkill for many situations.

 

I personally love FMEA's, they are very useful. We already use them for our customers who require IATF.

But, our process owners for our non-OEM customers don't want to do it, and I'm not gonna do it for them. lol

 

I agree with Andy. FMEAs and Control Plans add value to the operations of design and/or manufacturing companies. Since your company makes use of them and you find them very useful, why not just use the same FMEAs and Control Plans in case your aftermarket customers ask for them. Also, there's no need to mention in your procedure that you only do FMEAs and Control Plans for customers who require them.

If you're using FMEA to satisfy IATF 16949 and your automotive customers, you can also use this as an RBT tool for manufacturing products for your aftermarket customers - if your company subscribes to ISO 9001:2015.

 

Here is my opinion on the reason why the process owner(s) disapprove of the use of the PFMEA and Control plan. I have been working in a big manufacturing plant which is owned by a Top50 corporation for 8+ years. This kind of corporation indeed is addicted to the talents, and also have the ability to pay them "fat". However they also tends to not just heavily depend on someone or even anyone. So they need to "force" the process owner(s) who know the process well to share their knowledge or "pass on" their knowledge to someone who is potentially willing to accept a "reasonable" salary as a potential successor. And FMEA and control plan is a good way to achieve this goal. Good FMEAs can contain precious knowledge of the process(es), and let the new guy to know or even master the process in a relatively short period of time. It is good to the organizaion however not that attractivc to someone (of cource, not everyone). If the process owner want to prevent this situation, just do a mediocre FMEA, based on my experience on this kind of FMEA, it is really not worth the efforts (just some cumbersome paperwork ㅜ.ㅜ)
Maybe it is not appropriate to do such "wild" even "a little vicious" speculation. However sometimes the competition in the workplace is THAT fierce. When it comes to smaller organizaion, it may becomes even worse, because breaking down cost, especially human cost, may be more critical for the smaller organizaion to survive in the modern jungle.

 

My two cents because someone above mentioned "AIAG Format." If you look in the AIAG books, they give examples of Process Flow Diagram and Control Plan and say "Like this." Not EXACTLY like this. So if the format is cumbersome, change it - as long as it meets the requirements.

Example: I cannot STAND the AIAG PFD example. It has separate columns for each step type (operation, check, movement, etc) but it also has separate SYMBOLS for each type. That's redundant. Also, it's a very vague idea of what's going on.

Why not take the floor layout of the equipment, label the OP numbers, and draw the arrows showing the routing? That's FAR more descriptive of the process flow.

What I have found is AFTER PPAP, if we have discussions about how or where a process is going wrong, we are invariably looking at the layout diagram. The Process Flow Diagram remains untouched in the original PPAP and adds very little value (as formatted per AIAG) or none at all.

 

That may work for your organization. But we don't really have a "process flow" at the part level. It may or may not change machines depending on current capacity especially for non-auto stuff. Things like "recommended action" and a new RPN isn't really helpful for us.

 

You demonstrate my point, however. The "Blue Books" give us ONE example for PFD, D/PFMEA, Control Plan and we have imposed upon ourselves as the industry that these examples are the requirements, when they are not.

The thought that I can shoe horn in any given process to a template that is at best "one size fits most" and at worst overly complicated trying to handle every situation makes no more sense than saying every process engineer is the same. You can't take a stamping expert and put him in a rubber molding operation and expect the same results.

Further, it burns too much time trying to make things look like everyone else instead of doing the work and sorting out if it actually adequately controls the process.

Don't get me wrong, there is advantage to standardization to some degree. It definitely adds clarity. A good example is an 8D for problem solving. That's pretty accepted as a norm and it's a good norm. But I care less about the format of the 8D as long as all the steps are there and in order. My general experience is that standards can suffer scope creep. They start out with "Here is the requirement." Which is what they SHOULD be. But then a few folks don't understand the requirement, and the standard evolves towards "Do it this way."

Consider a control plan and work instructions. If I choose to run my shop via work instruction, why can my control plan simply not be my work instructions in order (provided they meet the requirements)? OR, if I run my shop via control plan, do I NEED separate work instructions? (Again, providing all requirements are met).

 

True. Yes over the years we have been required to adopt the exact format in the aiag books even though "guidelines" is used all throughout the books. We even had NCs written on old plans that did not have a "key date" filled it. It sucks.

 

Drives me bonkers. We are told to be JIT/Lean/Visual/Effective.

Then any creativity is met with "That's not how it's supposed to LOOK." Really?

If I replace my Andon lights on my line with a natural solution employing pigeons and sea turtles and it at least as effective and costs me less, you should say "Good job on your creative inline notification" and not ding me for having no Andons.

 

Currently checking on-line for a source from which to order pigeons and sea turtles.

 

There are two sections where customer's waiver is mentioned - 8.2.3.1.1 and 8.3.6.1.
In my opinion, usage of customer's waiver has a very limited applicability.
Especially, any CSR or waiver can't be set in opposition to requirements of IATF 16949 standard.