I need help creating a practical preventive action process

K

Ken K

Shane,

This subject of CA / PA has been debated since the Cove existed and more than likely, way before. You'll probably come away more confused than before you asked for an example.

My answer to you is define PA as it applies to you and your company. There are tons of definitions floating around and they basically say the same thing...trying to prevent a potential problem before it happens. ( a crystal ball helps and I'm sure some won't agree with this definition)

We just had a ISO17025 audit and our assessor asked for an example of a PA. I presented this:

Our environmental chambers and ovens are located on a second floor mezanine out in the open. Below us is the prototype lab which makes molds.
The chambers and ovens were calibrated a couple of weeks ago. The person doing them took an air temperature reading on the mezanine - 110F. Plus the dust generated from below was starting to clog the condensors. He recommeneded we move them to a confined area.
That was the PA I presented - moving equipment - and the auditor agreed. And it fits our definition of PA.

Good luck.
 
L

Laura M

Ken - yep that makes perfect PA, and that's the kind of thing that goes on, but folks have trouble with the documentation end. How do you track and show management review of PA?
 
S

shane

Thanks

Just wanted to thank everyone for their inputs. Several of the suggestions are things that we have done in the past and it is nice to know that others are having success with these types of actions.

I guess the bottom line is to just try to be more diligent in gettng things documented when you do come across them.

Thanks again,

Shane :bigwave:
 
C

Chris May

Shane,

Like yourself, I am involved in PCB assembly (Surface Mount & Conventional).

I believe from what you said, you are involved in contract manufacture......which is not a bad thing.

However, I have the luxury (because we design and build our own products) of having an input into the design and layout of PCB's.

Preventative Action here, involves me looking at proposed layouts & designs and using a known set of design rules (experience also), recommending changes to layouts that will prevent manufacturing faults.

The documented evidence in this case is a unique change request form detailing recommendations.

To some extent, a poka-yoke approach is used.

For example, we had a board that was going to fitted with 2 x VDR's (voltage dependant resistors). Both blue. Both 5mm pitch. But one was a 475v & the other was a 275v.

You can see the defect opportunity here. We changed the 475v one to a 7.5mm pitch, so now they will only fit in the correct position.

Another example is with electrolytic caps. I have now "educated" the design layout guys to always have the -ve end facing the same way on all boards. This prevents the confusion during assembly, of mis-orientation because on all boards now, the -ve end always faces "up".

The design rules are the documented evidence of preventative actions in this case. These will be reviewed and improved as technology / products move on.

In a previous company, which was subcontract manufacturer, I dealt with the customers design guys using a similar set of design rules. The handshaking in this case were my recommendations for change to improve the test yield prior to the manufacturing run.

Obviously all cost savings were shared out (!!??!).

The documentation / feedback form was logged with proposal and response.

Hope this helps,

Chris May
 
A

AnneG

Does anyone have any experience implementing preventive action where the product being produced is software?

After every release of a new version of software, we conduct a meeting with all software development team members where we try to determine "what went wrong" and "what went right" during the development process of the latest release. From this meeting action items are developed in an attempt to improve our processes. This type of activity seems to deal more with "corrective action" since any problems encountered have actually already occurred.

How would you go about identifying "potential nonconformities" (ones that have not occurred yet)?
 
K

Ken K

I'm no software guru, but you say you have a meeting after the software is released. What about while it's being developed? Are changes made to the software because of bugs or potential problems before release?

I would think you could use a PA for these.
 
A

AnneG

Prior to a new release, there are several levels of testing that take place to check for bugs and verify that the software meets requirements (unit testing, software qualification testing, regression testing, acceptance testing, etc). In addition, before we even reach the stage where testing can occur, code reviews are conducted to ensure compliance with coding standards, etc.
 
S

shane

Well I've Got One Anyway!!!

Well, thanks to everyone's inputs I finally revised the procecdure, created a new database and form for our Preventive Actions and got it all signed off.

I even managed to enter one that we had been working on the past few weeks.

I also took the suggestion of trying to get the entire facility involved and sent out e-mail requesting any information on anything that may have gone on the past 3 months that we could consider Preventive Action. So far no replies, but we do have the one!

Thanks again all,

Shane
 
T

tarheel

P.Action

M Greenaway said:

tarheel

I hate the old corrective/preventive action argument, however arent suggestion scemes like yours actually corrective action, as you are changing something that has already occurred.

If I fix an electrical cord before someone gets shock, that is preventive. Maybe the other actions can also be construed as continual improvement, but am I not preventing unnecessary cost if I can be more efficient? (maybe a stretch, but I've found this approach has worked with many different auditors). It could be they don't understand it any more than we do.
:thedeal:
 
Top Bottom