Sub-Clause 1.2 reads (in part): “The only permitted exclusions for this Technical Specification relate to 7.3…..”

If this is the case, how is 6.2.2.1 Product design skills being handled for a non-design organization? How can you meet the “shall” if you exclude product design? :confused:

IMNSHO, this is a hole in TS. :(

16949 Allows 7.3 product design to be excluded. It specifically states that process design are not included. Hence my question. There are parts of 7.3 that call out process design, there are other parts that do not. For example: 7.3.1.1 Multidisciplinary approach, does not say "process". Does this apply to process design? 7.3.4 Design and development review, same thing. Does it apply? Or does process design only apply to those sub-clauses that actually say "process"? I think that if the sub-clause can be applied to process, it should be. But where is the "shall", and how should this be approached?

It is not a good thing when I have to post replies to my own posts.:eek:

I'm not well-versed in TS, I just want to wait and see if you start arguing with yourself.

Is there no-one out there that uses or is familiar with 16949 and can help out?

Dave, Not having the benefit of the spec...I will take a stab (you are at least forwarned to blow this off if it isn't a match :rolleyes: :bonk: )

If the 6 series is resources, like the 9001:2000...then I would say you should use this to point (refer) to whomever is actually performing the tasks and what your company will accept as the minimum requirements.

Does that make sense? :confused: Eileen

Since the shall is under the banner of human resources and training I would say that "if" you are design responsible those individuals performing the function must be competant.

I would say that if a company is not design responsible, it will not formally have trained product design personnel therefore the shall could be covered by a simple statement.

Just a thought.

db said:

It is not a good thing when I have to post replies to my own posts.:eek:

Nope - it's not good. But, all in all, most questions get responses rather rapidly as you know because often you're answering someone elses - for which I and all the others thank you for. Sometimes you have to 'bump' your question as you did. You know how it is with free services!

I'll have a look when I get back to the house tonight, but I suspect it's one of those 'little' things which will end up in a 50 page interpretations list (which those who wrote the document will, of course, blame on auditor incompetence or lack of training!

Dean P. said:

I'm not well-versed in TS, I just want to wait and see if you start arguing with yourself.

I want to see this as well! :thedeal:

db

Perhaps not a hole as such, but not very clever either.

I cant imagine that an auditor would expect to see trained product design personnel at a company that performs no product design.

But you never know.........

I agree with Marc. 6.2.2.1 is in that particular spot because it deals with training. If you do not do product design, and you are "officially" excluded from it, then I would not worry about that requirement.

As for the intermingling of product/process reqirements, you just need to look at the requirements and decipher the wording. Most of the areas that are specifically for design, say so. If it doesn't, it's probably applicable to both, and you need to apply it to process design.

Multi-disciplinary approaches should be used where necessary to ensure that your process will produce a product that conformes to customer requirements. You may need to use (probably will need to use) a multi-disciplinary approach even in process design. It's basically just asking you to get the necessary people involved. (especally when developing a PFMEA, etc.)

Hope this helps :bonk:

:cool:

Nobody is perfect...

IMHO the case of 6.2.2.1 for non design responsible organizations could be a failure of "design" or control of IATF/TC176 and the rest of the team responsible for the 16949:2002... who knows?.

It is not logic a "shall " applicable in Product design skills if the audited DOES NOT HAVE THAT DESIGN RESPONSIBILITY....I repeat, is my opinion.

By the way, talking about mistakes (errors, natural human errors) I have in front of me an IATF final Draft dated July 4 of ISO/TS 2002( which is already obsolete). It says ...7.6.4 Laboratory requirements, but it has to be 7.6.3. The proper order should be:

.......7.6.1 MSA
7.6.2 Calibration Records
7.6.3 Laboratory requirements....

In the official release of ISO/TS Second Edition the mistake was fixed....But some day it happened..

OK .. No attack to anybody , just an asertive opinion and a pretext to say hello to my frends of Elsmar, after a while out of the WEB

Greetings from Mexico

Qualiman

Just a thought, But, what is the definition for being "responsible for design and development?" As Deming would say "what is the operational definition?"

Being the person who gets sued if the design kills someone !

From ISO/TS 16949:2002(E):

1.2 Application
The only permitted exclusions for this Technical Specification relate to 7.3 where the organization is not responsible for product design and development.

7.3 Design and Development
NOTE: The requirements of 7.3 include product and manufacturing process design and development, and focus on error prevention rather than detection.

7.3 clearly states that design and development requirements apply to product AND manufacturing process design activities. However, from the exclusion note in 1.2, if a company is NOT PRODUCT design responsible (such as where I work) then the portions of 7.3 that deal EXPLICITELY and ONLY with PRODUCT design can be excluded. One has to be careful to still address the portions of 7.3 that deal with process design (even if product is also included.)

That being said, here are the sections of 7.3 that I would deem to be NOT APPLICABLE to a company/facility that is NOT PRODUCT design responsible (in other words, these would be the exclusions as per 1.2 Application):

7.3.1 Design and Development Planning
7.3.2.1 Product Design Inputs
7.3.3.1 Product Design Outputs – Supplemental

As far as I can tell, all other sections of 7.3, either directly or indirectly, deal with process design in one way or another.

If anyone would like to comment/add to my thoughts, please do!
:bigwave:

Hi all,

I see a contradition in 7.3.4 design and development review.

The 7.3.4 standard states:
At suitable stages, sytematic reviews of design and development shall be performed in accordance with planned arrangements (see 7.3.1).... NOTE These reviews are normally coordinated with the design phases and include manufacturing process design and development.

Then looking back at the first sentence in 7.3.1:
The organization shall plan and control the design and development of product.

So, 7.3.1 only refers to product design. My company does not do product design. Therefore, I have exempted us from 7.3.1.

Now I get to 7.3.4 and it refers to 7.3.1 (our product design exemption). Except that the 7.3.4 note talks about process.

O.K. so now we are in a circular loop. Are we not? Am I missing something here? Should I just pretend that I didn't notice the reference to 7.3.1 in the 7.3.4 clause and go ahead and address 7.3.4????

If you followed this, you should get a gold star and go to the head of the class!!

Can't wait for sanctioned interpretations on this process and product design stuff.

Help! I'm drowning in the quicksand of process and product design.


Denise :frust:

Denise - have you had any more luck in figuring this out yet?

I am still sticking to what I mentioned previously. I have also relayed this to our Corporate Director of Quality and I am waiting to hear his take on this as well.

:confused:

I guess I don't understand the exclusion of 7.3.1 for Xman and Denise. My take is that "Manufacturing Process Development" needs to follow this clause.

I do understand (and we, too, have) exclusions for 7.3.2.1 and 7.3.3.1. Dave - I, honestly haven't seen how we handled 6.2.2.1 in light of subclause 1.2, but I'm certainly going to investigate.

What a week I'm having today!!!!!!!! Thanks to the Cove for the momentary breaks I can take here. The "occasional zaniness" found here sure is a welcome respite.

Bill

FROM 7.3.1: The organization shall plan and control the design and development of PRODUCT.

Bill -

I understand what you're saying, but the way I am viewing it is that 7.3.1 deals strictly with product design and makes no obvious or implied reference to process design, hence my stand on it.

As for 6.2.2.1 - hmmm, I hadn't really noticed that one - good point. That is another clause I will have to think over too.

I am in no way an expert on 16949 (nor would I ever claim to be :ko: ...I'm just trying to feel my way through this like everyone else.

As Denise mentioned, it'll sure be nice when a good set of sanctioned interpretations are released.

As Denise mentioned, it'll sure be nice when a good set of sanctioned interpretations are released

This comment intrigues me. There were no “good” SI for QS (ie C9), why do you think TS will be any different? :frust: :bonk:

Xman

I'm still a little fuzzy. If I follow your line of thinking (if that's possible for me today), 7.3.2 should be an exclusion also - shouldn't it?

I'm looking at the "DEVELOPMENT" planning more in the light of product realization which, in my mind, includes Process Design.

Thank goodness I have to go kegling tonight and that it will, more than likely, include several glasses from a keg (pun intended).

Have a great weekend all.
Bill

db - In my mind, it seems that TS is a great improvement over QS in the way that it "fits" to our business instead of the other way around. Since TS seems to be an improvement over QS, I am "hoping" that this will also extend to the SI's for TS as well. (Maybe I'm just a dreamer! :smokin: )

Bill - in keeping with the way I am looking at things, 7.3.2 does not explicitly state "PRODUCT", so...
...basically any requirements that do NOT directly state or imply reference to "process" I will address, although I am still a little confused as to where I can/will address 7.3.2.

Does that make any sense?

TGIF! :p

"I understand what you're saying, but the way I am viewing it is that 7.3.1 deals strictly with product design and makes no obvious or implied reference to process design, hence my stand on it. "

Xman,
I agree with you on 7.3.1, I think it deals with product only.
IMO 7.3.2 covers both process and product.and further expands with the inclusion of 7.3.2.1, 7.3.2.2, 7.3.2.3. IMO it would be safe to exclude 7.3.2.1.

Xman and Sam,

I agree with you guys. We have to make our own guidelines, since this isn't very clear. And the thinking that 7.3.1, 7.3.2.1, 7.3.3.1 specifically address product design is the explanation that I think is very plausible.

One question:

Xman,
Where did you see the word 'explicitely'? Is it in the standard somewhere? At first, I presumed that you were quoting from the standard. But, now that I look I can't find it anywhere.

But whether it is there in writing or not, I'm still going with my first paragraph here. If I'm wrong I'll find out in the preassessment audit.

As far as 7.3.1, I don't see how it could apply to process design. There are no 'stages' to process design. It is not like product design where there are stages like prototype and prelaunch.

I am with a company that does no product design, and we were QS certified. The requirement was only to do production control plans. No prototype or prelaunch control plans were needed. And those control plans were the guiding force for the QS auditors.

We don't design anything, we just flat out make it. We do have process parameters that we use to produce the product. That's as clear in my mind (foggy though it is!) as I can get it. It is still difficult, but I'm going with it. Unless I see a better explanation here. I'm always open to different interpretations.

Does that make any sense?

Have a nice day!

Denise :bigwave: :bigwave:

Denise,

I just used the term "explicitly" to get my pont across, it is not in the standard (that I'm aware of.) Basically what I was saying was that I am looking at the exclusions as those that address ONLY product design functions (such as 7.3.1, 7.3.2.1, 7.3.3.1) Sorry if I confused you!

I am pretty much in the same boat as you in regards to our facility doing just manufacturing, that's it.

Bill brought up a very good point with 6.2.2.1 as well though. The exclusion statement in 1.2 states that permissible exclusions ONLY relate to 7.3. That being said, how do we then address 6.2.2.1 (Product Design Skills) if we are NOT product design responsible? Was something overlooked here with the exclusion statement when TS was written? :bonk:

It'll be interesting to see how this develops. :frust:

I hope I am not missing something really obvious, but I do not see any problem with 6.2.2.1 ("The organization shall ensure that personnel with product design responsibility are competent...") and its applicability (or lack thereof) to a company that is not design responsible. In such a case there would be no personnel with product design responsibility. Hence there is no issue, as I see it. It would just be a statement with no relevance.

1. If you take the exclusion for product design, you need not worry about 6.2.2.1 "rsalinger" hit the nail on the head.

This follows the logic of a concept called "scope exceptions". You're not going to find this documented anywhere (and a lot of you are going to hate that), but we Plexus types asked this very question (and others like it) to the IAOB, and they verbally bought into the logic behind it.

If you take the exclusion for product design, that pretty much means you don't HAVE "personnel with product design responsibility...." Therefore 6.2.2 does not apply, and no, you don't have to define a process for making any FUTURE product design responsible personnel competant (like some insane QS auditors might've told you. Since your QMS excludes product design, 6.2.2.1 is beyond the scope of your QMS.

This concept of "scope exceptions" also applies to clauses like 7.3.6.2 (Prototype Programme). It says "When required by the customer...." If your customer DOESN'T require prototypes, no problem. It's probably a good idea to list things like that in your scope statement in the QM. There's a few other clauses like that in the TS - have fun finding them - I just got off a plane, and I'm tired! :)

2. The 7.3.1/7.3.4 Thing
Going back to the scope, it's pretty clear that the task force's INTENT is for organizations to control design and development of processes. You may exclude PRODUCT design if your organization is not doing it. NO ONE gets away with excluding process design. But we knew that already.

The requirements in 7.3.1 apply to both product and process design. They HAVE to. Otherwise, how are you going to ever make a product? Yes, I know it SAYS "product". But think about it - all they're asking for is defining the design and development stages, the review, verification and validation appropriate to each of those stages, and the responsibilities. That's kind of hard to argue with, isn't it? The task force couldn't change that verbiage - the stuff inside the boxes is copyrighted by ISO. Why didn't they add a statement at the bottom of 7.3.1 like they did with 7.3.4? Beats me - I wish they had. But, do you really NOT want to have plans for process design?

If you dig into APQP, it'll point you in the direction of appropriate development stages for process design and development. The important piece has to be the verification and validation steps for the process - capability studies, Run-At-Rate, Process Sign Off, and of course, PFMEA and Control Plan development. It doesn't have to be some massively complicated process, and it's quite likely to be somewhat unique for each program.

You can exclude 7.3.2.1 and 7.3.3.1 entirely. You can exclude
7.3.1, 7.3.1.1, 7.3.2, 7.3.3, 7.3.4, and 7.3.4.1 ONLY as they apply to product design - you're still on the hook for these clauses as they apply to process design.

3. Don't hold your breath waiting for Sanctioned Interpretations for TS2 - there are NO plans to publish any. The IAOB/IATF is adamant about that. In their opinion (and mine, though who cares about MY opinion:) ), SI's for QS caused more problems than they ever solved. Putting my reality hat on though, I'm not sure if they can avoid it. But as of right now, today, there aren't any plans to publish SI's. That's the IAOB's story, and they're sticking to it. If YOU want to argue with Hank Gryn and Joe Bransky about that, go for it - I'll watch, from a safe distance.

Hope this helps!
DW