Process Control Plans: Product Characteristics vs. Process Characteristics

All,

I have recently been challenged by a TS-16949 auditor who noted we lump our process and product characteristics together. Does any one have any examples of process characteristics (beyond what's provided in the APQP manual)?

I am quite sure I am making a mountain out of a mole hill, here, and am hopeful that a few examples will orient my thinking accordingly.

Thanks!

Re: Process Control Plans: Product vs. Process

shadowjade said:

Does any one have any examples of process characteristics (beyond what's provided in the APQP manual)?

Click to expand...

Let's say you are doing machining. Product characteristics: Dimensions on the product, surface finish, etc. Process characteristics; feeds and speeds, tool wear, etc.


Let's say you are doing injection molding. Product characteristics: Dimensions on the product, surface finish, etc. Process characteristics; injection pressure, speed, hold time nozzle temp, mold hold time, mold pressure, ejector speed, etc.


Does that help?

Re: Process Control Plans: Product vs. Process

Yes,

That does help... our processes involve machining. We view this as a rather redundant task as we already denote pressures, feeds, and speeds on router packets (at each step/operation of the process) and/or checklists. Are we missing the boat as to this being potentially important in the overall processing of our parts?

Thanks!

Re: Process Control Plans: Product vs. Process

Some more recent control plans have two columns under the Characteristics heading: one for Product and one for Process. This way you can keep them 'separate' and easier to identify by everyone. The rest of the Control Plan can remain the same. I believe this will make things clearer and respond to the auditor's challenge. See the attached file for a sample control plan. That's my .

Re: Process Control Plans: Product vs. Process

shadowjade said:

That does help... our processes involve machining. We view this as a rather redundant task as we already denote pressures, feeds, and speeds on router packets (at each step/operation of the process) and/or checklists. Are we missing the boat as to this being potentially important in the overall processing of our parts?

Click to expand...

It is redundant. You need to have it on the control plan - if it wasn't important, you wouldn't document it anywhere. If you use the control plan on the floor, you can remove it from the router. If you like the layout on the router (it may include tool paths, etc.), then not only is it redundant, but you will always have to make sure it matches!

Re: Process Control Plans: Product vs. Process

To Bob's comment ... In the case of machining processes you don't have to reference all process parameters (feed, speed, DoC, tool, comp., etc). A simple reference to the NC program and the machine NC controls will suffice IMHO. Now, it is not bad practice to verify occasionally (once a year or so) that the speed and feed are what they are supposed to be ... It can help identify potential problems with the equipment and/or the process.

Re: Process Control Plans: Product vs. Process

DrM2u said:

To Bob's comment ... In the case of machining processes you don't have to reference all process parameters (feed, speed, DoC, tool, comp., etc).

Click to expand...

That's true - just the ones that impact the quality of the part - especially if they relate to process FMEA/corrective action issues. If there is no limit to the adjustment you can make in realtionship to the quality of the process output, it need not be in the control plan.

Re: Process Control Plans: Product vs. Process

shadowjade said:

Yes,

That does help... our processes involve machining. We view this as a rather redundant task as we already denote pressures, feeds, and speeds on router packets (at each step/operation of the process) and/or checklists. Are we missing the boat as to this being potentially important in the overall processing of our parts?

Thanks!

Click to expand...

Let me take a guess. You've been around for a while and have the specifics documented on an individual "part router." That router is what your operators use to run their jobs. You have been doing it like that for years.

DrM2u's sample is very nice. We would take it one step further and develop the control plan for "families" of parts (ie; similar parts, different sizes). We would then refer to the router or print dimensions instead of including that on seperate control plan documents. That is an attempt to minimize the redundency. To me, your most important document is the router, which is built from the control plan. Good luck.