• No se han encontrado resultados

LOGROS Y OBJETIVOS NUCLEARES CUMPLIDOS

In document PLAN ESTRATÉGICO (página 41-52)

Equivalent to subclause 7.2.2 of ISO 9001:2008

8.2.3.1 (No subclause title)

Once you determine product requirements, you must review them. This is really nothing more than a sanity check: Do we understand the requirements and can we really meet them? Most people have had experiences with organizations that promised to do something but badly missed the mark. The intent of this element is to keep you from being one of those organizations.

ISO 9001:2015 requires that you review the order or contract prior to committing to supply it. In practical terms, this is usually the acceptance of the order or contract into your own production system. The customer may have already placed the order, but you haven’t formally committed to supply it. This review can be performed by anyone, even the person who took the order in the first place. The review could even be performed by a computer. Specifically, the review includes the following items:

Customer requirements. We discussed determining these requirements in the previous section. Now we’re making sure we got the story straight. This is the single most important category of requirements because it comes directly from the customer. Some typical checks that organizations make when performing this review include:

Delivery date requested by the customer

Quantity requested by the customer

Product name or part number referenced by the customer

Price requested by the customer

Any tolerances and specifications requested by the customer

Paperwork, certifications, or reports requested by the customer

Follow-up actions after delivery requested by the customer

This check can be done by a person or by a computer, but either way we’re answering two questions:

Did we correctly record the customer requirements?

Do we have the ability to meet the customer requirements? If we can answer yes to both of these questions, we can move onto the next item to review. Requirements not stated by the customer but necessary. Customers rarely ask for everything they need. They make assumptions about the product or service, and they’re also ignorant about certain aspects of the product or service. In both cases, it’s your organization’s job to fill in the blanks. Many of these requirements come from internal specifications or standards that are applied automatically unless the customer requests otherwise. Just make sure you have standards in place to cover product requirements not addressed by customers.

Requirements specified by the organization. These can be anything else you’ve decided your product or service must meet. They don’t come from the customer, and they’re not strictly needed to fulfill the product or service. Here are some examples of extra requirements you might apply to your products or services:

Product tests done strictly to satisfy internal requirements

Arrival of service personnel before appointment time to set up

How customers are to be addressed (for instance, “Sir” or “Ma’am”)

absolutely necessary)

The correct dress and appearance of employees

Use of marketing materials

Placement of logo on product and use of corporate colors

Method of cleanup

Use of recycled or biodegradable materials

Use of “fair trade” raw materials

Upholding of ethical standards

Asking the customer to sign certain paperwork

Statutory and regulatory requirements. As we stated earlier, this is what the law requires of your products and services. Depending on the type of product or service you provide, each contract might get an exhaustive legal review, or you might face a much simpler situation. If you have a highly regulated product, this was likely identified during your planning for risks in clause 6.1. Simply apply the appropriate amount of scrutiny to your orders and contracts in accordance with their statutory and regulatory exposure.

Conflicting requirements. It’s not uncommon for an order or contract to involve many exchanges of information, some of which conflict with one another. This is especially true in this age of multiple communication channels. The more communication that takes place—especially among different modes and with different parties—the greater the chance that details will become confused. Just compare all the different communications that may have taken place and make sure that there aren’t any conflicts. Here are some examples of how requirements can differ from those previously expressed:

Specifications that accompany the order don’t match the specifications on file.

The customer placed an order via telephone and purchase order, but the purchase order requirements differ from the telephone order requirements.

Two different customer representatives are asking for contradictory requirements.

The customer becomes confused and requests different delivery dates.

The customer asks you to do something that isn’t in the contract.

If you encounter instances when requirements differ, contact the customer and resolve the conflict. Of course, keep a record of contacting the customer and what the final agreement was.

Undocumented requirements. If the customer doesn’t provide a documented statement of requirements, as is the case with telephone orders, you must confirm the order back to the customer. This can be as simple as repeating the requirements back to the customer to make sure you understood what he or she wanted. Many organizations email the order to customers so they can review it themselves.

8.2.3 FREQUENTLY ASKED QUESTIONS

We don’t take orders or write contracts with customers. All we do is work

against a schedule our home office sends us once a week. Can we

exclude the requirement of reviewing product requirements?

No. The schedule represents your product requirements (at least in part) and you must review them.

8.2.3.2 (No subclause title)

You must keep a record of the review of product requirements. This record can be a signature, initials, stamp, form, or any other simple indicator. It’s often affixed directly to the order or contract. Personnel working within the system should understand what constitutes the record of review and what it represents. Simply having a copy of the order or contract doesn’t constitute a record of its review.

In document PLAN ESTRATÉGICO (página 41-52)

Documento similar