Manufacturers Don't Have a Data Problem. They Have a Follow-Through Problem.
A researcher who talked with thirty plant managers found that manufacturing exception data wasn't the problem: every system already caught the defect and flagged it. What was missing sat one step further, a designed process for who owns the fix, on what deadline, with automatic escalation if it stalls, instead of a manager personally chasing it down by hand every time. The piece argues this gap is a process design failure, not a technology gap, and stays that way even in a fully automated plant, since deciding what to do about a flag is still human work.
Ask most owners what's broken in their operation and data comes up fast. Better visibility. A dashboard that would have caught this before it became a problem. Somewhere out there is a system that sees more than the one they've got.
A researcher had conversations with thirty plant managers, looking for the pattern underneath that assumption. What he found wasn't a data problem. Every plant in the sample already had the data. The ERP logged the defect. The shift log recorded the exception. The system did exactly what a system can do: it turned something that happened on the floor into something flagged, timestamped, and ready to act on. Then its job ended. What happened on the other side of that line is where the real pattern lived.
Even a fully lights-out plant still has that line. It doesn't mean nobody's reviewing what the machines flag and deciding what to do about it. A system can capture what happened. It can turn that into information: this defect, this owner, this deadline. Somewhere between the system's job ending and a person's job starting sits a seam, and no amount of better data or better automation on the floor sews it shut. In plant after plant in this sample, there was no process for closing that seam. There was only a manager, starting from scratch each time: tracking down whoever owned the fix, working out why it had stalled, then staying on it by hand until it moved.
Somewhere between the system's job ending and a person's job starting sits a seam, and no amount of better data sews it shut.
Call it the chase, because that's what it becomes, and it can be exhausting. Picture a defect logged Tuesday morning. By Thursday, nobody's touched it. The plant manager finds out by walking the floor, not from the system. She tracks down the shift supervisor. He didn't know it was his to close. Maybe that genuinely wasn't clear. Maybe it was clear and got deprioritized against three other fires that same morning. Either way, the seam got closed the only way it could: manually, by her, again, same as last week.
This is expensive in a way that never shows up on a P&L line. The chase isn't free labor. It takes real judgment: figuring out who dropped it, whether the excuse holds up, how hard to push. That judgment goes into closing a seam that nobody designed to close on its own, and every hour spent on it is an hour that doesn't go toward the projects that actually move the company forward. Multiply that across every exception in every shift, and the management team's real, unbudgeted job is doing by hand what a well-designed handoff should do on its own.
The instinct once you see this pattern is to go looking for a bigger system. More dashboards. A platform that promises full visibility. That instinct aims at the wrong side of the line. More data and better information sharpen what the machine already does well: noticing. Neither touches what happens after the machine's job ends, which is the actual gap. Visibility wasn't missing in this sample. The plants already had it. What was missing sat past the handoff: a process that assigns an owner the moment an exception is flagged, sets a deadline as part of that assignment instead of leaving it to whenever someone checks, and escalates on its own if the deadline passes with nothing done.
None of that takes the person out of the loop. Nothing does yet, and lights-out was never going to be the thing that did. What actually closes this gap is narrower, and it isn't new technology. It's a process: ownership, a deadline, and an escalation trigger, attached the moment something's flagged, instead of left to whether a manager happens to remember. The decision and the work stay human. Whether the handoff gets made on schedule stops being a matter of memory and attention, and starts being a matter of how the process is designed. Plenty of the systems already flagging these exceptions have fields sitting unused, waiting for a process to use them. The process has to come first. It was never a software gap.
So the useful question isn't whether this is in the system. It almost certainly is. The useful question is narrower, and it points straight at the handoff: for the exceptions your system already flags, what happens next the moment that flag crosses from machine to person, and who currently has to notice on their own that it crossed?
Walk your own operation with that question for a week. You'll probably find the same gap that kept surfacing across those conversations. Not a system that's blind. A system that sees clearly, hands off cleanly, and then waits, patiently, forever, for someone to notice the handoff happened.