Section 8.2.3.1 Order Review

imwilliam

Involved In Discussions
Hello All,

So, this order review section of the standard is one of several giving me heart burn.

Specifically, the opening of 8.2.3.1:

"The organization shall ensure that it has the ability to meet the requirements for products and services to be offered to customers. The organization shall conduct a review before committing committing to supply products and services to the customer.

a) . . . including requirements for delivery . . ."


So, if I look at a P.O. and realize I can't make the delivery date, then before I can get started on the work, I need to contact the Customer and let them know I can't, when I anticipate that I can and if they agree, then start on the work . . . seems straight forward enough in theory but I think in reality, (or at least my little corner of reality), it's a problem.

I get purchase orders that have due dates prior to the date I received the P.O. Sometimes the dates are impossible. What happens when that purchase order comes in on a Friday afternoon and I can't get a hold of anyone to issue a revised P.O. Do I let this P.O. set till Monday, the one stamped in red "URGENT" and "PLEASE EXPEDITE" or do I get started on it over the weekend? Right now, I get started and work over the weekend and I think that's the right thing to do, how do I structure my QMS so that I can still so this for my customer?

Sometimes a customer may "flood" me with purchase orders, sometimes for parts we've never done, with delivery dates we'll never make (And they know that). I triage the work, usually asking for a priority list from the customer and taking that into account, (but not necessarily strictly following it), and get started on the work. I don't want my QMS to force me into waiting till I've come up with reasonably accurate delivery dates for a dozen jobs before I get started . . . and neither does my customer. So how do I structure my purchase order review, so it doesn't paint me into a corner?

And in real life, Purchasing Agents don't really seem to like it when you tell them you can't make the date as soon as you get the P.O. I think it sometimes/somehow forces them to pull the job and find someone else. . . something I don't think they really want to do. My sense is that they would prefer you make your best effort, advise them a few days before delivery that you'll be a bit late and leave it at that. (I learned this the hard and expensive way)

And sometimes I just don't know how long it's going to take. That's part of small orders and prototype work vs repeat production.

Sometimes I get purchase orders without prices on them, now what? Hasn't been an issue to date.

Biggest concern I have when I get a purchase order is that if it's a repeat job, that my programs/notes and etc. are for the same Rev as the current order. That's worth checking and making a note of. Some jobs/parts need an inspection before I get started with them, that's important too.

But particularly with due dates, how do I structure my QMS/order review so that I don't end up as a worse supplier after its in place than I was before? Or can I?

On the topic of risk-based thinking, one of the risks of full ISO9000 certification that I'm concerned about is that I could end up a worse supplier at the end of the day, and that's what I want to avoid.
 

geoffairey

Involved In Discussions
An order is only an order when both parties agree.

If the customer is asking for something you can’t achieve, you (your company, not necessarily you personally) either need to negotiate for a new achievable order or refuse the order.

renegotiation may need some creative thinking, e.g. delivery in part shipments as you have them

Accepting an unachievable order is a non conformity and a failure of customer service.
 

imwilliam

Involved In Discussions
An order is only an order when both parties agree.

If the customer is asking for something you can’t achieve, you (your company, not necessarily you personally) either need to negotiate for a new achievable order or refuse the order.

renegotiation may need some creative thinking, e.g. delivery in part shipments as you have them

Accepting an unachievable order is a non conformity and a failure of customer service.


Surely, given the examples I gave above, you must mean "a failure in customer service" in the technical sense within the narrow confines of the ISO 9001 standard: and that, at a single point.

If my customer is content to work out delivery dates, even price, as we go, and I'm content, who's to say that I shouldn't be able to adapt my QMS to reflect that?

Does the standard really do that?
 

Tagin

Trusted Information Resource
The intent is to prevent mindlessly accepting orders into a system, which can then result is problems, either internally, or for the customer, or both.

