"Software only compensates for so long"
Breaking QA out of its silo: a cross-functional approach from software code to the factory floor
Carrying software engineering practices, traceability and acceptance criteria, over to quality control on a physical production line, in order to align departments.
Software can absorb a certain amount of variation in the hardware around it, but not indefinitely, and above all not silently. Going through the defects reported on Markprint, I found that some of them were not coming from the code at all: they came from variations in the adhesive media, which the software handled as best it could until the point where it no longer could. Fixing the code would have meant treating the symptom.
Director of Operations
Quality and compliance, Operational structuring
Recognizing a defect that is not where you are looking for it
The first task is to accept an unwelcome hypothesis: if a defect survives several fixes, it may well not be in the perimeter where you are looking for it. Qualifying the tickets made that diagnosis possible, by isolating the defects that clustered on certain consumable batches rather than on certain software configurations. Without that data, the conclusion would have remained a conviction, which is to say unarguable and without effect.
What software QA does routinely and the factory floor did not
I carried three ordinary development practices over to physical production. Explicit acceptance criteria, meaning a written tolerance rather than a judgment based on experience. Validation protocols run systematically rather than when someone has a doubt. And traceability, which makes it possible to tie a customer report back to a specific manufacturing batch. None of these practices is specific to software, but they are unremarkable there, whereas on the factory floor they had stayed informal.
Making support the first filter
The chain only holds if the first link knows how to qualify. I trained the support staff on assessment grids that let them tell a usage defect, a software defect and a consumable defect apart before escalating. That transfer of skill has a direct consequence on production: a defect correctly qualified during the call becomes usable information in manufacturing, where a vague ticket would simply have been lost.
What I can claim, and what I cannot claim yet
Since these protocols were put in place, I have received no quality report on any serial number produced under the new process. That is a signal, it is not yet proof, and it would be dishonest to present it as anything else: the delay between a batch being manufactured, delivered, actually put to use and a defect eventually surfacing is counted in months. A reliable measure of this method will come from time, not from a dashboard. What the setup does guarantee today is that a defect, if one occurs, can be traced back to its batch.
The part that transfers
The value of this method goes beyond the case of adhesives. As soon as a product combines software and hardware, the boundary between the two becomes the place where defects settle and where nobody is clearly accountable. Working on that boundary requires that one and the same person be able to look at both sides, which is less a technical skill than a question of how wide the mandate is drawn.
Related projects