Datamanagement
In the
Bare Board Test Environment

by:
Duane Delfosse
Everett Charles Technologies

The data overload problem has much more severe ramifications than simply increasing the stress level of test and MIS staff.

It doesn't take many visits to test departments in board manufacturing facilities to realize that excessive amounts of data are overloading well-intentioned and competent staffs.Data overload stems from the large quantity and variety of information needed to fabricate fixtures, conduct test, feedback data to upstream processes, and continuously improve the test process itself. Much has been said of the power and connectivity of computer integrated manufacturing (CIM) solutions, and there is no denying their effectiveness in many areas. These solutions, however, are usually deficient in meeting the needs of a test department, an area which has become one of the most data-intensive in the factory.

The data overload problem has much more severe ramifications than simply increasing the stress level of test and MIS staff. A lack of accurate data has more than once led a board manufacturer to buy more "theoretical" capacity or capability, in the form of equipment or additional staff, as a brute-force solution to this problem. Once the capacity or capability is installed, it is a rude awakening to discover the root-cause problem or problems remain.

This type of serious missed opportunity is based on the fact that the data leading to the decision was inaccurate or simply unavailable. It's important to keep the perspective that test, which includes its associated fixture and data processing operations, is a process within the larger board fabrication process. It has multiple steps, defined inputs and outputs, yields, and rework loops that ought to be represented in any board manufacturing process flow diagram.

Sorting Through the Data

What follows is an attempt to sort though the data associated with the bare board test process to identify what kinds of data are important for managing test as a continuously improving process. The objectives of the improvement process are to develop and refine a system for achieving the most accurate test results possible at the highest possible throughput rate. Obviously, it is impossible to identify a concise list of the essential data for managing any test department. However such data can be reasonably grouped into the following categories:

• Test requirements for computer integrated manufacturing systems
  

• Test process improvement data requirements

• Board manufacturing feedback data requirements

After considering each of these categories, the difficulties of implementing a data-oriented change environment are discussed, along with some suggestions on high leverage change activities.

Test Requirements for Computer Integrated Manufacturing Systems

Managing today's test floor is very unlike what it will become in just a few years, because the requirements of test process flow are just starting to be properly integrated into shop-floor control systems. Today, expediters are too often compelled to spend their days checking the status of daily shipments, which serves to drive a short-term, reactionary mentality. Fundamentally, most CIM systems are not yet sophisticated enough to do a better job than a human at scheduling work through a collection of test and repair stations. In some CIM installations, fixture fabrication, analysis, and repair are not broken out as separate operations. In either case, it takes planning and effort on the part of the test and MIS staff to get the most out of their CIM system.

The following diagram illustrates how board fixture materials and data might flow in a simple test environment.

As you can see, there are a number of discreet process steps, most use data from the previous step(s) or provide data needed for a subsequent step. This diagram is much more complicated if parallel alternate paths exist through different types of test, repair, fixture fabrication, or data processing tools-all of which could be brought to bear on the incoming supply of boards and data, but each possessing its own set of constraints.

