No items found.
blog
When Guidewheel Is Not the Right Tool
By: Guidewheel
Updated:
11 min read
Six things will disqualify Guidewheel, and it is faster for both of us if you check them first. If you need to change the process rather than observe it, you need a control system. If you need temperatures, pressures or recipe parameters, you need SCADA or a historian. If you need validated genealogy for a regulated product, you need an MES or a quality system. If you need work orders, parts and labour, you need a CMMS. If you need to know which bearing is failing, you need condition monitoring. If you need inventory, Guidewheel does not do it.
The disqualifiers at a glance
- Guidewheel observes. It does not control. No setpoints, no interlocks, no commands, ever.
- It reads power, not process. No temperatures, pressures, recipe parameters or controller tags.
- It is not predictive maintenance. It does not forecast failures or diagnose components.
- It is not an MES or a CMMS. No work orders, no genealogy, no inventory.
- Where it does fit: mixed-age fleets, assets never worth integrating, and cross-site operating comparison you need this quarter rather than next year.
| If you need this | Guidewheel | Use instead |
|---|---|---|
| To change a setpoint or hold a safety interlock | No | PLC and SCADA |
| Process variables: temperature, pressure, flow, recipe | No | SCADA and a historian |
| Validated genealogy or regulated batch records | No | MES or quality system |
| Work orders, parts, labour, maintenance history | No | CMMS |
| Component-level diagnosis on rotating equipment | No | Condition monitoring |
| Inventory or materials management | No | ERP |
| Run, idle and down truth on every machine including old ones | Yes | - |
| One comparable operating picture across plants | Yes | - |
| Coverage without a controls project or IT involvement | Yes | - |
When Guidewheel is the wrong tool
Six disqualifiers, each with the system that actually answers it.
You need to change the process. Setpoints, sequences, safety interlocks, anything that writes back to the machine. Guidewheel has no control authority by design and will never acquire it. This is a PLC and SCADA requirement, and no visibility layer should be considered for it.
You need process variables. Temperature, pressure, flow, torque, position, recipe parameters. A current signature tells you a machine is drawing power and how that draw behaves over time. It does not tell you the barrel is at 240 degrees. If your question is why a batch drifted out of specification, you need SCADA and a historian.
You need validated genealogy or regulated batch records. Which lot went into which product, signed, timestamped and auditable. That is an MES or quality-system function with validation requirements attached, and reconstructing it from machine signals is not acceptable to any regulator.
You need work-order management. Raising, assigning and closing work, holding parts and labour, maintaining asset history. That is a CMMS. Guidewheel does not raise work orders and does not hold maintenance records.
You need component-level diagnosis. Which bearing is degrading, whether a gearbox is developing a fault, how much life is left in a component. That is condition monitoring, using vibration, temperature or ultrasound on the asset itself. Guidewheel is not a predictive maintenance tool and does not forecast failures. Guidewheel's own guidance on older equipment points to condition-based sensing for critical rotating assets rather than claiming current data replaces it.
You need inventory or materials management. Guidewheel does not do it, and nothing about the architecture suggests it should.
If any of those is your primary requirement, stop here. The rest of this article is for readers whose requirement survived the list.
Limits that are real but not disqualifying
These will not rule Guidewheel out, but you should plan around them rather than discover them.
Current sensing infers, it does not read. Machine state is derived from the electrical signature rather than reported by a controller. On availability and state timing that inference is strong. On anything requiring a controller's own reporting, it is not the right source. The practical consequence is that you should validate accuracy on your own assets before scaling, not after. The method is in validating run, idle and down accuracy.
Some machines need threshold work. Assets that keep hydraulics, heaters or drives energised between parts can read as running when they are idle, until the thresholds are tuned for that asset class. This is normal and fixable, and it is the single most common finding in a validation window. It is also why a pilot should include your most awkward machine rather than your newest one.
✅
When piloting Guidewheel, include your most awkward machine — the one with hydraulics, heaters or drives that stay energised between parts — rather than your newest asset. Threshold tuning on difficult machines is the single most common finding in a validation window, and testing it early prevents surprises at scale. Also budget for operator adoption and quality-context integrations from the start, since reject counts, scrap reasons and job context are not in the power signature.
Quality and job context need a person or an integration. Reject counts, scrap reasons and which job was running are not in the power signature. They come from an operator, a quality system or an ERP integration. Budget for that rather than assuming it arrives.
Reason quality depends on operator adoption. The system captures the stop automatically; the reason still comes from a human. A plant that does not invest in the taxonomy and the habit will get accurate durations attached to unhelpful reasons, which is a real limitation of the whole category rather than of one product.
Our own materials also note constraints such as setup friction on very old equipment and caps on some report ranges. Those are internally reported rather than published, so treat them as questions to raise in a pilot rather than settled facts.
None of that changes what the product is for, which is the next question.
Where Guidewheel does fit
Four situations, and they have a common shape: you need coverage across machines that were never worth a controls project, and you need it soon.
Mixed-age fleets. A floor with a new cell, a fifteen-year-old line and a press from the nineties. Anything that reads the control system covers a subset and leaves the rest dark. Current sensing does not care how old the machine is, only that it draws power.
Assets nobody integrated. The compressor, the ovens, the ancillary conveyors, the rented machine. Individually none justified an integration; collectively they are often where a surprising share of the loss sits.
Cross-site comparison on a real timescale. When leadership wants comparable operating numbers across several plants this quarter, a per-site controls project is not a plan. 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. That is a first-party result rather than a guarantee, but the machine spread is the relevant part.
No controls capacity available. If the controls team's queue is the binding constraint, an approach that does not touch the control system removes the dependency entirely. Installation is described as taking as little as a day, and pricing starts at $15,000 per year including the first 10 machines, which is a published figure rather than a scoped estimate.
Fitting one of these does not mean Guidewheel replaces anything you already run, which is worth being explicit about.
Where it complements another system
In most plants the honest answer is not "instead of" but "alongside", with a boundary written down.
Alongside SCADA. SCADA keeps control authority, process tags and the controlled process. Guidewheel covers the assets SCADA never reached and owns the operating metrics on top. The full boundary, including which system owns which field, is in Guidewheel versus SCADA.
Alongside an MES. The MES owns work orders, scheduling, recipes, traceability and batch records. Guidewheel owns real-time machine state. Guidewheel's own comparison of MES and IIoT platforms draws the functional line but stops short of a field-by-field ownership matrix, which is worth building for yourself before the two systems start disagreeing.
Alongside a CMMS. Monitoring detects and quantifies the stop; the CMMS manages the response, the parts and the history. The handoff between them is covered in machine monitoring versus CMMS.
Alongside condition monitoring. These answer different questions and should be sequenced rather than traded off. Condition monitoring judges whether a component is degrading; production monitoring finds where output is going. The boundary is set out in production monitoring versus condition monitoring.
The rule that makes coexistence work is simple: one named owner per field, agreed before installation. Most integration arguments are ownership arguments that nobody settled in advance.
A short self-qualification checklist
Eight questions. Any yes in the first group is a disqualifier on its own.
Group one: does any of this describe your primary requirement?
- We need the system to change the process, hold an interlock, or write a setpoint.
- We need temperature, pressure, flow, torque or recipe parameters.
- We need validated genealogy or regulated batch records.
- We need work orders, parts, labour and maintenance history.
- We need to know which specific component is degrading.
If you answered yes to any of those, Guidewheel is not your answer for that requirement, and the systems that are appear in the section above.
Group two: does any of this describe your situation?
- A meaningful share of our machines has no controller worth integrating.
- We cannot say, with numbers we trust, where our production time went last week.
- We need comparable operating data across sites sooner than a controls project can deliver it.
Two or more yes answers in group two, and no yes answers in group one, is the profile Guidewheel was built for. One yes in group two is worth a conversation. Zero is a sign your problem is somewhere else, and you should keep your money.
For the product scope in full, see the FactoryOps overview, and for what an engagement costs, the published entry tier is on the pricing page.
If you want a straight answer about whether your plant fits, talk to the Guidewheel team. A no is a faster outcome for both sides than a pilot that was never going to work.
Frequently asked questions
What are Guidewheel's limitations?
It has no control authority, no process tags, no work-order management, no component diagnosis and no inventory function. Beyond those hard boundaries, current sensing infers state rather than reading it from a controller, some assets need threshold tuning before they read correctly, and quality and job context require an operator or an integration. None of that is hidden and all of it should be tested in a pilot.
Is Guidewheel a predictive maintenance tool?
No. It does not forecast failures, estimate remaining useful life or diagnose components. Those questions need sensors measuring the physical condition of the asset, such as vibration or temperature, plus the analysis to interpret them. Guidewheel's own guidance on older equipment recommends condition-based sensing for critical rotating assets rather than claiming current data covers it.
Can Guidewheel replace our MES?
No. An MES owns work orders, scheduling, recipes, traceability and batch records, and Guidewheel owns none of them. The two coexist, with the MES holding order and genealogy context and Guidewheel holding real-time machine state. Any vendor suggesting a monitoring layer replaces an MES is describing a different product from the one you would be buying.
Does Guidewheel work for regulated or validated production?
Not as the system of record. Validated genealogy, batch records and regulated documentation belong in an MES or quality system with the validation obligations that implies, and reconstructing them from machine signals is not acceptable to a regulator. Guidewheel can run alongside those systems to supply operating metrics, but it should never appear in a compliance argument.
When should we choose something else?
Whenever your primary requirement is to change the process, read process variables, hold validated records, manage maintenance work, or diagnose a specific component. Each of those has a correct answer that is not Guidewheel: a control system, a historian, an MES or quality system, a CMMS, and condition monitoring respectively. Disqualifying early is a better outcome for both sides than a pilot that was never going to fit.
About the author
