What to do with broken parts?

Imagine You do run a production company. Such a real one, not an imaginary one. And this company do produce something.

And, of course, from time to time as we do live in a real world, the product comes out a piece of crap.

What to do with such a crap?

ISO 9000 says…

(…)prevent bad outputs from entering production again(…)

Which is good. If You detected a broken part or a broken product it must not be used or sold.

The easiest way to achieve that it is to scrap it and throw it away.

Store them for investigation

Sometimes however bad parts should not be thrown away. There are plenty of modes of failure. Some of them are random, some are statistically important. For an example You may observe that one of each 100 pieces of Your MP3Players do turn-on when plugged to USB port while 99 pieces do not. This is not a critical failure, but it may turn critical after some time. So it would be best to know why does it happen.

Of course Your Research&Development department is under a full load and it may not be able to react in timely manner to each single failure. And even if they would, they also need some statistics. For an example they must break a piece to see what is inside. And of course such an operation renders that piece inoperable, so no more work can be done.

This means, that if You are observing a repeating, statistically significant failures of unknown origin then You must collect samples.

Prepare some warehouse storage, mark each broken part sample with clear description:

• when it was discovered it is broken?
• when it was manufactured?
• add tracking data so You may pin point all components tracking data;
• who tested it and found out the problem?
• what the problem exactly is?

Describe the problem

And no, “it doesn’t work” is not a good description. Describe step-by-step how to reproduce error. Describe all numeric value and measurements You made. Describe what You have seen. And, equally important, what You think You should have been seen.

Only then Your Research&Development department will be able to do the job.

Be prepared for long-term storage

This depends on the load which is put on Your Research&Development department and failure criticality. I think that for non-critical errors You need to be prepared for 3…9 months long storage. Remember, this is not only due to Research&Development department delay, but also due to the fact that You must collect a reasonable (5…10 pieces at least) number of samples. This also may take some time.

So prepare Your broken product for long term storage. Remove batteries or be prepared to charge them from time to time. Keep them in proper air-conditions and temperatures.

And do not mix them. Remember, they must be tracked piece-by-piece and have their matching description. Piling them up on the shelf is not right.

Store them for training

Now imagine You do manufacture not a 15$ per piece MP3 player, but 5’000$ in-cost worth gizmo for some techno-fetishists.

If You think about quality and safety, then You must continuously train Your employees. Train, re-train, allow them to try out their skills in safe and inexpensive manner.

For that You need training samples. Teaching a guy on assembly line how to put together 5’000$ worth modules using a pneumatic press tool on almost ready 5’000$ worth part is… well… at least stressful for both teacher and pupil.

But what if You would collect some broken parts, spray them with a red paint or drill some holes in them? They will be clearly distinct from regular parts, so chance that someone will re-enter them into production is almost zero, so we are ISO9000 safe. And with such parts You main train Your employees.

Even more, You can let them try by themselves how much force the part can withstand before it is destroyed. Or that if they will stick their fingers there then they will break something. The training with broken parts may be efficient, highly educational and inexpensive

“How not to” examples

Different people do have different minds. Different operations may require different quality criteria. And there is always some shadow zone between “it is good” and “it is bad”. Having a manual which shows “good part” and “bad part” is good.

But having also an example of “bad part” is even better. The employee may then self-control the job confronting it with “good” and “no-good” example.

Note: In mechanics in 1980-ties there were popular “pass”-“no pass” “test rods” for holes. The “pass” side of rod was slightly smaller than the hole should be, the “no pass” side was slightly bigger. All the employee had to it was to try to ram-in both of them. If both could enter the hole, it was too large. If none could enter, it was too small. Why not to use this concept for electronics and other production?

Summary

After reading this blog entry You should be at least partially aware that sometimes it is good to retain broken products. Of course after marking them in some impossible to miss and impossible to remove way.

ISO 9000 and unit test?

In this entry I would like to make a short talk about ISO 9000 quality assurance system and unit tests. But, and it may surprise You, not in a context how ISO 9000 may utilize unit tests, but how unit tests may be utilized to keep ISO 9000 in an operational state.

Audit is not a check

Launching ISO 9000

The IS0 9000 is a strict, formal, “paperwork” centered quality assurance system. In very short words You, the entrepreneur, do create some numerous quality assurance procedures and then make them running.

During the system startup it is carefully checked if Your procedures do reach goals required by ISO 9000.

ISO 9000 requirements

The requirements of ISO 9000 are very, very inaccurate. They are just generic statements. Your organization should know this, Your organization should document that. Is it strange? No. The ISO 9000 is aimed to help You to ensure quality in almost any kind of enterprise. From manufacturing of shoes to printing books. They simply couldn’t be more specific.

Imprecise task == imprecise result

The problem with such an approach is that You may craft fully ISO 9000 compliant system which won’t have anything in common with a quality assurance. You can design procedures which do work, do reach ISO 9000 goals, but the stuff You make is a total crap.

Primarily because producing crap was Your goal and a proof of crap quality is in a stench. ISO 9000 must be also able to cover that kind of activity so don’t be surprised it allows that.

Auditing ISO 9000 system

The ISO 9000 has a built in safe-fail procedures. These are “audits”. You are bound to periodically perform the “audits”.

The problem is, that even a proper audit may be restricted to taking a procedure and checking if Your organization do adhere to it. There is no intention during an audit to actively search for quality problems.

And, sadly, plenty of quality problems may be outside procedures or at the boundaries between them.

The world is turning…

… and the world is changing.

Nothing stays stable.

Small example