So, although 'review' is typically thought of as a single 'gate', it need not be. If you are willing to take calculated risks of starting a job early before final agreements have been made with the customer, that is ok. In your case, 'review' can happen somewhat in parallel with operations, and the point is that you are able to show that you have control over things like: 1) risks taken, 2) changes to the order (especially while in process), 3) delivery date management, and 4) preventing release of a shipment until all the questions about the order have been settled between you and the customer.

This may be a bit more difficult to document and describe to an auditor than a single review gate or stage or signoff, but I think it fits the spirit and intent of the clause.
 

imwilliam

Involved In Discussions
The intent is to prevent mindlessly accepting orders into a system, which can then result is problems, either internally, or for the customer, or both.

So, although 'review' is typically thought of as a single 'gate', it need not be. If you are willing to take calculated risks of starting a job early before final agreements have been made with the customer, that is ok. In your case, 'review' can happen somewhat in parallel with operations, and the point is that you are able to show that you have control over things like: 1) risks taken, 2) changes to the order (especially while in process), 3) delivery date management, and 4) preventing release of a shipment until all the questions about the order have been settled between you and the customer.

This may be a bit more difficult to document and describe to an auditor than a single review gate or stage or signoff, but I think it fits the spirit and intent of the clause.

That's what I was hoping for, both in this specific case and as a general concept for structuring my QMS.

Would some sort of a "position statement" in the QMS stating that when we start a job without settled details we do so as a courtesy to the customer and accept the risks and then enumerate some of those potential risks?

I'm thinking at times some of these "position statements" on various items explaining the rational in advance might help with an audit, might help me refine how I think about these things as well.
 

Tagin

Trusted Information Resource
That's what I was hoping for, both in this specific case and as a general concept for structuring my QMS.

Would some sort of a "position statement" in the QMS stating that when we start a job without settled details we do so as a courtesy to the customer and accept the risks and then enumerate some of those potential risks?

I'm thinking at times some of these "position statements" on various items explaining the rational in advance might help with an audit, might help me refine how I think about these things as well.

That would help some, but that's just one facet. The key thing is to be able to demonstrate control over all the aspects of the order that may be up-in-the-air until final agreement is reached:
  • Who has authority to say "start this order early", "go ahead and buy all the raw materials", etc.?
    • I.e., who is authorized to make that risk assessment and decide go or no-go on starting early?
  • What will prevent the order from shipping before final delivery dates are agreed upon?
  • If an order is changed while in production, how are those changes controlled, so the old version of the order doesn't ship, and any changes in production process are made?
  • Etc.
 

Funboi

On Holiday
Don’t you acknowledge the receipt of the PO with your estimate of when the job will be finished and why it has to be that way?
 

imwilliam

Involved In Discussions
Don’t you acknowledge the receipt of the PO with your estimate of when the job will be finished and why it has to be that way?

Some P.O.s come with a request that I confirm, and I do.

But normally, no I don't, if I pick up parts or they're dropped off here.

If I'm emailed a P.O. or if parts are shipped via someone other than my customer or myself, then I confirm receipt of the parts and P.O.

Sometimes there isn't a P.O. at all. Parts get dropped off and I'm asked to do something to them, and I do that something to them. Most often they come with a print, sometimes no.

Keep in mind, these aren't new customers, some of these folks I've worked with for a couple of decades.
 

Funboi

On Holiday
If I understand, you have but one customer requiring certification? If so, you could make the scope of your QMS specific to their products, or something similar which can free you to handle everyone else in your current methods. Some might rail against operating 2 systems, but if you want the business, there’s value in having a QMS and it is creating problems with customers who care not about ISO, I see no alternative. I have seen a supplier who successfully negotiated out of certification by passing on the costs to the buyer and giving them the job to change their ridiculous internal requirements. Offer them a part specific Quality plan, - a mini QMS - in place of certification and welcome their audit, is also an option.
 

imwilliam

Involved In Discussions
This is something that's been on my mind, limiting the scope of the QMS to just this one customer. Could I limit the scope to only those customers that require ISO9000?

But that won't solve the original problem in my post.
 
Top Bottom