Latest / The Operations Podcast with Fexingo: Process, People, and Profit in Modern Business / How a Microchip Plant Slashed Test Time by 40 Percent
Transcript
- Lucas: So earlier this year, I was talking to the operations head at a mid-sized chipmaker that supplies automotive and industrial customers. And she told me something that stuck with me: 'Our test floor is the new bottleneck.' They were shipping chips on time, but the test floor was running three shifts and still couldn't keep up. Luna: That's interesting because everyone talks about fab capacity, but testing is the unsung hero. What did they do about it? Lucas: They did a deep dive and found that each chip was spending an average of 18 minutes in final test. That's the electrical validation that catches defects before shipping. And they managed to get that down to under 11 minutes per chip. That's a 40 percent reduction, without adding a single piece of test equipment. Luna: Forty percent is huge. But how do you even start shaving off that time? Is it just faster machines? Lucas: Not really. The machines were already fast. The problem was the way they were being used. Each chip had to go through a series of tests — connectivity, leakage, speed, and so on. And the sequence was fixed, one test after another. But not all tests are equal for every chip. Luna: So they started skipping tests? That sounds risky. Lucas: No, they didn't skip them. They just changed the order and the logic. They used machine learning to predict which tests were most likely to fail for a given chip design and process corner. Then they ran the most telling tests first. If a chip passed those, they could run the remaining tests in a different order, sometimes in parallel. Luna: So it’s like triage. But ML predicting failures — how confident were they? Did they have to prove it to quality auditors? Lucas: They did. And that’s where the operations piece came in. They didn’t just flip a switch. They ran a pilot on a single product line, comparing the ml guided sequence with the old one. They validated that the failure detection rate was statistically equivalent. The key was that the ML model wasn’t deciding which chips to skip tests on; it was just optimizing the order and flagging which tests could be run concurrently. Luna: So the tests all still happen, just in a smarter order. That’s a relief. But how did they manage the parallel testing? That sounds like it would require new hardware. Lucas: It actually didn’t. The testers already had multiple channels, but they weren’t using them efficiently. By grouping chips with similar test profiles, they could run multiple chips at once. Previously, they were testing one chip at a time per station. Now they batch them — like three chips per station, with shared resources. That alone cut a lot of the per-chip overhead. Luna: Okay, so that’s the technical side. But operations is about people too. How did the floor staff react to this new system? Lucas: That’s the part I found most interesting. The test engineers were skeptical at first. They’d been doing it the same way for years. But the ops team brought them in early, showed them the pilot data, and let them tweak the rules. They also retrained the technicians to monitor the new workflow. One of the biggest changes was moving from a fixed sequence to a dynamic dispatch system, so operators had to trust the software to tell them what to do next. Luna: So it’s a cultural shift as much as a technical one. I’d love to hear more about how they managed that, but first — and I know we’re in the middle of this, but you know, we keep this show free and ad-free, and that’s something we’re proud of. If you’ve found these conversations useful, and you want to help us keep it that way, you can support us at buy me a coffee dot com slash fexingo. Just a thought. Lucas: Yeah, that’s a good reminder. And we do appreciate it — it’s what lets us spend time on stories like this. So, back to the cultural shift. How did they get the engineers on board? Lucas: They used a simple approach: they gave the skeptics a voice. The operations lead told me they set up a weekly review where the engineers could challenge the model’s decisions. For the first month, they kept a log of every time the ML suggested an order that seemed wrong. And they found that in most of those cases, the model was actually accounting for interactions they hadn’t considered, like temperature effects between adjacent test bays. Luna: So the model was teaching them something about their own process. That’s a nice flip. But what about the physical layout? You mentioned reconfiguring the floor earlier. Lucas: Right. They mapped the flow of chips through the test floor and found that a lot of time was spent moving batches between stations. They reorganized the floor into cells, grouping stations that frequently tested the same type of chip together. This cut the average travel distance by about 60 percent, and it also reduced the time chips spent waiting in queues. Luna: So the 40 percent came from a combination of parallel testing, smarter sequencing, and layout changes. What was the hardest part of the implementation? Lucas: The biggest challenge was the data quality. The ML model needed clean, labeled data from the test floor, but the existing logs had a lot of gaps and inconsistencies. They had to invest a couple of weeks just to clean up the data before they could train the model properly. The operations head said that was the unglamorous but critical step. Luna: That makes sense. Garbage in, garbage out. But once they had the model, how did they validate it against quality? I imagine a recall would be disastrous. Lucas: They ran a side-by-side comparison on a high-volume product for two weeks. Every chip went through both the old and new test flows — the new flow was used for shipping decisions, but they also ran the old tests in parallel on a sample. They compared failure rates and found no statistically significant difference. Then they got the quality team to sign off. Luna: So it wasn’t just an ops win; it was a quality win too. What did the floor staff think after the pilot? Lucas: The skepticism turned into ownership. They started suggesting further tweaks — like reordering the test steps based on the time of day, because temperature drift affected some measurements. The ops team hadn’t even thought of that. That’s when you know you’ve got a real process improvement. Luna: So what’s the bottom line? Did they actually save money or just time? Lucas: Both. They avoided a capital expenditure of about twelve million dollars for new testers, because they freed up enough capacity just by using the existing ones smarter. And they also reduced the time from wafer to shipment by about two days, which is a big deal for customers who are waiting on chips for their own production lines. Luna: Wow, twelve million is a big number. And it’s not just about this one plant, is it? I imagine other chipmakers are facing the same pressure. Lucas: Absolutely. As chips get more complex, test times tend to grow. But the industry has been slow to adopt these kinds of data-driven approaches because testing is seen as a cost center, not a place for innovation. This case shows that a mid-sized player can steal a march on the giants by applying ops thinking to a technical bottleneck. Luna: So what’s the one thing you want our listeners to take away from this episode? Lucas: I think it’s that the bottleneck is often where you least expect it. Everyone focuses on the fab, but the test floor is where the product actually gets confirmed. And with a bit of data science and a lot of change management, you can unlock capacity without spending a dime on hardware. Luna: That’s a great note to end on. Thanks for joining us on The Operations Podcast. We’ll be back next week with another story of process, people, and profit.