› "Outsourced Process" vs. "Factored Item" in ISO 9001:2000

If you buy a subassembly complete, when is it an "outsourced process" and when is it a "purchased item"? I read the ISO document GUIDANCE ON 'OUTSOURCED PROCESSES" and it was not very helpful in answering my question.

Our company is in the electronics assembly business. If we buy a sheet metal component made to our specifications, it is considered a purchased item. If we buy a standard off-the shelf power supply to incorporate in an assembly we manufacture, it is considered a purchased item.

Now, if we have an assembly that we sell to a customer made completely outside, is it a "purchased item" or an "outsouced process"? In the old standard, this would have been considered a "factored item"?

If you outsouce a product in total that you have the capability to do in house and is your core business, is that an "outsourced process" or is that "purchasing" a product?

Where do factored items fit in the ISO 9001:2000 standard?


qdigest 3/19/2002

This is an excellent question, but one I cannot answer--and would not if I could--because it is up to your organization to answer the question. The real question here is not "Does the 'reconfiguration activity' fall under the ISO 9001:2000 requirements in Clause 7.3, Design and Development?" but "Do the organization's procedures reflect what the organization actually does?" Remember that ISO 9001, whether the 1994 or 2000 edition, comes down to "Say what you do, do what you say you do, prove it (and consider what can be done to improve how you do what you do [if you are to pursue continual improvement])."

I think that your president is right in that the procedures and documentation you have in place are creating an impediment to satisfying the customer's needs when there is an urgent need for delivery of a product--it would be one thing if your company couldn't produce and deliver the product to satisfy customer requirements because of the urgency of the customer's needs. However, since it sounds like this is a common occurrence and not a once-in-a-while emergency situation, it should not be treated as an "urgent" situation but the normal speed of a good part of your business.

What is really needed here, based on what you have told me, is a streamlining of the paperwork that exists, most of which is not required by ISO 9001:2000. Remember, ISO 9001:2000 requires only the following documentation relative to design and development activity:
Records of the results of design and development reviews, verifications, validations and changes and any actions necessary to correct the design and development activities in response to the results.

What any organization needs to do is plan their design and development processes to satisfy the requirements of Clause 7.3 in such a way as to make the processes efficient, effective, consistent in meeting customer requirements and as repeatable and productive as possible. In your company's case, it sounds like your procedures were developed to handle the majority of design, development and production scenarios, but with a significant minority of scenarios not taken into account.

I am not an expert on management system implementation, so I cannot advise you on the best plan of action based on lots of experience, but what I would do is review your present procedures for design and development by flowcharting the various steps captured by your present procedures and then separately flowchart several examples of actual activities within your company's design and development and production operations in the last few months. Compare the flowcharts for actual practices within the organization with that of the documented procedures. It may be that you need simply to link the existing documented procedure to a separate loop to be followed when reconfiguration is involved or you may need to rebuild your procedures to take into account a parallel system for reconfiguration activities. Not everything in any company is going to fit into a rigid mold, unless you manufacture a basic product like paperclips. In addition, look at every piece of documentation you presently have and ask this simple question: "Do we really need this for our business to function?"

I would invite other forum members to look at the question that was posted and provide any input they have, including additional questions about this situation, on what should be considered by this company or what they have done in similar situations. Remember, there is no wrong answer if the forum ultimately helps your organization improve its processes to achieve ISO 9001:2000 conformance and pursue continual improvement.

sharwood 3/19/2002

Thank you for your response Mr. Mroz. I had actually written our procedure to contain a separate loop to be be followed when reconfigurations are involved but based upon your statements in paragraph #3 your response , it does not meet the minimum requirements of the standard. This is how our procedure currently reads:

A product reconfiguration is a current product with a minor change made to its components. Reconfigurations are given a new part number to distinguish it from the original product. Product reconfigurations fall under the responsibility of the Engineer with the original product. The Operations Manager or responsible Engineer creates a Bill of Material for this configuration by copying the original product's BOM and making the necessary changes. The responsible Engineer then creates a new Manufacturing Packet and/or Product File or modifies the original Manufacturing Packet to include this configuration. The responsible Engineer creates a product history file, places all newly created documentation into it and places it in the Design Files for future reference. Any file that contains documentation on a reconfiguration will not contain a Design Plan or any other documents that are required for a new design. These documents will have the word "Reconfiguration" written on the front of the file folder.

