Six Sigma SPC - Statistical Process Control

Auto-Collecting Data
Six Sigma SPC - 2070 W. Washington St. #5 Springfield IL 62702  Ph: 217.698.0063
6 Sigma Statistical Process Control (SPC) Software for Windows 95/98/NT/2000/XP/ME

Home Search Capability Studies Links
Products Services
Prices FAQ
About Support
Contact Quality Control Dictionary and Glossary Free Desktop 6 Sigma Calculator Forum
Quality Books Six Sigma and SPC Articles Free Online 6 Sigma Calculator Free Newsletter
These articles are from the Six Sigma SPC Newsletter and other publications. All articles written by Jim Winings

From the (Apr-May-Jun.) 2002 Newsletter


Collecting data is a messy costly business. But, you have to do it. Sometimes there are no good ways of doing any given task, just a way. However, there are small things that you may be able to do that will reduce the cost by a few cents. Multiply that savings by the number of points of data you collect and then multiply that by about 365 and you will see that you can save some costs.

Auto-collecting data, or data logging, may seem like a really good idea on the surface, but as you dig into it you may find some problems that will actually cost you more in the long term. I got a call from some magazine involved with metal stamping or making screws, (or something like that), in the UK that thought by collecting data on 100% of the product that they would be able to do some kind of statistics on that data. Yes and no. You can do statistics on the data collected providing you just look at a sub-set of the 100% data. If you try doing SPC, (statistical process control), on all the data, you are not doing SPC. Not only that but, you could still have a problem with the process that may not been seen until it is too late. Which of course leads me to a short story. It really depends on if you are collecting data all day long, like in incoming inspection, or if you are an operator and just collecting a few samples every few hours.

Auto-collecting data has been going on for years in the testing of IC chips. With the testing of IC chips, you usually have a test fixture connected to a workstation, connected to a computer. You load the testing software into the computer and on the workstation is a box with a button you push to start the testing and a display of some type that will display a 'bin' number. This bin number can be used to sort the IC chips. We rarely sorted ICs' unless engineering wanted to see how many bin 'x's they were getting. All most always, a bin one, '1' went in to be processed more and any other bin numbers were scrapped. The bin numbers on that computer could be from zero to ninety-nine. They were only using about half the numbers they could have used. I.E 1 to 50. So they had about 50 more numbers they could have chosen.

The workstation with the display on it also had a little hood on top of the box to block glare so the operator could read the display easier. What happen was the operator was sitting too high and the hood blocked only the very first segments on the LCD. That was fine except that bin sevens, '7' looked like bin ones, '1' because the line going down on the 7 was straight and not at an angle. The operator ran all night putting bin 7s' into the bin 1 tray.

So auto-collecting data is fine but also make sure your process is as flawless as possible. I ask the supervisor, why TSE, (test system engineering), was using bin 7. They still had a lot of other numbers they could have used. If they made all the bin 7s' in all the test programs some other number, like with 2 digits instead one digit, then that problem would have never happened. Also using one digit for a good part and 2 digits for a bad part allowed there to be more disparity between good and bad parts when looking at the display. So they changed at least that part from bin 7 to bin 75 or something. We then knew that particular problem would not occur again. Common sense.

If you do data logging using custom software, you need to insure that the process of connecting the data logger to the software to analyze the data is as easy to do as possible. It does not do you any good to have to spend 15 or 20 minutes each time you set up a process to collect data unless you are running enough of a volume of parts to justify the time. It can take as little as 15 seconds to enter numbers into our statistics program via the keyboard. And if there is a timing problem between the data logger and the analysis software, it takes even more time for the operator to fix the problem, and this may make your operators less productive. The problem usually comes into play where you try to make something do a task it wasn't designed to do. For example, one would not try to pull a fully loaded semi-trailer with a FORD F-150 pick-up. At some point it will break because it was not designed or tested to do such a task. While this is a simple concept, I see people trying to do stuff like this all the time. It is however possible to retrofit machines, software, etc. to do what you want them to do.

While the device you use to collect data into your data analysis software may not have the ways and means to put the data onto a PC, it will most certainly have a way to print the data. Yesteryear, the printer was almost always a serial port type printer. So what I have done on more than one occasion is take the printer output port on the measuring device and hook it to the serial input port on a PC. Then using any modem program, you can get the data to a text file. Depending on the software used to print to the printer, you will find some extra characters in the text file that are used to control the printer. Like form feed, etc. Once you have the data to the PC's hard drive, you can write a parsing program, a program to strip out all the control characters, and then put it into your data analysis software or create a comma delimited file to import it into your data analysis software. And remember we can help you automate your data collection no matter if you are using ZeroRejects or not.


I had a Six Sigma course that dealt with software. The course taught that a three minute interruption was the same as a 20 minutes interruption in the programming process. This is because you lose your concentration and have to get back into the swing. Not only that, but, this is not only true with programmers, but most everyone who has to use their brain doing their jobs. It may be 5 minutes instead of 20, but an interruption will do that. It is not a one to one ratio because we are humans. When you stop to collect data, you just created an interruption. So you may not be saving time at all by only measuring one-piece part instead of 2 parts. For example, if it takes an operator 2 minutes to shut down and make a measurement, it may be 5 minutes before they get back to being 100% productive. This may be the same amount of non-100% production time if the measure is of one piece or two pieces. And by measuring 2 pieces, you can do real SPC. You can check your production rates at various times to see how your company is.

So try, and it is not always possible, to make your SPC measurements when the operator is going to be interrupted anyway. Like before lunch or breaks. There is also a theory that indicates that before lunch and breaks there is a higher possibility for an operator to make a mistake. This is because they are less attentive before breaks. After breaks, it takes them a few minutes to reach 100% production. Use these gaps where production is less than 100% anyway to make your measurements if possible. There may be times with some processes in some companies where this is not applicable. But if you can do it, you will actually be saving some money.

Motorola and Six Sigma are Trademarks of Motorola, Inc.
Ford, and F-150 are registered trademarks of the Ford Motor Company




Copyright � 2005 Six Sigma SPC / Jim Winings All Rights Reserved
Privacy Statement - Disclaimer - Copyright - Site Map

Last Updated: Saturday, 15-Apr-06 19:47:49 PDT