Machine Visibility RFP Checklist for Plants With SCADA or MES

If your plant already owns a controls stack, a machine-visibility RFP is mostly about boundaries and evidence, not features.

The vendors will all demo a dashboard. What separates them is what they require from you: whether they touch the control system, whether they need a network path your OT team must approve, which assets they can reach without a controls project, how much operator time the data costs, and who owns the thing after go-live. This checklist covers eleven categories, states what to ask in each, and defines the pass condition, including the lines Guidewheel itself does not clear.

The RFP checklist at a glance

Control boundary requirements

Write these four as statements the vendor either agrees to or does not. Do not phrase them as questions, because a question invites a paragraph and a statement invites a yes.

1. The system will not write to the process under any circumstance. No setpoints, no commands, no participation in interlocks, no exceptions for a future module. Ask for it in the contract, not the proposal. A vendor whose architecture cannot write to the process will sign this immediately, which is itself informative.

2. The system will not require OT network access. If it does, that is not disqualifying, but it moves the project from a purchase into a network change with your OT security owner as an approver and a timeline you do not control. Make the vendor state the required path explicitly: cellular, plant wifi, wired, or a connection through an existing gateway.

3. No firewall changes will be required for standard operation. Ask what happens at renewal, at upgrade, and when a new asset is added.

4. Any controls-adjacent work follows our change process. Name the process and the approver in the requirement, so it cannot be treated as an implementation detail later.

Guidewheel meets the first three by architecture rather than by policy: it does not require a PLC connection or OT network access, because it reads the machine's power conductor rather than its control system. That should still be verified rather than assumed, which is what the accuracy and coverage requirements are for.

Signal and coverage requirements

Specify what the system must produce without a human, and on which of your actual assets.

List the fields, and mark which require operator input. Machine state, stop duration, stop frequency, cycle count, downtime reason, reject count, job context. Most platforms produce the first four automatically and need people or an integration for the rest. A proposal that implies all seven arrive automatically deserves a follow-up question.

Name your worst assets in the RFP, by asset. Not "legacy equipment" but the 1998 press with no network drop, the two ovens, the shared compressor. Ask each vendor to state, per asset, whether it can be covered, what hardware that needs and what controls work is involved. This single requirement separates vendors faster than any feature matrix, and it stops the demo happening on the newest cell.

Demand an accuracy standard with a method attached. A vendor claiming high accuracy should be able to say how it is measured and against what. The pre-rollout method in validating run, idle and down accuracy is a reasonable standard to hold everyone to: ground truth from known events, a numeric threshold per state, and criteria agreed before the data is seen.

Ask what happens on a machine with variable load. Every current-based approach has an answer, and the quality of the answer tells you how much real deployment experience is behind the proposal.

Coverage evidence is worth more than a coverage claim. Guidewheel's Seacast case study records 30 machines deployed in one month spanning presses, x-rays, lathes and welders, which is the kind of evidence to ask every vendor for: named machine types, a real timescale, and a named customer.

Commercial and ownership requirements

Ask about disclosure before you ask about price, because disclosure varies enormously across this market and it determines whether you can compare at all.

Some vendors publish a figure you can put in a model. Guidewheel publishes an entry tier: from $15,000 per year including the first 10 machines. Others publish nothing and quote on volume. MachineMetrics, for example, describes its pricing as volume based, with the per-machine cost falling as you connect more, but does not publish numeric software pricing, and its Edge gateways and sensors can be bought through the vendor or procured independently without a published figure. Neither posture is wrong, but a shortlist mixing the two cannot be scored on price without normalising first.

So require the following from every vendor, in writing:

• The complete list of what the quoted figure excludes. Sensors, gateways, displays, cabling, installation labour, shipping, integrations, custom development, on-site visits, and renewal uplift.
• The five-year cost at our asset count, not the entry tier, with the expansion increment stated.
• What is bundled that we would otherwise buy. Support, onboarding and training are genuinely included by some vendors and charged by others; MachineMetrics bundles unlimited remote support, onboarding and training into the subscription, which is a real procurement advantage worth crediting.
• Who owns the system after go-live. Who adds an asset, who changes a metric definition, who fixes a broken report, and whether any of that is chargeable.
• What happens to our data if we leave. Export format, retention period, and whether historical data survives.

