IoT in Manufacturing: The Gap Between Pilot and Plant

The smart factory pitch is easy to visualize. Sensors on every machine. A dashboard showing real-time throughput, temperature, vibration, pressure. An algorithm that detects the early signs of a bearing failure before the machine breaks down. The maintenance team gets an alert on Tuesday, schedules the repair for Thursday, and avoids the unplanned outage that would have happened Friday at 2am when the production run is in full swing. This is the promise of industrial IoT, and in a controlled setting, with new equipment, clean power, stable connectivity, and a motivated team, it works.

The part that is harder to sell in a deck is what happens when you try to do this at scale, across an actual production floor that has been running for twenty years.

Start with the machines themselves. Predictive maintenance, the most cited use case in industrial IoT, requires sensors that can read the machine's outputs. New equipment often comes with digital outputs already built in. Equipment that was installed in 2003 does not. Retrofitting an older machine with sensors means attaching external accelerometers, temperature probes, or acoustic monitors, running cables, finding mounting points that do not interfere with the machine's operation, and dealing with the vibration, heat, oil, and particulate environments that manufacturing floors actually involve. A sensor that works perfectly in a lab specification sheet will not necessarily survive two years next to a press that generates significant vibration and heat. The failure rates for retrofitted sensors in harsh industrial environments can be substantially higher than pilot data suggests, because pilots use new sensors on well-maintained machines in conditions chosen to make the pilot succeed.

Then there is connectivity. Plant floors were not designed for wireless data transmission. Metal enclosures, interference from motors and welding equipment, and the layout of production lines create real obstacles for the Bluetooth, Wi-Fi, or cellular connectivity that IoT devices depend on. Industrial wireless protocols exist for this, and they work, but deploying them across a complex floor requires a network infrastructure project that is often more expensive and time-consuming than the sensor deployment itself. Organizations that budget for the sensors and forget to budget for the connectivity infrastructure discover this during implementation.

GE's industrial IoT platform, Predix, is probably the highest-profile example of the gap between ambitious rollout and actual enterprise deployment. Starting around 2015, GE announced Predix with significant investment and coverage in the business press, positioning it as the operating system for the industrial internet. By most accounts, the platform was subsequently scaled back significantly. The specific reasons reported at the time included challenges with enterprise adoption, the complexity of integrating with existing industrial systems, and competitive pressures. I do not want to overstate what I know about the internal decisions at GE, and the reporting on large technology programs is often simplified. But the broad pattern, a major industrial technology initiative announced with high expectations that was later significantly reduced in scope, is consistent with what the industrial IoT adoption literature suggests about the difficulty of actual scale deployment versus proof-of-concept.

The data challenge is where I think the gap is most underappreciated. Predictive maintenance as a use case depends on having enough historical failure data to train a model that can recognize early signs of failure. If your organization has detailed maintenance logs going back five or ten years, with accurate timestamps for when equipment failed and what the sensor readings looked like in the hours before failure, you have the training data you need. Most manufacturing organizations do not have this. They have maintenance records of varying quality, often kept in paper logs, spreadsheets, or multiple systems with inconsistent formats. When the IoT project goes live and the sensors start generating data, the model has nothing reliable to learn from. Getting from "sensors are running" to "we can predict failures" requires building the historical dataset, which takes years of operation, or accepting a model trained on generic equipment profiles that may not match the specific behavior of your specific machines in your specific operating conditions.

There is also a change management dimension that the technology case does not address. Sensors on the floor are, from a worker's perspective, monitoring. Even when the explicit purpose is equipment monitoring rather than performance monitoring, the distinction is not always obvious to the people whose work is now being tracked at higher resolution. Workers who have concerns about surveillance are unlikely to be enthusiastic participants in the system, and without their cooperation, the data quality that the analytics depend on is compromised. I wrote about how technology resistance is actually data, and industrial IoT on the plant floor is one of the clearest examples. Resistance to sensor deployment is often telling you something about the change management process, not about irrational fear of technology.

None of this means industrial IoT does not work. There are real deployments, at scale, in manufacturing environments, that deliver genuine predictive maintenance value. The technology is sound. The challenge is that getting from "this works in a pilot" to "this works across our plant" requires solving a set of problems, legacy equipment integration, connectivity infrastructure, historical data quality, and change management, that are organizational problems, not technology problems. Organizations that go into industrial IoT deployment understanding this upfront tend to build realistic timelines, invest in the organizational prerequisites, and get closer to the outcomes the pilot promised. Organizations that treat deployment as primarily a technology rollout tend to hit those organizational problems as surprises, mid-project, when the budget and timeline have already been set.