Industrial IoT programmes on Indian factory floors tend to follow a recognisable arc: sensors are installed, a dashboard appears, executives are shown live machine data, and then nothing changes. Output is the same, downtime is the same, and eighteen months later the dashboard is open on a screen nobody looks at. The failure is almost never the sensors.
It begins with instrumenting for visibility rather than for a decision. The question that should precede any installation is which decision this data will change, who makes it, and how quickly they need it. Vibration data on a motor is worth collecting if somebody will schedule maintenance differently as a result. If the maintenance schedule is fixed by contract and nobody may change it, the data is expensive decoration however good the dashboard looks.
The second problem is the gap between the shop floor and the planning system. Machines speak industrial protocols; the ERP speaks business objects. Without integration between them, the plant has real-time knowledge of its capacity that never reaches the people committing to delivery dates. Closing that gap - actual machine availability informing the production plan - is usually where the largest return sits, and it is unglamorous integration work rather than anything to do with analytics.
Third is assuming connectivity that a factory does not have. Plants have metal, interference, dust and unreliable links, and a design that streams every reading to the cloud loses data whenever the link drops. Edge collection with local buffering and store-and-forward is not an optimisation, it is a requirement - the device must keep recording through an outage and reconcile afterwards. Designs that assume a good network are the ones that quietly develop gaps in their history.
Fourth is jumping to predictive maintenance before the basics are in place. Predicting failure requires a meaningful history of failures with known causes, correctly labelled. Most plants beginning this journey do not have that, and the models trained on what they do have predict nothing useful. Start with condition monitoring and threshold alerting, which delivers value immediately and, crucially, generates the labelled failure history that a predictive model will need in two years.
Fifth, and the one that decides the whole programme: the operators. A system that tells a supervisor a machine is drifting, in a form they can act on during their shift, gets used. A system that produces a report for head office does not, and the people closest to the equipment quietly work around it. Design the first output for the person on the floor, and the rest of the programme tends to look after itself.
