Crystal Ball Methodology - reading customers' minds?

K

karin

Hello, everyone!!

I've been a lurker for a few months and really value this site -- you all have such great imput and make me realize I'm not the only one going thru the "bad guy" syndrome at work while upgrading us from QS-9000 to TS2.

Okay, I have a question now, and if this has previously been addressed, please ignore, tell me to go away, and/or give me a link to the thread -- that would be appreciated.

7.2.2 ~ Where the customer provides no documented statement of requirement, the customer requirements shall be confirmed by the organization before acceptance.

HUH? :confused:

First of all, how do you implement that -- do you really have to say to the customer "um, are there any other requirements you're not telling me about that I need to confirm" -- sounds a tad insulting to me ...

Second of all, how would you document that this has been done -- I did download an awesome contract review check list posted by a member on this site, and it does have a box marked "requirements not stated by customer are defined" ... but how would you prove that?

Any input would be greatly, greatly appreciated. It's hard enough to get my coworkers on board with this stuff -- now I have to ask them to be mindreaders AND document the information they mindread!!! :bonk:
 
B

ben sortin

My tool of choice would be "Quality Function Deployment" (QFD). QFD is a planning tool which translates customer needs and wants into significant items on which to focus time, product improvement efforts, and other resources. If your company uses it with some discipline you may reduce the overall product development cycle.
 

howste

Thaumaturge
Trusted Information Resource
Don't forget that sometimes customers like to get on the phone and order things. In this case you know what the customer wants, it's just not documented. I believe this is really the intent of that text in the standard.

The "requirements not stated by customer are defined" part really comes in when you know more about your product than your customer, or when some things are just assumed but not stated. If I mail-order a toaster in the USA, I don't specify that it needs to be 115 volts. But if it shows up requiring 220, I'll be pretty hot...
 
K

karin

ben sortin said:
My tool of choice would be "Quality Function Deployment" (QFD). QFD is a planning tool which translates customer needs and wants into significant items on which to focus time, product improvement efforts, and other resources. If your company uses it with some discipline you may reduce the overall product development cycle.

Ben ~ I did forget to mention that we are a value-added distributor. 90% of our business is straight distribution -- so our APQP process as it currently stands is making sure customer requirements are known and quoting them the correct product for their application. We do cut parts to length, also ...

As a distributor, I want to keep this all as simple as it can be -- sometimes the customer will ask us to send them 500' of a specific product they call out -- I guess what I'm saying is I just want to keep this as simple as possible for us (isn't that what we're all trying to do?)

I *really* appreciate your response!!

Karin
 
K

karin

howste said:
Don't forget that sometimes customers like to get on the phone and order things. In this case you know what the customer wants, it's just not documented. I believe this is really the intent of that text in the standard.

The "requirements not stated by customer are defined" part really comes in when you know more about your product than your customer, or when some things are just assumed but not stated. If I mail-order a toaster in the USA, I don't specify that it needs to be 115 volts. But if it shows up requiring 220, I'll be pretty hot...

I wish the writers of the standard would ask normal people to read it over before they expect us to implement it -- I hate being in the position of interpreting their intent ...

And I appreciate your response ~ but let me ask, how do I document an assumption that we're meeting the customers' specifications? Should I work it into a procedure? Do you have any tips you can give?

Thanks so much!!!
 
C

Craig H.

karin said:
I wish the writers of the standard would ask normal people to read it over before they expect us to implement it -- I hate being in the position of interpreting their intent ...

And I appreciate your response ~ but let me ask, how do I document an assumption that we're meeting the customers' specifications? Should I work it into a procedure? Do you have any tips you can give?

Thanks so much!!!


Karin:

Welcome to the Cove!

What I think of here (and we're ISO 9001, not TS, so take it for what its worth) are things like type of packaging and labeling, if a Certificate of Analysis is required, and if shipping information needs to be emailed or faxed. The customer might not think of stating the requirements for these up front, and that will cause problems when the item(s) show up and do not conform with their Quality System.

For instance, we have no stated requirement that the bags of our material should still be upright on the pallet when the customer's truck arrives at the customer's dock. Is it a requirement, nonetheless? You betcha!

Hope this helps

Craig
 

howste

Thaumaturge
Trusted Information Resource
karin said:
...how do I document an assumption that we're meeting the customers' specifications? Should I work it into a procedure? Do you have any tips you can give?
How do you have your other "contract review" requirements documented? A verbal order is really no different than a PO or contract. You're already required to have records of review of requirements, only in this case you don't have anything in writing from their end. Just write down their requirements then review them the way you would any other order.

One last thought - you aren't required to have a record that you confirmed their order, but I would recommend a confirmation email or fax in case there's a dispute later...

BTW, I think that there are really two things that are being discussed in this thread - 7.2.2 review of requirements (which I'm addressing in this post), and 7.2.1b-d determination of requirements. I'm trying to keep clear what we're talking about.
 

Cari Spears

Super Moderator
Leader
Super Moderator
howste said:
...The "requirements not stated by customer are defined" part really comes in when you know more about your product than your customer, or when some things are just assumed but not stated...

I struggled with the Review vs. Determination thing too and this is what I also took it to mean in the end. I've attached an exerpt from our policy manual - some of our customers know exactly what they want, others rely on us to determine what they need. What do you guys think?
 

Attachments

  • QPM.9k2k Outtake.doc
    74 KB · Views: 291
Last edited:

Cari Spears

Super Moderator
Leader
Super Moderator
howste said:
BTW, I think that there are really two things that are being discussed in this thread - 7.2.2 review of requirements (which I'm addressing in this post), and 7.2.1b-d determination of requirements. I'm trying to keep clear what we're talking about.

Oops - you're right. I was looking at 7.2.1.

For 7.2.2 - we use a verbal order form.
 

Wes Bucey

Prophet of Profit
Never confused on this point

Cari Spears said:
I struggled with the Review vs. Determination thing too and this is what I also took it to mean in the end. I've attached an exerpt from our policy manual - some of our customers know exactly what they want, others rely on us to determine what they need. What do you guys think?

PS - We're ISO not TS.
Am I the only one who NEVER was confused about the intent of 'confirming customer requirements'?

It always seemed straightforward to me:
If the customer didn't provide WRITTEN detailed description of his requirements for a custom product (versus off-the-shelf item), it was our job to ask questions until we were sure we understood. Once we made the determination, we WROTE it down (copy to customer for confirmation via FAX or [now] email when time was a factor.)

With an off-the-shelf item, we made doubly sure customer made no error when ordering by phone ("Part number 15-345? Yessir, to confirm so I have it right, you want a green spindizzy for a framsit. Is that correct?")
 
Top Bottom