Who knew that a phrase from a decades-old popular board game could have some relevance in today’s ever-changing world? In the game of Clue, simply put, evidence is collected and then used to solve a mystery. In my world, testing is performed to gather data/results (evidence) and then this information is used to determine the root cause of some issue that is under investigation (solving the mystery). The recommendations made as a result of a failure analysis investigation commonly lead back to some step along the manufacturing process that now needs to be scrutinized and evaluated and then possibly improved and/or changed. To effectively do this, having information from the steps in that process (evidence, again) is a key component of the potential solution. This latter idea is the main subject of this month’s column, or in a simpler way, how traceable is your process?
When a manufacturing process is humming along, widgets whiz through many pieces of equipment and through many sets of hands until they eventually find their purpose out in the real world. Initial loading, component population, reflow, hand soldering stations, installation into a housing, cabling, functional checks, and potentially many, many more operations…are just some of the steps that a widget might be exposed to during its manufacturing. The process, by its nature, requires a myriad of steps, one potentially very different from the next.
Some steps are likely to be very repetitive in nature and very repeatable in execution from lot to lot, while others, maybe not so much. Regardless of the operation being performed and whether it’s heavily automated or not, having traceability of each individual step through the process as a whole is vitally important. Knowing who did it, when they did it, what tools/materials/supplies they used to do it, and the conditions under which they did it are just a few bits of information that should be known and readily available to someone investigating a process that has produced some bad widgets.
For example, let’s say our widget is a sealed unit that has a printed circuit assembly inside that is sensitive to moisture. The unit itself has a cover on it that is attached via screws with a gasket for sealing purposes. The client is experiencing failure of the widget when it is installed in a humid/wet environment. As a result of testing that would have been performed to investigate the issue, let’s say that the root cause of the field failures was determined to be water/moisture ingress around the cover.
From here, the owner of the widget would likely go to the manufacturing line to investigate the cover attach process. So, at this point, the more information that the investigator can get about that step in the process the better. A simple bit of information would obviously be to know which operator installed the screws and which screwdriver they used, but that might only be the tip of the iceberg in respect to what information could be known. Other examples of bits of information that would likely be of interest in this situation would be…How much torque was applied to the screws? What is the material (lot) traceability of the cover plate? What is the material (lot) traceability of the gasket? What is the material (lot) traceability of the screw? What were the environmental conditions on the line when the unit was sealed?
Those are just a few of the questions that the investigator might ask to try to solve the issue at hand. Thus, having complete traceability of your process will allow for easy dissemination of the needed information. Who knows…maybe the solution is as simple as a bad lot of gaskets? Or, maybe, the torque setting on the screwdriver was incorrect from 9–11 am on a given Tuesday? These are all very plausible answers to our example, but finding these answers would be impossible if the traceability information wasn’t being recorded and/or stored.
Traceability is not designed to be a blame game, although that does unfortunately sometimes happen given the world we all live in. From an analytical vantage point, establishing a mentality in which everyone understands that traceability allows for quicker and more efficient problem solving and troubleshooting when/if things go awry is really the greater theme. If you knew it was Professor Plum in the library with the candlestick from the very beginning….wouldn’t the game be much easier to play?
Keith M. Sellers is operations manager with NTS in Baltimore, Maryland. To read past columns or to contact Sellers, click here.
This article originally appeared in the August 2017 issue of The PCB Magazine, click here.
