oops. yep. I guess sipping from the cooking sherry doesn't help huh?
Informing Customers of Process Changes - Is this considered a process change?
oops. yep. I guess sipping from the cooking sherry doesn't help huh?
Helmut Jilling
Auditor / Consultant
...many people seem to feel sherry helps, but that is another thread...
Helmut Jilling
Auditor / Consultant
Re: Is this considered a process change?
It is hard to speak definitively when you are using analogies of pies. But here are a couple hard facts you may consider:
1. It is absolutely necessary that you figure out how to verify whether your processes meet the requirements. Any scenario you expect to encounter has to be verified. That is fundamental to all quality systems. You can't just guess. In automotive (TS), there is a whole super-process of APQP-FMEA-Control Plans_PPAP to validate all this. You must verifyeach meaningful characteristic.
2. In USA automotive, the PPAP book gives a few tables that explain when you have to notify a customer. Plus, they customer has a right to specify when notification is expected. Generally speaking, if you add things, to make the process more robust (add inspections or mistake-proofing), you may not need to notify. If you take anything away, you have to notify.
3. If it were easy to figure out how to test all this, then you wouldn't be getting paid the BIG BUCKS that you are!
It is hard to speak definitively when you are using analogies of pies. But here are a couple hard facts you may consider:
1. It is absolutely necessary that you figure out how to verify whether your processes meet the requirements. Any scenario you expect to encounter has to be verified. That is fundamental to all quality systems. You can't just guess. In automotive (TS), there is a whole super-process of APQP-FMEA-Control Plans_PPAP to validate all this. You must verifyeach meaningful characteristic.
2. In USA automotive, the PPAP book gives a few tables that explain when you have to notify a customer. Plus, they customer has a right to specify when notification is expected. Generally speaking, if you add things, to make the process more robust (add inspections or mistake-proofing), you may not need to notify. If you take anything away, you have to notify.
3. If it were easy to figure out how to test all this, then you wouldn't be getting paid the BIG BUCKS that you are!
Helmut Jilling
Auditor / Consultant
well, GOOD sherry helps!
cooking sherry, not so much!
COOK with the sherry...DRINK the Cabernet...
Z
zeptech
Re: Is this considered a process change?
Interesting pie story, now I have another scenario. I will also use the pie as analogy.
I am now manufacturing pie, using 10 ovens. Because of capacity constrain, I also employ my subcontractor to do the same with the same oven. They have 10 ovens doing the same pie, same recipe, same process flow.
Customer knew about our subcontractor, they have been notified via PCN earlier.
NOW, due to organization restructuring and management realignment, now we want to focus on developing new kind of pie, and we do not want to manufactur that much in-house. So we decided to transfer the current 9 machines in-house to our subcontractor. Meaning we left only 1 machine for "development" (experimental) purposes and our subcontractor will have total of 19 machines.
QUESTION -- Is a PCN needed for this transfer?
I understand, equipment relocation, even though within company from one building to another, requires PCN. But that focus is more because of "new location". Now if we consider my above scenario as our subcontractor buying additional 9 machines -- not buying from OEM but buying from us. Do we PCN?
My argument is to look in such an angle that subcontractor is adding more machines in their production line, and the machine they are buying is the same model like the existing one they are using, only that they are buying "second hand" instead of "brand new machine". So they only need to do internal qualification of the additional machines and PCN is not required to notify customer.
Please comment.
Interesting pie story, now I have another scenario. I will also use the pie as analogy.
I am now manufacturing pie, using 10 ovens. Because of capacity constrain, I also employ my subcontractor to do the same with the same oven. They have 10 ovens doing the same pie, same recipe, same process flow.
Customer knew about our subcontractor, they have been notified via PCN earlier.
NOW, due to organization restructuring and management realignment, now we want to focus on developing new kind of pie, and we do not want to manufactur that much in-house. So we decided to transfer the current 9 machines in-house to our subcontractor. Meaning we left only 1 machine for "development" (experimental) purposes and our subcontractor will have total of 19 machines.
QUESTION -- Is a PCN needed for this transfer?
I understand, equipment relocation, even though within company from one building to another, requires PCN. But that focus is more because of "new location". Now if we consider my above scenario as our subcontractor buying additional 9 machines -- not buying from OEM but buying from us. Do we PCN?
My argument is to look in such an angle that subcontractor is adding more machines in their production line, and the machine they are buying is the same model like the existing one they are using, only that they are buying "second hand" instead of "brand new machine". So they only need to do internal qualification of the additional machines and PCN is not required to notify customer.
Please comment.
S
silentrunning
I have found the hard way that you should always notify the customer of ANY change.
We have been making a particular bracket for several years. The supplier we bought the steel from could no longer supply us for some reason. We shopped around and found another supplier that was glad to get our business. We didn’t notify our customer of the change. (He did not require notification on his PO.) The new material started to fail in application and was found to be at the very bottom of the specification for tensile strength. The old material had been at the high end. If we had notified him of a change he probably would have tried a few of the brackets in application before sending them out to customers. The recall was costly for both of us. We now notify our customers of any change.
We have been making a particular bracket for several years. The supplier we bought the steel from could no longer supply us for some reason. We shopped around and found another supplier that was glad to get our business. We didn’t notify our customer of the change. (He did not require notification on his PO.) The new material started to fail in application and was found to be at the very bottom of the specification for tensile strength. The old material had been at the high end. If we had notified him of a change he probably would have tried a few of the brackets in application before sending them out to customers. The recall was costly for both of us. We now notify our customers of any change.
Helmut Jilling
Auditor / Consultant
The AIAG PPAP manual defines several tables of when the customer must be notified of changes. The whole purpose of that is to prevent failures, by verifying or validating changes, upfront.
Most of the discussion on this thread ASSUMES there won't be any impact....
Obviously, "Assuming" is not as effective as "validating." ISO and TS are trying to PREVENT failures. Why are we cheating the system? These are good tools to protect you, not make your life difficult.
Most of the discussion on this thread ASSUMES there won't be any impact....
Obviously, "Assuming" is not as effective as "validating." ISO and TS are trying to PREVENT failures. Why are we cheating the system? These are good tools to protect you, not make your life difficult.
How do you know the sub on will install them correctly?
How do you know they aren't damaged in shipment?
If I were your customer the validation would probably not be very difficult. But I would want some validation. I get about 4 crashes from invalidated changes that my supplier didn't bother to tell me about every year. Either th eproduction line goes down - for days or worse my customer experiences the failures.
Always notify your customer. It is their money and their business you are putting at risk. PREVENT problems and everyone is happier.
How do you know they aren't damaged in shipment?
If I were your customer the validation would probably not be very difficult. But I would want some validation. I get about 4 crashes from invalidated changes that my supplier didn't bother to tell me about every year. Either th eproduction line goes down - for days or worse my customer experiences the failures.
Always notify your customer. It is their money and their business you are putting at risk. PREVENT problems and everyone is happier.
S
ssz102
Re: Is this considered a process change?
also i think the type of change need to inform the customer regardless these change is internal change or customer change requires
also i think the type of change need to inform the customer regardless these change is internal change or customer change requires
Similar threads
