How to Pilot Guidewheel Beside Existing PLC and SCADA Controls

Most machine-visibility pilots stall on ownership and scope, not on technology. The sensor works, the dashboard fills, and then nobody agreed what the pilot was supposed to prove, who owns the numbers, or what result would justify scaling. This plan fixes four things before anything is installed: the controls boundary in writing, the source of truth for every field, a baseline of what the plant believes today, and the scale-or-stop criteria. Guidewheel does not require PLC access or a connection to the OT network, which is what usually makes the controls team's approval straightforward.

The pilot at a glance

Set the controls boundary first

This is the section that gets you the yes, and it belongs before the hardware conversation rather than after it.

A controls team's objection to a monitoring pilot is almost never about monitoring. It is about who else will now have an opinion about their network, their controllers and their change process. Answer that in writing, before anyone asks, with four commitments.

1. No control authority, ever. The system reads. It does not write setpoints, issue commands, or participate in any interlock. Put this in the pilot scope document rather than leaving it to be inferred from a demo.

2. No PLC access. Guidewheel reads the machine's power conductor, not its control system. Nothing is connected to a controller, no tags are mapped, and no controller configuration changes.

3. No OT network connection. The data path does not run over the plant's operational technology network. State the path explicitly in the document so the security owner can review it once rather than repeatedly.

4. Any controls-adjacent work follows your existing change process. Name the process and the approver. This costs nothing and removes the fear that a pilot becomes a precedent for bypassing it.

Get those four signed by the controls owner before the first sensor arrives. A pilot that starts with the boundary agreed almost never has a turf fight later; a pilot that starts with a dashboard demo frequently does.

With the boundary fixed, you can choose where to run.

Choose a representative line

Pick the line that will teach you something, not the one that will look good.

The instinct is to pilot on the newest cell, because it is clean, instrumented and staffed by the people most likely to engage. That pilot will succeed and will tell you almost nothing about the rollout, because the rollout will mostly happen on assets that are none of those things.

A representative pilot line has four properties:

• At least one asset with no controller. This is the population the business case depends on, and it is the population most likely to need threshold work.
• A machine with genuinely variable load. If your floor has one, include it. Variable-load assets produce the most confusing accuracy results and you want that surprise in a pilot rather than at machine sixty.
• A shift where behaviour actually varies. Guidewheel's 2026 Factory Uptime Report found the same crew running the same changeover showing a 57% shift-to-shift spread. A pilot that samples only days will underestimate both the variation and the opportunity.
• A supervisor who will use the data. The technical result is easy; the adoption result is the one that predicts scale.

Size it modestly. Guidewheel's Seacast case study reports ten machines live in two days and 30 fully deployed within a month, spanning presses, x-rays, lathes and welders, which suggests the constraint on a pilot is rarely installation time. Ten to fifteen assets across one line and one awkward neighbour is usually enough to answer every question a scale decision needs.

Before anything is installed, settle who owns which number.

Name the source of truth per field

Write a single table, agree it, and stop relitigating it.

Almost every dispute in a running deployment is an ownership dispute that nobody settled in advance: two systems report a different downtime total, and the argument that follows is about credibility rather than about either number. Fixing it costs one meeting before installation.

The last row matters more than it looks. If nobody owns the published number, two will appear within a month and the pilot will be judged on the discrepancy rather than the result.

With ownership settled, you need something to compare the result against.

Baseline before you install

Record what the plant currently believes, and how it knows, before any sensor changes the answer.

This step is skipped more often than any other, and skipping it is what makes pilots unprovable. Four weeks in, the data shows the line losing nine hours a week. Is that better or worse than before? Nobody can say, because the previous number was a monthly average assembled from shift reports and half-remembered stoppages.

Capture four things:

• Current OEE or uptime, and the method that produced it. The method matters more than the figure. A number from operator logs and a number from machine data are not comparable, and knowing that in advance prevents an unwinnable argument later.
• Current downtime hours per week on the pilot assets, with the same caveat.
• The current top three downtime reasons, as the plant would report them today.
• How long it currently takes to produce a shift report, in person-minutes. This is often the first measurable saving and almost nobody records the starting point.

Expect the baseline to be wrong, and say so up front. That is not a criticism of anyone. Guidewheel's 2026 Factory Uptime Report found 48% of measured downtime sitting in three under-instrumented categories, electrical, material and staffing, and its downtime analysis puts staffing events at roughly 197 minutes and material or supply delays at roughly 119 minutes on average. Losses of that size do not go unnoticed because people are careless; they go unrecorded because nobody raised a work order for them.

Framing the baseline as "what we believed" rather than "what was true" also protects the pilot politically. The result is then a change in visibility rather than an accusation about the old numbers.

Now define what result would justify scaling.

Agree scale-or-stop criteria

Five criteria, written down before the pilot starts, each with a number and a fail action.

1. State accuracy. At least 95% agreement with observed events on running versus not running, across all pilot assets including the one with no controller. The method is in validating run, idle and down accuracy. Fail action: identify whether it is one asset class or systemic, and scope accordingly rather than abandoning.

2. Reason completeness. The share of downtime minutes carrying an operator reason, sustained across four consecutive weeks rather than measured in week one. Fail action: this is a taxonomy or training problem, not a sensor problem. Fix it before scaling, because it does not improve with more machines.

3. Time to first useful decision. The date on which someone changed something because of the data. Fail action: if no such date arrives inside the pilot, the deployment will not survive contact with a busy quarter.

4. Implementation hours consumed from your own team. Tracked, not estimated afterwards. Fail action: if the real figure is far above the projection, recalculate the rollout on the real number before committing.

5. Coverage achieved. Assets reporting against assets promised. Fail action: identify which asset class failed and whether it represents a large share of the estate.

Then write the stop action itself, in one sentence, and have the sponsor agree it. Pilots rarely fail cleanly. They drift, because nobody wants to be the person who called it, and a drifting pilot consumes credibility that the next initiative will need.

Set a review date at the outset and put it in a calendar, with the sponsor present. A pilot with a scheduled decision date ends in a decision; a pilot without one ends when somebody loses interest.

For the broader boundary between a visibility layer and the controls stack, see Guidewheel versus SCADA and the no-PLC monitoring guide. To express the result commercially, production monitoring ROI covers how to frame it for a finance audience, and Guidewheel's 2026 Factory Uptime Report sets benchmark context for the baseline.

Frequently asked questions

About the author