Defect Code: Defect Coding Scheme Design

A defect coding scheme is the difference between data and a list. With a consistent structure, the codes support a pareto, a trend and a root cause analysis; without one, the records accumulate as free text that nobody can aggregate. The scheme does not need to be sophisticated, but it does need to be designed rather than allowed to evolve.

Why Codes Fail

Most schemes fail in one of two ways. Either the categories are too broad, so that a code such as solder defect covers everything from a bridge to a cold joint and cannot lead to an action, or they are too detailed, so that the operator has to choose between twenty similar codes and picks whichever is first. The first produces data that cannot be analysed; the second produces data that is unreliable.

The third failure is a scheme that is not maintained. A code for a component that is no longer used remains in the list, and a new failure mode has no code and is recorded as other. Within a year the scheme describes the product as it was rather than as it is. First pass yield data is only as good as the codes beneath it.

Designing the Structure

A useful structure separates what the defect is from where and when it was found. The defect code itself describes the physical condition: missing component, wrong component, insufficient solder, solder bridge, lifted pad, damaged component, contamination. The location and the detection stage are separate fields, so that a bridge found at optical inspection and the same bridge found at functional test are distinguishable.

Separating the fields is what allows the data to be analysed in more than one dimension. Counting by defect code shows what goes wrong; counting by stage shows where it is caught; counting by location shows whether the problem is concentrated on one part of the board. Any of the three alone is less informative than the combination, and the combination is only available if the fields are separate.

Categories and Granularity

The categories should map to the process step that can fix them. If two codes always lead to the same corrective action, they can be merged; if one code leads to two different investigations, it should be split. Ten to twenty codes is a practical range for most assembly processes, with the ability to add a comment field for detail that does not warrant a code.

The granularity should also match the volume. A defect that occurs once a year does not need its own code, while one that occurs daily does, even if it seems minor. The scheme should be reviewed against the defect data annually, and the list adjusted to reflect what actually happens rather than what was imagined when it was written. Yield analysis depends on that alignment.

Location and Stage Fields

The location field should be defined in a way that is quick to record and useful to analyse: the component reference for a placement defect, the board area for a process defect, the panel position for a handling defect. Where the location is free text, it will not aggregate; where it is a list, the operator will choose the closest option, which is adequate for analysis.

The stage field is the one that most often exposes a process problem. A defect that is created at placement but detected at functional test has passed several opportunities to be caught, and each of those is a weakness in the inspection plan. Recording the stage makes that visible, and it supports the decision about where a check should be added or removed. Inspection standards define what each stage is supposed to detect.

Data Quality

The quality of the data depends on the people entering it, which means the scheme has to be quick, unambiguous and visibly useful. A code list with a short description and a photograph of the defect is much more reliable than a list of names, and a scheme whose results are fed back to the team is maintained better than one whose data disappears.

Training matters as well. Two operators should code the same defect the same way, and the only way to confirm that is to test it with examples. Where the coding is inconsistent, the pareto is a reflection of the people rather than of the process, and the improvement actions will be aimed at the wrong problem. Periodic calibration using photographs of real defects keeps the coding aligned.

Using the Data

The primary use is the pareto, which identifies the largest loss and gives the improvement programme its first target. The secondary use is the trend, which shows whether a change worked and whether a new problem is developing. The third use is the comparison across products, which identifies the design features or process steps that consistently produce defects.

For any of these to be useful, the data has to be aggregated regularly and reviewed by somebody with the authority to act. A report that is produced monthly and read by nobody is a cost without a benefit. The review should end with an owner and a date for the largest category, which is the same discipline that applies to any improvement loop. Yield control provides the framework.

Maintaining the Scheme

The scheme should be owned by a named person, with a documented revision and a defined route for adding or retiring codes. Changes should be rare and considered, because a scheme that changes frequently breaks the trend, and the trend is one of its main purposes. Where a change is needed, the historical data should be mapped to the new codes rather than abandoned.

The review should be annual and based on the data: which codes are unused, which are used constantly, which are ambiguous and which defects are being recorded as other. That review keeps the scheme aligned with the process, and it prevents the slow drift that turns a useful tool into a formality.

Choosing Between Codes and Free Text

Some factories resist coding because the detail of a defect is lost when it is reduced to a category. That concern is legitimate, and the answer is a comment field rather than a longer code list. The code carries the analysable part of the information, the comment carries the detail, and the two together give both the statistics and the description that an engineer needs to understand a specific board.

The comment field should not become a substitute for coding. Where the comments contain the real information and the codes are filled in carelessly, the analysis fails. A short rule that the code is mandatory and the comment is optional, with the comment encouraged where the defect is unusual, keeps the balance and makes the data usable.

FAQ

How many defect codes should there be? Usually ten to twenty for an assembly process, with a separate comment field for detail that does not warrant its own code.

Should the location be part of the code? Better as a separate field, so that the data can be analysed by defect, by location and by stage independently.

How do we keep coding consistent? Short descriptions with photographs, periodic calibration with real examples and feedback of the results to the people entering the data.

What if a defect has no code? Record it as other and review the list. A recurring other is a code that needs to be added.