Seeing the Data Sets You Free; You Can't Manage a Secret...

The title is paraphrased from a talk given by Alan Mulally at the Stanford Business School when he was CEO of Ford Motor Company. (Note 1)  In his discussion, he meant that if you want to tackle a business problem in a meaningful way, it is absolutely essential to get everyone using the same set of data or information to be able to make some desired improvement. Seeing the data together is important, even if – especially if – the data show “bad news.”

A few years ago I joined a company as the Operations Manager in printed circuit board assembly and had my own “A-ha!” experience that corroborates Mulally’s observation. One of the operating division’s practices was to review each production business unit’s process yield data and trends, and report them in a Bimonthly Yield Meeting. My team’s review consisted of tables and bar charts showing the overall first-pass yields of the various models of circuit boards we built for each product line. Accompanying commentary written by one of the process engineers described the failure modes for the top 3 causes of test failures in the period, followed by an attempt to explain the underlying or “root” causes.

Perhaps not surprisingly, given the volume and variety of circuit boards tested in two months’ time, in every historical report I looked at the answer was some variation of “different failures, random causes, no trends, check back again in 2 months.” This approach was sufficient to keep first pass yields hovering around 90%, even as circuit board complexity had increased steadily over the prior few years as products had added features.

As part of the company’s continuous improvement process, a training company was engaged to teach a workshop on Six-sigma principles. Engineers from each business unit participated in a week-long classroom session followed by a supervised project over several months. Many good things came out of the workshop and the projects; one of the best was to solidify the notion that in order to improve quality of the process, it was not enough simply to tabulate the test failures over a long period of time. It is necessary to get beneath the “pass-fail” view – in close to real-time – and investigate what defects occur and what is causing them to occur, then set about correcting the underlying causes in order to maintain process control.

Here’s an example from a few weeks into that new Six-sigma paradigm.

A board called the “MCU Board” has a high failure rate in the ICT (In-Circuit Test, an automated board test system) for a capacitor in circuit location C16. The production line repair technicians remove and replace that part on approximately 30 boards per week because the tester flags them as defective; that is, the measured value is outside the acceptable tolerance that’s programmed in the test. When the part (or any part) fails, the board is set aside for repair and retest before it can be used in product. I’m the new guy here, so I can ask naïve questions for a few more weeks, and when I ask about this C16 failure, the responses are something like: Oh yeah, that’s normal; or, Been like this as long as we can remember; and, It’s only about 5 percent of the boards.

Nobody thinks of it as a problem; this is just the way it is.

In reviewing the ICT failure data, however, I noticed something curious and brought it up with the engineering team. “The same component type and value as C16 is used in a dozen locations on the board, but the other ones never fail. How can it be that the bad ones are always placed in C16?” 

Dead silence in the room for three full minutes while that sank in. Then one brave soul volunteered that maybe the test program limits were not set properly for C16. Another engineer pointed out that maybe C16 was right and the other locations’ test limits were set too wide (meaning some of them should be failing, too). Still another pointed out that maybe the circuit design had other components around C16 that prevented the ICT tester from making a proper measurement. At that point an eager problem-solver emerged and said he would start digging into the cause of this obvious problem as soon as the meeting broke up.

That afternoon he excitedly reported to me that the test program indeed had pass-fail limits biased in favor of measured values above the center of the C16 part tolerance, thus increasing the chance that parts measuring low, yet still within tolerance, would fail the test. On the next six-hundred-piece run of that board, he checked the measured values for all the affected capacitors and was able to nail the root cause of the problem as incorrect test limits. Seeing that, he easily corrected the program so that parts measuring within tolerance (essentially all of them) would pass.

Behind the tech-geek discussion, what happened there? Right off the bat, we got a 5 percentage-point improvement in MCU Board yield, for the cost of around 4 hours of an engineer’s time. The technicians who used to remove and replace 30 per week of that part no longer had to do that, saving labor cost. The bonepile of defective boards was reduced because the failed MCU Boards that had been awaiting repair were tested against the corrected limits, with no C16 repeat failures. The scrap rate went down, saving material cost. Board retest post-repair went down, saving labor cost.

These are all good things, but there was an even bigger payback.