Key takeaways
Short answer: Most IIoT projects underdeliver because they skip the basics. A 12-item checklist forces honesty about scope, use case, data quality, security, integration, and ownership before signing a contract. Working through it shifts the question from "can the technology work" to "will the operational change happen." The latter is harder and more important. See also Plant Floor Data Quality.
Use case clarity (item 1). Many projects start with "we need IIoT" without a specific decision the data will enable. The vendor delivers data; the value never appears.
Data quality (item 4). Sensors are installed; data flows; nobody verifies accuracy. Downstream analytics built on bad data fail.
Adoption plan (item 9). Dashboards deployed; nobody changes behavior. The value never appears.
Operational owner (item 10). Project lives in IT; operations does not own the outcome. Drift.
Three common failure modes:
1. Technology-first thinking. "Let us deploy IIoT." Outcome never specified.
2. Pilot that does not scale. Pilot works; scale-up exposes architecture problems.
3. Adoption gap. Data exists; behavior does not change.
The checklist forces each to be addressed upfront.
Vendors typically handle:
Customers must handle:
Most failures are on the customer-responsibility side. The vendor delivered; the customer did not.
Pilots succeed because everyone pays attention. Scale-up fails because the attention dissipates.
Plan scale-up from the pilot phase. Make the scale-up plan part of the pilot success criteria.
1. Skipping use case definition. Most common cause of failure.
2. No data quality plan. Bad data downstream.
3. No operational owner. IT-only ownership produces dashboards no one uses.
4. Pilot success ≠ scale success. Need explicit scale-up plan.
Before signing the vendor contract, work through all 12 items. If any are vague or missing, address them before commitment. Most plants find that working through the checklist either delays the project (because real problems surface) or kills it (because the use case is not real). Both outcomes are better than signing and failing.
A modern OEE platform integrates with IIoT data sources, provides outcome measurement (OEE, MTBF, cost), and supports the adoption-focused workflows that make IIoT pay off.
Fabrico's OEE module integrates with IIoT data, provides outcome measurement, and supports operator and management workflows that turn IIoT data into operational change.
See how Fabrico captures this automatically, explore OEE for manufacturing or book a demo.
A security plan should name its standard. The ISA/IEC 62443 series is the reference for industrial automation and control system security, and IEC 62443-3-2 describes partitioning the system into zones and conduits based on a security risk assessment. In practice, keep PLCs in their own zone, let data leave only through a controlled conduit such as an edge gateway, and connect read-only wherever the use case allows.
If you use OPC UA, turn on its built-in security: each client and server is identified by an X.509 certificate, and messages can be signed and encrypted. If you use MQTT, run it over TLS with authentication, and never leave a broker open on the plant network.
Decide early between polling and publish and subscribe. OPC UA client and server polling is simple for a few machines. MQTT with the Eclipse Sparkplug specification suits many devices reporting by exception, and Sparkplug adds birth and death certificates so every consumer knows whether a device's data is current. Whichever you pick, give the edge device store-and-forward buffering, so a network outage delays data instead of losing it.
Before anyone trusts the dashboard, run an acceptance test. For one full shift, compare the system's piece count and stop list with a manual count and an operator log. Check that every device's clock is synchronized to one time source, because events from machines with drifting clocks will not line up. Sign off the data only when the counts agree within a tolerance you set in advance.
Skipped use case definition, weak data quality, and no adoption plan are the biggest causes.
Operations, with IT and engineering supporting.
3-6 months typical. Less than 3 misses real-world variability.
After data quality is proven and use cases are clear. ML on bad data fails.
Operational owner. Without explicit accountability, the project drifts.
Login
Blog