What should you actually measure on your machines?
Most machine builders can log hundreds of signals, but struggle to say which ones tell them anything. The problem is rarely too little data. It is knowing what is worth measuring. Here is a practical way to decide.
Talk to almost any machine builder with connected machines and you hear a version of the same thing. The data is there. Hundreds of PLC tags, alarms and counters are flowing. And yet nobody can confidently say which of those numbers actually helps run the business better.
This is not a data problem. It is a definition problem. Machine builders are experts in mechanics and control, not in KPIs. Logging a signal is easy. Deciding which signals are worth turning into a metric, and which are just noise, is the hard part. And it is the part that determines whether all that data ever becomes useful.
The "log everything" trap
The instinct is understandable: capture as much as possible now, figure out the rest later. In practice that produces three problems. More data to store and pay for, dashboards crowded with numbers nobody acts on, and a vague sense that the insight must be in there somewhere. Volume is not the same as visibility.
The fix is to turn the usual order around. Do not start from the data you happen to have. Start from the decision someone needs to make.
Start from the decision, not the data
A measurement is only worth taking if it changes a decision. So the right sequence runs backwards from the business question to the signal on the machine:
Decision → KPI → required signal → data model → dashboard
A service manager wants to know where to send attention, so the KPI is downtime by cause and mean time between failures, which requires stop events with reason codes. A commercial lead wants to offer customers an uptime guarantee, so the KPI is achieved uptime per customer, which requires machine state mapped to the right customer and site. Each time you work from the decision to the data, not the other way around.
A simple test for any signal: if you had this number on a screen tomorrow, what would you do differently? If the answer is "nothing", it is storage cost, not a KPI.
What is usually worth measuring
For machine builders in packaging and similar discrete production, a small set of metrics covers most of the real value. The point is not to build all of them at once, but to recognise which ones map to a decision you actually care about.
| If you want to know… | Measure (KPI) | You need (signal) |
|---|---|---|
| Where to focus service effort | Downtime by cause, MTBF, MTTR | Stop and alarm events with reason codes |
| Whether a line is losing speed | Performance / speed loss, micro-stops | Cycle count vs design speed, state transitions |
| How much you really produce | Throughput, OEE | Production counter, run/stop state, good/reject count |
| Which machines underperform | Fleet benchmark (OEE compared) | The same KPIs, normalised across machines |
| If you meet uptime promises | SLA / uptime per customer | Machine state plus customer and site mapping |
| When a wear part is due | Remaining component life | Running hours or cycles per component |
Notice the last two rows. Comparing machines against each other and reporting uptime per customer are exactly the questions a single-machine view cannot answer. They only become possible once the data sits in a structured layer that spans the whole fleet.
Be honest about what the data can carry
Not everything on the wishlist is available straight away, and pretending otherwise is how projects lose trust. A few realities worth naming early:
- Downtime by cause needs reason codes. If stops are not categorised at the machine, you can measure how long a line was down, but not why. That is a configuration step, not a dashboard step.
- Energy and giveaway usually need extra metering. Power per unit or fill-weight deviation often is not on the PLC. It requires a meter or checkweigher to exist first.
- Quality metrics depend on counters that are really there. A reject rate is only as good as the reject counter behind it.
Naming these limits upfront is not a weakness. It is what separates a measurement plan you can deliver from a wishlist that stalls.
A short framework to decide
When you are not sure whether a signal deserves to become a KPI, these questions usually settle it quickly:
- What decision should this inform, and who makes it? If you cannot name the person and the choice, stop here.
- What would change if you had the number? A metric that changes nothing is not worth building.
- Is the signal actually on the machine? Or does a tag, counter or reason code need to be added first?
- Does it need other data to mean something? Linking to ERP, MES or a customer record changes the effort.
- One machine, or the whole fleet? Comparing and benchmarking is a different layer than monitoring a single machine.
Where this fits
Deciding what to measure is the first real step, well before any dashboard. It is also the cheapest place to get it right, because every later choice (which signals to collect, how to model them, what to show) follows from it.
This is exactly what a Quick Scan is for. In a short, fixed-scope session we work through your priority decisions, shortlist the KPIs that earn their place, and check which signals are realistically available. You leave with a written shortlist of what to measure and why, and a clear next step. No deck, no pitch.
Not sure what is worth measuring?
A Quick Scan turns a wall of signals into a short, defensible list of what to measure and what it is worth. Fixed scope, written output.