AS9100D 8.2.1 Review Requirements for Products and Services

[Kathy Beagle]

Hi Folks, I work for a thermoplastic sheet company that is going after AS9100D certification and I am getting hung up on clause 8.2.1 and 4.2, specific to review of customer requirements. Most Aviation Customer PO's reference Terms and Conditions (some quite lengthy) as well as other additional customer procedures.

I may be over-thinking this, but as I study 8.2.1 and 4.2, I am coming to the alarming conclusion that I need to scan every PO for any reference to requirements (other than the normal product description/specs) and if, for instance the PO should reference any customer procedures, I should obtain copies, review them, document the review along with results of the review including implementation actions. The reason this is so worrisome is that many of these referenced documents will reference other documents, which reference other documents, and so on and so forth.........not to mention the inevitably referenced Terms and Conditions that are written by lawyers and legal departments.

All of our PO's are formally reviewed for the product related specifications stated on the PO's and I do review a lot of the systems requirements, but I do not document the reviews or the actions that come out of those systems requirements reviews. What exactly is the intent of 8.2.1 and 4.2 regarding customers' quality systems requirements for their suppliers? I have considered developing a matrix but we have hundreds of customers (not all Aviation but all products / processes will be included in the scope of the AS9100D certification) and it seems like this would be very difficult to effectively manage. How are other organizations managing the 4.2 and 8.2.1 requirements?

Thanks

 

[Big Jim]

Let's make this simple. Even under ISO 9001:2015, 8.2 requires that you consider ALL of the customer requirements and that you REVIEW all of the requirements before committing to supply. You need to look further than 8.2.1 though as it deals with customer communication. 8.2.2 deals with gathering the requirements and 8.2.3 deals with reviewing them.

It is a HORRIBLE business practice to agree to something you didn't make sure you fully understood. HUGE liability.

 

[Mike S.]

Contract review (8.2) is no fun unless you happen to enjoy such things (I hear such people are more rare than Bigfoot). No one seems to want to be "stuck" doing it. Many, maybe most, of the companies I have worked for or with often do not do a good job at this. They wanna get the order, book the order, get started on making it, not worry about "all that paperwork". And flowing requirements down to their subtier suppliers is even more neglected. As Jim said, this can be a very bad thing, but they get by with it so often that they can grow complacent until something blows up (literally or figuratively).

Many customers don't help matters any by spewing requirements, often unnecessary ones, like they are getting paid by the requirement and spreading them all over the place in PO text, terms and conditions documents, "quality code" documents, procurement specifications, SOWs, SDRLs, and others.
To do CR well, you have to allot time for it. It helps to have someone who doesn't hate it be responsible for it. It often requires a multi-disciplinary approach (i.e. you may sometimes need someone from Engineering or Finance to help). Developing a checklist can help.

It many industries is not easy or trivial.

 

[John Broomfield]

On large projects Bechtel had teams of engineers and specialists in construction reviewing drawings and specs for constructability at 30%, 70% and 100% stages of design completion; until the designers got them right.

These Bechtel staff were charged to the client, of course!

They in turn trained the client’s staff eventually to replace them.

 

[Kathy Beagle]

Thank you

Let's make this simple. Even under ISO 9001:2015, 8.2 requires that you consider ALL of the customer requirements and that you REVIEW all of the requirements before committing to supply. You need to look further than 8.2.1 though as it deals with customer communication. 8.2.2 deals with gathering the requirements and 8.2.3 deals with reviewing them.

It is a HORRIBLE business practice to agree to something you didn't make sure you fully understood. HUGE liability.

 

[QLearning]

Hi All,
I'm jumping back into this thread with my own related questions and hope I can get some help regarding 8.2.3.2. We are a contract manufacturer and operate mostly on PO basis. Our customers sends us a RFQ, we review the RFQ and provide a quote back to the customer. The customer then sends us a PO if they like our quote. Our project managers (PMs) review the PO and accept after a review to make sure the quantities, cost, delivery dates are all the same as our quote. Our auditors have always asked us for documented proof of our reviews and the "results of our review." We use an electronic quoting system to help us provide quotes. So, we say that the results of our review is basically the quote we provide. Auditors have not really liked this. Additionally, our PMs review the customer PO and compares against the quote. If everything matches, our PMs accepts the PO. Auditors say the accepted PO is not really sufficient. Help!! Thanks.

 

[Randall Beck]

We are kind of in the same service industry. Our contract review basically consists of the "PM", or in our case production manager and Quality manager, (a member from the technical and quality departments) reviewing the PO for concerns or additional risk and if there is none found, each signs or stamps the customer PO as reviewed and approved. This method is clearly documented in our written procedures and we have never had an issue in 15 years during AS9100, NADCAP, MEDACRED, ABS or DNV audits. As long as you document your method of verification, and review, and there is a visual documented stamp or electronic signature and it is documented, auditors should not have an issue with this.

You don't however specifically say if your PM physically signed the PO or not. If not make that change and document it and you should be good. There is no reason to over complicate a system that meets requirements and suits your business. That may be the missing piece the auditors want to see. Just my opinion.

 

[John Broomfield]

Do you show evidence that you’ve reviewed the RFQ for any unusual requirements, resource demands and for any scheduling conflicts before you quote?

Contract Review is a bit of a misnomer.

It is the basis for your promise (aka quote) that may risk a failure to fulfill requirements.

 

[Randall Beck]

RFQ should always have the documented authority figure's signature as reviewed and approved by signing the RFQ. Your right this is really where the deep dive contract review should take place. In doing so the RISK, the obscure requirements, regulatory requirements, testing requirements and everything in between must be reviewed to ensure a process exists or can be created to ensure conformance as quoted and produced for sure.

For us the second step is verifying the PO matches the RFQ, if there is one, and if not, that the that existing processes are in place to perform the manufacturing process to the requirements. Checklists can be very useful documented records of review that conveniently have the appropriate signatures that are procedurally responsible.

Just ensure that procedures detail who is responsible for, and when and where the reviews are documented. Every organization is different but the requirements are the same.

 

[Big Jim]

One of the more common ways of meeting this requirement is to have a contract review checklist showing that you did indeed thoroughly go over the RFQ and Quote. A contract review checklist helps to align the RFQ to your system, making it easier to evaluate. It also provides a place to show that you performed a risk review.

That said, the wording in 8.2.3.2 is awkward. It requires that you keep a record of the result of the review. They didn't say a record of the review, they said a record of the result of the review. The result of the review can be very ambiguous. The result of the review could be a completed Quote. You reviewed it and as a result you sent it off.

I have a feeling you will not win the argument, but the writers of the standard need to get their act together and get rid of the ambiguities.