The Engineer is responsible for making sure that all activities that are needed are completed before releasing the product to production."

As you can see our procedure does not require records of the results of design and development reviews, verifications, validations and changes and any actions necessary to correct the design and development activities in response to the results.

But this was really my original question: "Are records of the results of design and development reviews, verifications, validations, changes and any actions necessary to correct the design and development activities in response to the results REQUIRED for product "reconfigurations" or may we bypass these activities and these records?

Basically, our current procedure only requires a Bill of Materials (to document the product requirement changes) and a Manufacturing Packet (this tells the technician how to assemble the product, what to test/measure/inspect and how, and what the acceptance criteria is. It also is where the final inspection results are recorded).

qdigest 5/14/2002

Sorry for the delay in responding. Based on what information has been provided in the original message and this follow-up message, which includes what I take to be your organization's documented procedure for design and development changes per Subclause 7.3.7, Control of Design and Development Changes, the whole issue comes down to two words in 7.3.7: "as appropriate".

Remember that the text of Subclause 7.3.7 states:
"Design and development changes shall be identified and records maintained. The changes shall be reviewed, verified and validated, as appropriate, and approved before implementation.... Records of the results of the review of changes and any necessary actions shall be maintained."

Thus, the first question becomes:
Is review, verification and validation of changes to the design of our product necessary and, if so, to what degree? If the changes to design and development of a product could have a significant impact on the product or could result in increased variation in the output of the product to spec, then you need to have review, verification and validation processes in place to ensure that such variation and impacts are controlled, with records to show that such processes are being applied when changes occur.

If the changes being made are minor and have no impact on the product and do not cause variation in output, then the processes may need to be minimal in nature and likewise the records. Your organization needs to determine whether the changes are controlled by your existing procedures. If nonconforming product or processes occurs when changes occur, then there is a problem.

The second question, however, is:
What are we doing to approve of these changes? Note that the "as appropriate" does not include the approval of changes to product design, and I saw nothing in your procedure to indicate that any sort of approval is taking place. There is also a sentence that I did not cite that requires evaluation of the effect of changes.

The third question is:
Do we need a documented procedure at all or can we direct the Engineers to follow consistent processes that ensure that review, verification, validation, evaluation and approval take place as needed and that the required records are created? I think the problem is that you are trying to create a single procedure for everyone to follow that will minimize documentation, but you may not need documentation and instead need to improve your records system and perhaps the actual procedure. You should consider instead taking your existing documented procedure, sitting down with all or a cross-section of the Engineers who are involved in design changes and review that procedure against the requirements of 7.3.7 (and the rest of 7.3 for that matter). The goal should be to eliminate the documented procedure if that is a workable solution, as long as the Engineers will know what procedures they are to follow when changes occur. If they cannot, then a documented procedure is necessary. Then, see if the Engineers know of a simple, easy-to-do way exists for them to record the changes process that is workable and value-added.

Thus, as I noted in my first response, I cannot answer your question, because I am not able to evaluate whether the procedures you are presently using do the following:
1. Control variation in output when changes to design occur.
2. Involve the approval of design changes when they occur. Perhaps the Engineer responsible has authority to approve his/her own changes, but this is not stated.
3. Produce records of design changes, who made and approved the changes and whether the customer is aware of the change (it sounds like the customer is driving the changes, but if responding to customer requests affects the changes and the product, the customer needs to know).
4. Lead to review, verification and validation of changes when needed. Your organization's history of the product should help determine how much review, etc., is required.
5. Result in conforming product that meets customer specifications and meets or exceeds customer expectations. The whole point of this is to make sure the product produced satisfies the customer.

To sum up, you do need records of design changes and approvals and you need records of review, verification and validation activities to the degree those activities are deemed necessary. You do not necessarily need a documented design change procedure unless the Engineers and others involved in changes cannot otherwise conduct design changes consistently. You need to determine whether your existing processes and the records they produce meet the requirements of 7.3.7.

If your registrar disagrees with your present procedures and records system, determine whether what the auditors are asking for is reasonable based on your reading of ISO 9001:2000 as it applies to your organization and, if not, what will satisfy the registrar, your organization's way of operating and your customer.