The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : I need help creating a practical preventive action process


shane
18th February 2003, 05:15 PM
I've been involved with the implementation of ISO9000 quality systems since 1991. I lead teams that implemented the 1987 procedure at a very large company, and at the very small company that I've been with since 1993. We successfully upgraded to the 1994 standard, and have since added a second facility. All the while I've managed to get away with the fact that I really DON'T understand or perform Preventive Action.

With the additional focus on this clause in the new standard I know that we have a real process in place, just having it documented will no longer work.

Everything I've read to date basically repeats the standard. Nothing gives what I believe to be good real life examples.

We are a small contract manufacturing company that assembles SMT and Thru hole printed circuit boards. We have a solid "Blue Color" approach to our Quality System. We operate on a small and very tight budget, no fancy toys.

Is there anyone out there that is willing to share some practical, and very basic practices that I can use as building blocks to create a true working preventive action process?

Please remember, we are small, and we don't have the resources to have a person or group dedicated to reviewing data from all of our processes or customers on an ongoing basis.

Any practical examples would be greatly appreciated.

Thanks in advance,

Shane :bonk:

p.s.

Please excuse me if my message seems desperate, it's more the frustration of trying to make something that is so poorly defined into a working process.

tarheel
18th February 2003, 05:26 PM
Don't feel like the lone ranger. PA is a very difficult thing to wrap your hands around sometimes. After 20 years, I have come up with a system that has passed QS-9000, 1994 and 2000 ISO. I created a form on Access and I put it on the floor. I push our operators for suggestions that will help them do their jobs better. For example, I had an operator come up with a way to bypass some data entry that was taking up to 10 hrs per week of her job. I documented that as a preventive action. Another operator questioned why we were using a particular brand of very expensive wrap when another cheaper wrap would do. I documented that also. I have found this to be a gold mine for PA. I've also found with lots of auditors that they will generally be very broad in their definition if they see some system working. Try to broaden your horizon of what you consider corrective actions. For example, how about safety. If you have a safety program that fixes potential safety hazards, isn't that a preventive action. I actually included safety in my quality manual and my auditor loved the fact that I had broadened the very narrow definition that is in the ISO standards. Broaden your horizon, you may be surprised what you find.

M Greenaway
18th February 2003, 05:31 PM
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.

I personally feel that tools such as FMEA and SPC are more robust examples of preventive action, as you take actions on the system before you have made bad product. However if you have no resource for setting up, running and analysing such systems it is basically a non starter !

Bob_M
18th February 2003, 06:29 PM
tarheel said:

Don't feel like the lone ranger. PA is a very difficult thing to wrap your hands around sometimes. After 20 years, I have come up with a system that has passed QS-9000, 1994 and 2000 ISO. I created a form on Access and I put it on the floor. I push our operators for suggestions that will help them do their jobs better. For example, I had an operator come up with a way to bypass some data entry that was taking up to 10 hrs per week of her job. I documented that as a preventive action. Another operator questioned why we were using a particular brand of very expensive wrap when another cheaper wrap would do. I documented that also. I have found this to be a gold mine for PA. I've also found with lots of auditors that they will generally be very broad in their definition if they see some system working. Try to broaden your horizon of what you consider corrective actions. For example, how about safety. If you have a safety program that fixes potential safety hazards, isn't that a preventive action. I actually included safety in my quality manual and my auditor loved the fact that I had broadened the very narrow definition that is in the ISO standards. Broaden your horizon, you may be surprised what you find.

Your examples sound more like Continual Improvement of a process. The examples saved money and time, they did not prevent a non-conformance.

I'm new to this arena but this is my understanding of the terms:

Corrective: Correct a problem that HAS occurred and prevent it from happening again.

Preventive: Identify a POTENTIAL problem and correct it before anything actually happens. (I feel these are seperate from issues found during a corrective action).

Continual: Making improvements to any part of the company, Quality, Safety, Process, Timeliness, etc.

If I'm way off please tell me, because I just finished updating our procedures/forms to reflect this idealogy.

Bob M

