posted 10 February 2000 01:18 PM               

You may want to try the old "80/20" rule. What you want to find are the Vital Few in the Trivial Many. As your program becomes more stable, you may elect to reintroduce some of those you may have been on the fence about removing. Your goal is to increase the efficiency, so your steps towards making it more user friendly should work out.

Additionally, when should a CAR be issued? Many folks don't know the answer, so when in doubt, issue a CAR (in reality as Barb B. says; train, train, train!). This is bad practice. It gives the program a bad taste. Pretty soon, no one reports trouble, because CARs they issued, some for good reason, some not, have gone unanswered for months! Why bother? The system bogs down because there are many useless CARs in the system, no hope for improvement. Again, the Vital Few need consideration. I would also say that "System Knowledge" needs to be taught (my own opinion here).

An example: a CAR is issued by an inside sales associate because someone called up, upset that a product they bought was missing a key piece of hardware. The system that produced the problem operates at 99.98% efficient. Was this a bonified reason to issue the CAR? Things to consider: Severity of the problem, Occurrence of the problem, point of Detection. Looks familiar? It is part of the FMEA risk rating system. Develop an RPN (risk priority number) and address those that require addressing. Again, the 80/20 rule applies. An organization has limited resources, and chasing a shadow won't get it done, only worse!

I inherited a CAR program that had issued 367 CARs in a 6 month period. I went through them all, classified them, and came to the conclusion only about 12 required corrective action. Needless to say, no one was filling out the CARs before, but they fill them out now. They only get them when they are needed.

I'll be out your neck of the woods most of next week, so let's meet at Honey Girls for lunch if you like.

Regards,

Kevin

posted 16 February 2000 09:38 PM              

I bumped into your forum while deleting old bookmarks off my browser. The caymen cove link still worked after 3 years!

More to topic. I took an interest in two things. #1. Dominic wants to get his data in a fine detail of 70 "things". To me he should keep after them. In any factory that i admire, i really marvel at their attention to detail. That is because they have gotten the easy 80% and were on the last 20%. To get the last 20% you really need detail from all areas, the more the better. Can you imagine the level of detail that is needed when you are working on the last 5% of your i- If you find a way to deal with the data please get back to me........which leads me to #2 which is Kevin's point about inheriting a +350 CAR back log (sounds like maintenance work order system). What's wrong with the +350 Car backlog is our inabilty to digest the data. I have seen the same thing in safety programs that want employees to report even potential hazards (ie air hose are similar in color to the floor. tripping hazard......i don't think the color is the problem). But aside from the pile of work, people....real live employees were reporting stuff. The problem was in what they were told to report or the resources allocated to handle the information or nobody knew what to expect. Maybe that situation arose because people thought the QA dept was a combination maintenance/IT dept!

I think Dominic's solution may lie in relaying the workforce that the CARS are only information on how the systems are working. You can't address all them unless you are "super dept" but you can use them to focus on the critical 12. Ask Kevin the impact of those 12 CARS he distilled from over 350. I would guess pretty good.

Maybe a suggestion: in the paper work it would be clearer if the 70 "things" there were put on say five sheets with only 10 - 15 codes. The writer might have to chose but would be much happier with a clearer and perhaps more specific paper. They could also be dept, site or even classification specific.

Education and delivering a clear understanding that the QA program collects data, analyses it and issues reports on the performance of "systems." It usually doesn't have the stuff to fix them. If these two things are up front I think you will be able to handle all the data.

Greg Jobe

posted 01 March 2000 05:39 PM               

A nice job of explaining! Your suggestion to compile the data to make it more meaningful is a good one. Working on a QS is never ending. Each NC should be reviewed for its merit and dealt with in a way to make the QS more effective. By itself, it may be meaningless. Get a pile of "hose in the aisleway" notes, you might just want to investigate.

I am glad the shortcut to the Cove still worked. I am impressed with the popularity of Marc's growing creation!

Regards,