The System Nobody Uses

How expensive technology ends up collecting dust

There's a particular silence that surrounds unused equipment. It sits in the corner of the factory floor, powered on, indicators blinking, doing nothing. Everyone walks past it. Nobody mentions it. The purchase order closed years ago and the project was marked complete.

This happens to technology that works exactly as designed. The vision system inspects correctly. The automated cell runs its cycle. The software produces accurate reports. The problem isn't the technology. The problem is that it doesn't fit how people actually work, and people route around obstacles.

The gap between designed workflow and actual workflow is enormous and invisible. Designed workflow lives in process documents and vendor presentations. Actual workflow lives in the habits of operators, the informal agreements between shifts, the shortcuts that evolved because the official process takes too long. When new technology assumes the designed workflow, it lands in an organization that doesn't work that way.

I've watched operators disable safety interlocks, bypass automated stations, and manually override systems that were supposed to eliminate manual steps. Not out of malice or ignorance, but because the automated way doesn't handle the exception that happens twice a shift. The system was designed for steady state. Production is not steady state. Production is interruptions, material variations, equipment hiccups, and customer changes. The operators know this. The system doesn't.

Vendors demo in controlled conditions. Clean parts, consistent lighting, no time pressure, no exceptions. The demo works flawlessly because it's performing in an environment designed to make it work. Your factory floor is not that environment. Your factory floor has oil mist, temperature swings, parts that arrive out of spec, and operators who need to hit a number by end of shift. The gap between demo conditions and reality is where projects die.

The failure mode isn't dramatic. The system doesn't crash or catch fire. It just gradually becomes optional, then ignored, then forgotten. Operators develop a workaround. The workaround becomes standard practice. New hires learn the workaround, not the system. Eventually someone asks why we're still paying maintenance on equipment nobody uses, and that's when the project officially fails, years after it actually failed.

There's a specific meeting where this fate is sealed, usually early in the project. Someone asks "how will operators actually use this?" and the room goes quiet. The question gets deferred, or answered with an assumption, or redirected to training. Training doesn't solve the problem. Training teaches people to use a system. It doesn't make the system fit their reality.

The organizations that avoid this failure do something uncomfortable: they watch. Before specifying anything, they stand on the floor and observe what actually happens. Not for an hour, but for shifts. They see the exceptions, the workarounds, the informal processes. They learn that the official cycle time is fiction and the real cycle time includes all the things that don't appear in the process document. Then they design for reality instead of the diagram.

Technology adoption isn't a training problem. It's a design problem. If using the system is harder than not using it, people won't use it. If the system doesn't handle the exceptions that happen constantly, people will work around it. If the system requires perfect inputs and the inputs are never perfect, the system will sit idle.

The expensive equipment in the corner is a monument to a project that answered the wrong question. The question wasn't "can this technology do the task?" It was "will this technology fit how work actually gets done here?" Nobody asked.