Control of nonconforming product - Software Company - ISO 9001, Clause 8.3

[meensy]

Hi,

I do not know whether i am interrupting the current thread or link. But thought this question suits in this forum.

I am writing a process for 'Control of non-conforming products' for software company. The company has products as well as projects.

I am unable to decide the meaning of the wording 'deal with nonconforming product by taking action to preclude its original intended use or application'

Can anyone explain this with example.

Regards,

 

[s-bell]

This basically means that once non-conforming product has been identified, the procedure should ensure that the product does not make it to the end user.

In terms of manufactured product this could be controlled through labelling with barcodes etc that if a defective component is discovered the barcode label applied will not scan to authorise shipping of the product.

I am not familiar with the software world but I suppose any offending code would be quarantined and a subroutine put in place preventing the software from passing any test performed on it.

Hope this helps.

 

[Claes Gefvenberg]

Hello meensy, and welcome to the Cove

Hi,

I do not know whether i am interrupting the current thread or link. But thought this question suits in this forum.

No worries, you interrupted nothing. You started a new thread, and the forum is appropriate.

I am unable to decide the meaning of the wording 'deal with nonconforming product by taking action to preclude its original intended use or application'

Can anyone explain this with example.

That would be ISO9001:2000, Clause 8.3c, right? In essence you need to keep it away from the orginally intended user. You can:

• Lock it up
• Put it on hold in the MPS system
• Reassign it for a use it is better suited for
• Smash it with a hammer.

/Claes

 

[RoxaneB]

• Lock it up
• Put it on hold in the MPS system
• Reassign it for a use it is better suited for
• Smash it with a hammer.

My vote is for the hammer.

 

[Marc]

I think the first key here is to ask what, exactly, do you define as nonconforming product. Are we talking the code its self? Defective pressed distros (distribution CDs)? Are we talking in-house or customer returns?

We can offer more complete help if you provide us with a few more details.

 

[Cari Spears]

'deal with nonconforming product by taking action to preclude its original intended use or application'

Hi meensy - Welcome!

Preclude, in this context, means to "make it impossible". So the standard is saying: Make it impossible to unintentionally use or ship nonconforming product. When I want to explain it simply, I say it means "protect the customer".

The actions we take to protect our customer from receiving nonconforming product is generally a red nonconforming product tag and quarantine areas. If the disposition is rework - we keep the red tag with the product during rework operations. If the disposition is scrap - we paint it red so no one can mistake it for good product. I've worked at other places where they bent the clutch plate, or broke the rivets at the bracket, or somehow otherwise destroyed the part - making it impossible to install. Our products are different than yours, but hopefully this gives you a starting point for figuring out the best way to make it impossible to ship or use your type of products.

 

[qualitygoddess - 2010]

Also at a software company

I am writing a process for 'Control of non-conforming products' for software company. The company has products as well as projects.

I am unable to decide the meaning of the wording 'deal with nonconforming product by taking action to preclude its original intended use or application'

Can anyone explain this with example.

Regards,

Also with a software company. When Engineering produces a revision to a product, we take a series of steps to insure any customer does not get the previous version/now nonconforming product. These steps are outlined from a design review and documented on an engineering request that travels through the company. It requires an action and then approval from the various areas that have to make updates: engineering to master code files; sales to master revision files for firmware; marketing to update the website with the new software drivers, etc. We have one person whose job is to make certain all previous tasks have been done before the engineering request is closed.

During development work, if engineering produces code that is tested, but does not "work", the file is named to reflect the obsolete nature of the file and saved in a network directory that would never be accessible for a customer's part. The engineer also makes a paper record called an Engineering Work Record, and this explains the nature of the nonconforming product. This record gets filed with an engineering request after design verification is completed.

In our chip programming area, the programmer automatically kicks out nonconforming product. We mark the chip tubes with nonconforming tags, and have a regular material review board (MRB) meeting to disposition the chips.

These are a few examples of things we do to prevent software or firmware from getting out of the building. Our product complaints are very low, and customer satisfaction is high. We use a lot of checksheets in our work, to make certain nothing is missed. We also have a lot of double-checks by others to verified work has been done.

--QG

 

[Marc]

When Engineering produces a revision to a product, we take a series of steps to insure any customer does not get the previous version/now nonconforming product.

I would see this as a distro distribution nonconformance as opposed to a code nonconformance - Where does responsibility lie in this specific example, and how would the nonconformance be worded?

Interesting thread. I'd like to see more software oriented threads here.

 

[qualitygoddess - 2010]

I would see this as a distro distribution nonconformance as opposed to a code nonconformance - Where does responsibility lie in this specific example, and how would the nonconformance be worded?

Interesting thread. I'd like to see more software oriented threads here.

Yes, you are correct in your thinking. We have to prevent the use of the old revision on future orders. We don't provide CDs, but rather via download on a website. We use the engineering change process to manage the change. The process requires 3 or 4 steps by different departments to make certain the old revision is obsoleted. In the procedure about nonconforming, I refer to the instruction of engineering change to specify what to do with obsolete software.

 

[meensy]

Hi all,

And thanks for your replies it really did help me to clean up my thought process.

Are we talking the code its self? Defective pressed distros (distribution CDs)? Are we talking in-house or customer returns?

We can offer more complete help if you provide us with a few more details.

As far as clause 8.3 is concerned i believe it talks about the non conformity in the product found before and after delivery of product. Also talks about delivery non conformance.

However, it is not very clear about the action to be taken if non conformity is found after the product is delivered.

After reading all the replies i feel that in software industry, 8.3-a will be used mostly. 8.3-b also might be used in some cases. We may not need to use 8.3 - c as we can most of the time repair the code and need not throw it altogether unless the requirement itself turns upside down when the product is ready for use.

As regards, distribution non conformity i feel we need to take care that bad release is not sent to client. This also will form the part of 8.3 as pointed out rightly.

So in our terms i need to take care of two processes that is testing and release also configuration management.

Right?

Thanks and regards,