I have a pleasure (still) to work for a company which has a great belief in an adherence to procedure. We do things this way, because we have been doing that before and it worked. Recently this company had to order an expensive “vamp-up” of a production management software because in our procedures there was a drawing template which required that the material used should be put in such and such place. The software offered the method for automatically managing the materials consumed, including automatic computation of an amount, but the result wouldn’t be a “part drawing” but an “assembly drawing”. Visually speaking the table on a drawing would look differently.

Is that a problem to pay significant amount of money for that “vamp-up”?

No. The owners loves old procedures: “It worked yesterday, it will work tomorrow.”.

Hardly false.

But, and there is always a but, a short investigation have shown, that the reason behind this whole drawing template was, that in about 1970-ties You could order a pre-printed sheets of tracing paper (I’m not sure about an English word here. A semi transparent sheet of paper-like material to draw with ink on it).

Yes. About 50 years ago it was convenient to have a pre-printed sheets so 50 years later we do change an electronic system to follow this traditional procedure.

Method != goal

The ISO 9000 procedure is an algorithm to follow. If You do it, You are certain to reach the assumed goal.

Really?

Always?

Ever tried to bake a cake basing on a 1850 recipe?

Let us take the term: “…and take a spoon of sugar”. I didn’t realize why my cakes never came out properly until I got myself a silver spoon from about 1900. It is huge!

What does it mean?

Simply, if You do specify a method without specifying a goal Your recipe will decay, rust and become a problem not a solution.

Plenty of existing ISO 9000 procedures do not specify accurately enough the goals they are bound to reach.

Reverse approach

There is one very annoying order You may issue to Your subordinate: “Do it well.”. I don’t care how You will do it, reach Your goals.

You may then imagine, that You will write Your ISO 9000 procedure in terms of goals. For an example: “a kind and amount of material to produce a piece must be known from a drawing.”.

Then absolutely any method of describing the material will work. And it is clearly seen if the drawing is good or bad. Has it a material specified? It is good. Has it not? It is bad.

This kind of quality assurance procedure may survive hundreds of years without a need of alteration.

It is not ISO 9000

It is however to an ISO 9000 then.

ISO 9000 is about procedures. Procedures. Methods, recipes, algorithms. Call it however You like, but it can’t leave You any flexibility. This is because ISO 9000 procedure should warrant the quality even if a brainless ape will use the procedure. It may not leave a space for an invention, because inventing equals making mistakes.

Which is good.

Except, that if ISO 9000 procedure decays the quality is gone and nobody will notice that. On the contrary in “goal based” quality assurance system the quality will stay, but will fluctuate depending on person and method chosen.

Mixing it together

Unfortunately if You need ISO 9000 certificate You need procedures. Specifying goals is not enough.

Source of problem

The reader might have already noticed that the problem with “procedural” approach is in procedure decay. The time passes, conditions changes, and the algorithm at best starts generating expenses instead of quality.

The “audit” won’t detect it unless performed in a very investigative way. The problem is, that You can’t investigate if procedure still reaches its goals if You don’t know them!

So we need an efficient, easy to use system which will allow to quickly and at low cost to detect if ISO 9000 procedure is still doing what it should be doing.

Unit tests to rescue!

So lets see what can be done.

Specify Your goals

This is a must. Any ISO 9000 procedure absolutely must specify goals. The specification must be:

• bound to specific ISO 9000 requirement. This will help us to prune system of useless procedures if ISO 9000 will change itself;
• it must be easy to understand;
• it must be pin point accurate. A sentence like: “The goal of this procedure is to manage changes in documents” is a good title but not a goal. You must be an order of magnitude more accurate. Like, what is a “change”? What is “manage”? Is any formal acceptance procedure required? Do wee need an ability to roll back? Is notification needed? And etc, etc.

Specify Your algorithm

The usual way. Nothing to say. Do it as You did before.

Specify tests

And here is a big change. As You probably already noticed specifying accurate goals is not an easy task. It requires a very analytical mind to do it correctly. Such minds are not easy to find and are usually hell expensive. Plus, hardly anyone with a plain mind can understand what they are babbling about.

In fact, it is so hard, that You should assume that below 1% of Your “white collar” employees can do it right.

This is because 99% of humans do think “by an example”. And, in our case it is good.

They can specify examples which will show that the procedure works. And “examples” are what are unit tests about!

For an example if You have a quality assurance procedure for above mentioned drawings, you may add a simple test:

1.Take a drawing from an official documents pool.
2.Check if it has a kind of necessary material specified. 
3.If it does, test is passed. If it doesn't test fails.

Tests pool

Now imagine that together with each procedure is bound a certain amount of tests of above like complexity. And You are auditing the procedure. You are doing it with an additional goal in mind: to check if the procedure still works.

Without knowing goals of procedure it is impossible.

Knowing them it is possible but very difficult. A truly investigative job.

But with tests… How much of an effort requires an above test? I could do it drunk and tired. A kid from school could do them. They are easy because they are focused on a single example.

Of course You can’t proof a method by a positive example. Even piling them up You can only rise a probability that the method is correct.

But if any of test fails the entire method is wrong.

And You have detected it at an extremely low cost.

Summary

I could write more. And even more. But it is not a right place and a moment.

What You should understand it is that adding unit tests to ISO 9000 procedures can be an extremely cost efficient method of ensuring that Your ISO 9000 keeps Your quality in check.

Are there other benefits?

Sure. Exactly the same as when You do programming with unit tests. Let me know in comments if You like to have this article extended and know more about tests in ISO 9000 quality assurance systems.