Laura M
18th February 2003, 10:56 PM
I am working with a less than 100 people company. 15 "managment" - QC, Prod, Eng, PUrch, Sales, Accounting, Shipping and a couple schedulers and clerical help. The argument there was "we prevent problems everyday - you can't expect us to waste time writing it down." I told them I wanted the big magnitude stuff. I also heard people talk about things they wanted to do, but the CEO has tight purse strings, and only wanted "projects" as he called them, to occur when he authorizes it.

So our process is that once/month I send an email to everyone with an email account. I state: "It's time to update our monthly preventive action list. Please respond with any potential problems you have encountered. I will compile the list and forward to Mr. CEO for prioritizing."

It has actually turned into a CI and PA list - but I choose to not distinguish. It is the most comprehensive list of improvements I have seen since I started there 2 years ago. Plus, it puts the responsibility for updating the status of the list and providing the resources directly in the hands of the CEO - or "top management" review as required by the standard.

It worked for me. It was KISS, within the paperwork parameters that the company likes to deal with, and managed to get the CEO involved by meeting the above 2 conditions. I'd appreciate any feedback.

What is it lacking - real proof that it prevented a problem - but we have evidence of implementation.

Examples:

Create a bigger staging area in shipping to prevent shipping errors. Audited and unaudited parts are too close together.
(They've had shipping errors with unknown root cause, so I see this as preventive) Also - increase font size of part number on shipping label.

Put quality system documentation on the internet to "prevent inadvertant use of obsolete paper copies" (Guess who wrote that one - and implemented)


Laura

Claes Gefvenberg
19th February 2003, 03:19 AM
Hullo Shane,

I have a feeling you're not the only one beginning to sound desperate when PA is discussed. Most of us are struggling with it, whether we admit it or not. Ok, how about this?

Have a good look at 4.1.

We have to identify our processes and their application (4.1a). Having done that... why not regularly go through them with the "what can be improved here?" eyes?(4.1f)

FMEA could be used to good effect with that set up, but there are other ways too. Anyway, actions taken as a result of this approach could be regarded as "true" preventive actions. Being based on our core processes they should also prove useful.

I have to say that I like Lauras approach too. Talk about getting people involved... How many replies do you generally get to that mail?

/Claes

M Greenaway
19th February 2003, 05:26 AM
My fear of suggestion schemes is that we may end up meddling with the process, and making things worse, i.e. overadjustment of the process. However some of what Laura has found through her suggestion scheme should have been picked up at audit (which is perhaps just another suggestion scheme).

VascO
19th February 2003, 08:05 AM
I´m sure your Quality System is based and running in a preventive point of view.
Why not take advantage on that.

The fact that your processes are running in a controled way, is because there are some PA behind.
Of course there are other ways to implement PA, but my sugestion is one of them
My sugestion: a table for each Process, with the following or other collums

Process: XPTO

Task;Pre conditions/control;Verification/registation; Corrective action


Sorry for my english.

VascO

Claes Gefvenberg
19th February 2003, 08:32 AM
Hi Vasco, and welcome to the Cove. :bigwave: And do not worry about the english. It seems perfectly understandable, and that is all anyone asks for around here. I should know, I'm not a native speaker either ;)

Your setup sounds similar to what I had in mind.

/Claes

Mike S.
19th February 2003, 10:58 AM
Shane,

PA/CA can get a bit confusing for sure. Here's another angle. Let's say you have a defect or customer return/complaint (I know, it is rare!) on a certain product "X". You figure out what went wrong, and fix it for product "X". That's CA. Now, let's say you have similar but different products "Y" and "Z" and you can imagine how it might be possible the same problem could happen to them someday, so you take the same actions on product line "Y" and "Z" as you did for "X". That's PA for lines "Y" and "Z", IMO. Make sense?

Ken K
19th February 2003, 12:14 PM
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.

Laura M
19th February 2003, 12:27 PM
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?

shane
19th February 2003, 03:05 PM
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:

Chris May
20th February 2003, 04:43 AM
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

AnneG
20th February 2003, 11:13 AM
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)?

Ken K
20th February 2003, 02:42 PM
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.

AnneG
20th February 2003, 04:24 PM
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.

shane
21st February 2003, 05:18 PM
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

tarheel
21st February 2003, 05:22 PM
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: