Home
/
Guides
/
How to Structure an IIoT Pilot That Can Scale
Guide
How to Structure an IIoT Pilot That Can Scale
Around 60% of IIoT initiatives stall at the proof-of-concept stage. Most fail not because the technology does not work, but because the pilot was designed to prove the technology — not to prove that it can scale. This guide covers the difference.
The problem with most IIoT pilots
Most IIoT pilots are designed to succeed at the pilot stage. A vendor selects the best-case machine, the most cooperative controls engineer, and the cleanest data source in the facility. The pilot runs. The dashboard looks good. The steering committee approves phase two. Then the project stalls when the team discovers that the other 47 machines run different PLCs, use different tag naming conventions, generate data at different rates, and were never part of the pilot scope.
A pilot designed to prove the technology is different from a pilot designed to prove scalability. The conditions that made the pilot succeed — one machine, one protocol, one cooperative engineer — do not exist across the full facility.
Assemble the right people first
Four stakeholders need to be in the room when the pilot is scoped. If any of them are missing, their constraints will surface later and derail the project.
Operations
COO / Plant Manager — the KPI owner
Owns the metric the pilot is supposed to move. Defines what success looks like in business terms. Without their definition of success, the pilot has no agreed outcome.
Controls / OT Engineering
Controls Engineer / Automation Lead — the data owner
Knows what the target equipment communicates, how it is networked, and what cannot be touched. Defines feasibility. Their veto is the hardest to recover from post-scoping.
Enterprise IT / Cloud Architecture
IT Architect / CDO — the infrastructure owner
Owns the network, the cloud platform, and the data architecture the pilot will eventually feed. Defines the destination and the connectivity requirements to reach it.
Cybersecurity / InfoSec
CISO / InfoSec Lead — the gatekeeper
Distinct from general IT. Approves firewall rules, edge device hardening, and outbound connectivity. Getting their sign-off after the gateway is configured is a project restart. They must be in the room before scoping begins — not after.
You also need a documented baseline before any hardware is installed: current OEE, downtime hours and costs, existing data collection methods, and the machines in scope. Without a baseline, you cannot demonstrate ROI and you cannot make a credible case for scaling.
The three constraints that block scale-out
A scalable pilot deliberately tests the hard problems. Structure the scope around the three constraints that most commonly prevent pilots from reaching production.
If your facility has four PLC brands, the pilot should include at least two. A pilot that proves connectivity to one CompactLogix does not prove the platform can connect to the Siemens S7 on the adjacent line. Deliberately include a legacy or non-standard device.
Connectivity alone is not the test. The real scaling problem is semantic normalization. If the CompactLogix names its spindle speed tag Spd_RPM and the Siemens names it Rotational_Velocity, your data pipeline fragments at scale. The pilot must prove the platform can map both devices into the same semantic data model — the same tag name, the same unit, the same UNS path — before the data leaves the factory floor.
The pilot should cross at least one network boundary and test the architecture that will apply at scale. In industrial environments, that architecture is defined by the Purdue Model (ISA-95 / IEC 62443).
Purdue Model — edge gateway placement
Level 4–5
Enterprise / Cloud — ERP, analytics, cloud data platform
Level 3.5
DMZ — Edge gateway sits here. Outbound only: port 8883 (MQTT) or 443 (HTTPS). No inbound to PLCs.
Level 3
Site operations — Historian, SCADA, MES
Level 2
Control systems — DCS, SCADA supervisory
Level 1–0
Field devices — PLCs, sensors, actuators
The edge gateway sits at Level 3.5. It pulls data up from Levels 1 and 2 and pushes it outbound to the enterprise layer at Level 4. The traffic pattern is strictly one-way outbound — no inbound connections back to the PLCs are permitted.
Do not run the pilot gateway on the corporate LAN and discover the segmentation requirements at rollout. Test it from the Level 3.5 DMZ position with InfoSec's firewall rules in place. If the platform cannot operate under those constraints in the pilot, it will not operate at scale.
The pilot should include at least one workflow change: a maintenance team responding to a predictive alert, an operator acknowledging a quality exceedance, a supervisor reviewing a shift report generated from IIoT data. Data collection is the easy part. Getting operations teams to change their workflows based on data is the thing that determines whether the program delivers ROI.
If nobody changes their behavior during the pilot, the pilot has not tested the thing that matters.
Define these before the pilot starts
Primary metric
One number the pilot is designed to move. Unplanned downtime hours, OEE percentage, MTBF on a specific asset class. A pilot with five metrics has no metrics.
Duration
8 to 12 weeks. Shorter does not generate enough data. Longer loses organizational attention and invites scope additions. Fix the end date before the pilot starts.
Scale-out criteria
What has to be true at the end for the organization to approve full deployment. Include TCO predictability: many pilots succeed at ten tags and become commercially unscalable at 50,000 tags under consumption pricing. Get the vendor's committed commercial model for the enterprise footprint before the pilot ends.
Scope boundary
An explicit list of what is in scope and what is not. Every addition extends the timeline and dilutes focus. The team needs explicit authority to hold this boundary and redirect additions to phase two.
Where pilots break down
The steering committee sees the dashboard and asks for three more machines, two more metrics, and a mobile app. Every addition extends the timeline and dilutes focus on the primary metric. Frame additions as phase two scope. The team needs explicit authority to say no during the pilot period.
When the IIoT vendor's professional services team runs the pilot, the vendor controls the scoping, the configuration, and the success criteria. The internal team learns nothing about operating the platform and has no basis for evaluating whether results are reproducible without the vendor. Run the pilot with internal staff supported by the vendor, not the reverse.
The controls engineer configures the gateway. IT approves the network segment. InfoSec identifies the gateway as an uncertified device transmitting on a non-standard port and requires it to be decommissioned pending a security review. This is entirely preventable. InfoSec's requirements must be incorporated into the pilot architecture from day one, not discovered at deployment.
The pilot successfully reads tags from two different PLC types. The data arrives in the cloud with different tag names, different units, and different quality flags for the same physical measurement. The analytics platform cannot compare them. Semantic normalization must be tested in the pilot — not assumed and discovered missing at scale.
One gateway during a pilot is manageable. Five hundred gateways across twelve factories is a different problem. If the platform does not include a centralized edge orchestration layer for pushing OS updates, security patches, and driver changes to remote gateways, you are buying a maintenance burden that grows with every site added. Verify edge management capability in the pilot, not after the enterprise rollout has started.
Positive results followed by six months of budget debates kills more IIoT programs than technical failure. Build the phase two decision into the pilot timeline. The scale-out proposal should be ready before the final results are presented, not drafted afterward.
Related: the Unified Namespace guide covers semantic normalization in detail. The protocol compatibility guide covers how to verify connectivity claims before the pilot starts. The vendor index edge section covers platforms with centralized edge orchestration capability.
Stay current
The Fallout tracks vendor durability and M&A risk across the cybersecurity market. Five days a week.