The last two are where multi-year cost actually accumulates, and they are almost never in the proposal unless you ask.

Pass and fail pilot criteria

Five numbers, agreed before the pilot starts, each with a stated fail action.

1. State accuracy. At least 95% agreement with observed events on running versus not running, measured on four representative machines including one with no controller.
2. Adoption. The share of downtime minutes carrying an operator reason, sustained over four consecutive weeks. This is usually the criterion that decides whether the deployment is worth anything, and it is the one most often left out of pilots.
3. Time to first useful decision. The date on which someone changed something because of the data. If that date never arrives, the pilot succeeded technically and failed commercially.
4. Implementation hours consumed from our team. An hour figure, tracked, not a day count estimated afterwards. Vendors quote their own effort; almost nobody quotes yours.
5. Coverage achieved. The proportion of the named asset list actually reporting, against the proportion promised in the proposal.

Write the fail action next to each. If adoption lands at 40%, do you extend the pilot, change the taxonomy, retrain, or stop? Deciding in advance stops a middling pilot from drifting into a third quarter while nobody wants to make the call.

One more requirement worth adding: the pilot must include a machine the vendor did not choose. Pilots run on hand-picked assets tell you what the best case looks like, which is not the number you are buying.

Weighting the eleven categories. An unweighted checklist treats the exit clause as equal to control authority, which is how a shortlist ends up recommending the wrong vendor on points. Split the categories into three tiers before scoring.

Tier one, pass or fail, no score. Control authority and network path. A vendor that will not sign the control boundary is not on the shortlist, regardless of how it performs elsewhere. Scoring these numerically lets a strong showing on features outweigh an unacceptable architecture, which is exactly the failure the checklist exists to prevent.

Tier two, heavily weighted. Coverage of your named assets, accuracy evidence, and ownership after go-live. These three determine whether the system works on your floor and whether it keeps working once the implementation team leaves. In practice they separate vendors more than anything else in the list.

Tier three, weighted normally. Signals, operator workload, integrations, rollout labour, commercial disclosure and exit terms. Real considerations, but recoverable if you get them slightly wrong.

Score against evidence, not assertion. For every category, record what the vendor supplied: a contract clause, a named reference, a documented method, or an assurance in a meeting. Assurances score zero. This single rule is what stops a polished proposal from outscoring a capable product.

The full sequence for running such a pilot alongside an existing controls stack is in how to pilot beside existing PLC and SCADA controls.

Where Guidewheel scores poorly on this checklist

A scorecard published by a vendor is worth reading only if the vendor fails some of it. Here is where Guidewheel does.

Process variables: fails. If your requirement list includes temperature, pressure, flow, torque or recipe parameters, Guidewheel does not supply them. Current draw is not a proxy for a process tag, and a plant that needs those should score this line against us and look at a controls platform or a historian.

Component-level diagnosis: fails. Guidewheel does not identify a failing bearing or a degrading gearbox. It is not a predictive maintenance tool. Guidewheel's own guidance points to condition-based sensing for critical rotating assets rather than claiming current data covers it.

Work orders, parts and labour: fails. No work-order management, no parts inventory, no maintenance history. That belongs in a CMMS and the checklist should say so.

Regulated genealogy and validated records: fails. If the requirement is batch genealogy for a regulated product, that is MES and quality-system territory.

Job and order context: partial. Available through integration, not from the sensor. Score it as an integration requirement with a named owner rather than a native capability.

Two lines Guidewheel does clear that are worth checking hard on any vendor: no control authority by architecture, and no OT network dependency. Both should be verified in the pilot rather than accepted from a datasheet.

The full disqualifier list is in when Guidewheel is not the right tool. For the general market view this checklist deliberately does not repeat, see the machine monitoring software buyer's guide.

Frequently asked questions

About the author