For an intelligent CIM program to manage a test operation designed for continuous improvement, it would need to contain a model of the constraints and material requirements of each operation. It must have the capability to identify which constraints are most limiting, so that problem solving activities can continuously be brought to bear on the limiting constraint. (That's really another way for saying, "Look to see where the WIP is piling up, call it a bottleneck, and call the responsible supervisor.") Given knowledge of these constraints, the sequencing of jobs starting into the overall process-and in queue at each process step-can be matched to provide the maximum output for the entire process.

Unfortunately, it is not that easy. Such an intelligent system is not readily available for board fabrication yet. The fact that you can't go out and buy an appropriate solution, however, does not relieve you of your responsibilities for running the department!

Whether provided by a CIM system or not, you need to know how many boards were (or can be) processed and how good the process is. As a test manager, there is a set of important data that tells you the vital signs of your operation. If such reports and data are not available with the click of a mouse from the MIS function, then it needs to be generated within the department.

Example of Data Generation

A particular tester is overloaded. The high demand could come from the technical capability of that tester, an unexpected large order tooled for one machine-anything. That bottleneck resource must be scheduled! If you can't get a report to find the bottleneck, get the data by another means, perhaps by instituting visible queues for each tester. For a more ambitious approach, set up a pull system with the preceding and trailing operations. Once the bottleneck is identified, it's easier to juggle staffing, stagger breaks, or take steps to open more channels for product through other equipment or human resources. If the bottleneck is unwarranted, the "how good is the process" data should tell you right away, and problem solving can be initiated. (It is recommended one establish a lower limit for tester throughput that, if violated, triggers a predefined problem-solving response. Start the rate low, perhaps 60 percent of the expected throughput rate, and increase gradually so the problem-solving resources are not overwhelmed.)

Essential data that should be available from your MIS system includes:

• Quantity and identity of data processed through fixture fabrication processes (between dates and on a job-by-job basis, including operator identification)

• Data should also include the quantity and identity of boards processed through each test or repair station (this information should be available for a job, an individual work center, or for the whole department between dates)

Invariably, this level of data gathering requires the staff to log-on and log-off through each step in the process, which can be a tough cultural transition if it isn't already the norm. If labor, equipment depreciation rates, lease expenses, materials, and overhead burden are known, it is pretty easy to track the average cost to test a board, repair a board, or build a fixture. It follows naturally that, with a little work, a report could be generated to tell the cost of any particular fixture or the cost to test any particular board.

Test Process Improvement Data Requirements

Test is a process with feed materials, process parameters, quality checkpoints, manual or machine operations, and yield, just like any other process. Accordingly, test and fixture fabrication require quality monitoring, throughput monitoring, and continuous improvement activities centered on root-cause problem-solving. Whereas a CIM system would logically be expected to answer the "how many were processed?" question, test managers will usually not have an answer to the "how good is the process?" question unless they specified or wrote the capability themselves.

Once started down the path of data driven quality, there is a tendency to want to collect lots of data, only some of which will prove to be very useful. Restraint must prevail. It is a management mistake to collect all the data. Only careful analysis of the specific questions that need answers yields the correct, minimum amount of data. If it is discovered additional, specific data is needed, then data collection on a temporary or sampling basis can be instituted rather than creating a new layer of permanent data collection.

Ideally, data collection should be low cost and automatic. It should be a byproduct of executing the process. In this day and age, log books are absolutely a last resort! To really get complete data, it should be impossible to execute the process without data collection. More and more process equipment captures run data and provides text or common database outputs. Standards for communication between process equipment and host databases will be adopted in our business, as they have in the semi conductor industry.

" It follows naturally that, with a little work, a report could be generated to tell the cost of any particular fixture or the cost to test any particular board."

Essential CIM data is needed to monitor and improve the test or fixture processes, plus:

• Acceptability of drilled fixture plates into assembly

• Defective fixtures (ppm), as measured at fixture acceptance test

• Fixture on-time report

• Fixture performance report (this data includes false opens and is available at analyze-and-repair)

• Test and fixture manufacturing equipment periodic maintenance records

• Operator cross-training and certification records

Board Manufacturing Feedback Data Requirements

As an "inspection" process, test also must feed back to the board manufacturing process defect data to allow timely response and yield improvement. Since this is really the value test adds to the larger manufacturing process, efforts to clearly communicate the magnitude and trend of defect data is greatly appreciated by those responsible for upstream processes.

Defect data is routinely collected at the analyze-and-repair step. Increasingly, repair and analysis software/systems are capable of collecting defect data as boards are repaired, and writing it directly to database and/or ASCII files. Such systems require the operator to classify and disposition a fault before moving on to the next fault, the principal requirement of a good data-collection methodology. Efforts should be expended to break defects-code down into systematic and random defects.

Essential data needed to feed back to the upstream processes are:

• Defect data broken out by board technology, per lot and/or between dates, as well as trend charts

• First-pass and final yield by lot between dates (perhaps broken out by technology type, probably from CIM system)

• Record of test escapes and corrective actions

For factories with short cycle times, process feedback must occur very rapidly for the effort to have its desired effect. This dictates a network accessible database with real-time report-generation capabilities.

Continuous Improvement is Continuous Change-It's Hard

Thus far, the thought process has centered on what is the necessary data to manage a test department. Once the value of having data is established, we are faced with the formidable task of adhering to the data collection and root-cause problem-solving way of life. This invariably involves difficult change and new discipline. Changing the operation of a test floor seems to require an inordinate "force of will." Thus, the conviction of the change leadership must be strong and unwavering before setting out on this course.

There are ways to make change more easily acceptable. Changing the attitude, habits, and workmanship of a group is usually easier when physical change accompanies it. Rearranging the furniture, installing bulletin boards for department data, or issuing lab coats can cause a new computer-tracking requirement to be accepted. Test leadership should try to associate as much procedural and workmanship change to environmental change as possible. When the novelty of a new procedure or physical change begins to wear off, there will be a tendency for the workforce to lapse back into old habits. It is at this point that the leadership needs to drive acceptance, even if it boils down to their force of will. Of course, there should be consensus that the change is worth the price.

Tangible Benefits

Reductions in overall test cost and test cycle time are the tangible objectives of test supervisors and management (the accuracy of test results are a given). The data above should be used to drive the daily activities of the department to continuously improve the process. It has been shown at many sites that there are certain "surebets" for productivity improvement and cost reduction. Here are a few:

• Institute a standard fixture-acceptance test that is performed on new (or reassembled) fixtures as soon as they are finished (this test should involve checking for shorts and opens in the fixture)

• Institute a fixture troubleshooting methodology, which clearly leads to a distinction between tester, fixture, and board problems

• Strive for fixture standardization, the training burden, inventory, and storage requirements are all simplified by adherence to a standard (obviously, you need to choose the standard carefully)

• Find the bottleneck in the process and drive it

• Don't be stingy with data or knowledge-aggressively cross-train and seek to teach theory along with procedure to promote understanding instead of automatons

• Get manual data recording out of the process-move to bar-code readers whenever possible

• General cleanliness and workmanship, particularly with regard to fixtures, is usually the first measure of a test department's efficiency

A disciplined approach to handling test data will pay big dividends-not only in the long run, but in the short run as well!