Everybody wants more data off the manufacturing floor. Almost nobody asks whether the data they're about to collect is worth having.

I get asked to put sensors on aging equipment more often than actually makes sense. Plant managers hear “predictive maintenance” and “real-time visibility” at a trade show, and by Monday they want a project scoped.

Most of those projects shouldn't happen. The technology works fine, but nobody asked the two questions that matter:

1. Will This Data Change a Decision in the Next 12 Months?
2. How Long is the Machine Staying?

Sensors and connectivity got cheap enough that almost any machine can be wired up in an afternoon. That's exactly the problem. Ten years ago, the cost of the hardware forced some discipline into the decision, because nobody was going to spend real money instrumenting a machine on a whim. Now the barrier's gone, and the discipline has to come from somewhere else.  

The two questions outlined below are less about the sensor and more about whether the data changes a build or rebuild decision you're already facing. If it doesn't, the sensor is the wrong place to spend your time.

Both questions take about 5 minutes to ask. Skipping them costs a lot more than 5 minutes down the road. Someone still has to scope the sensor, install it, and keep a dashboard fed that nobody ends up logging into. That's labor, and on a manufacturing floor right now, labor is the resource you can least afford to burn on a vanity metric.

Question 1: Will This Data Change a Decision in the Next 12 Months?

If you can't point to the decision sensor data will change, what you're building is an expensive screensaver.

Take vibration data on a bearing that causes your line to go down twice a quarter, with nobody sure when the next failure's coming. That data changes a real decision: when to schedule the repair, and whether to keep firefighting or finally fix the root cause.

A bearing you're already replacing on a fixed schedule doesn't need that same sensor. You already know what you're going to do with it.

Ask it plainly before you spend a dollar on sensors. What decision, in the next year, gets made differently because you have this data? If the honest answer is none, or “it would be nice to know,” stop there.

There's a follow-up hiding inside that first question: compared against what? Data on its own can't tell you good from bad. You need a reference, and there are only three places it can come from:

• The machine's own history, meaning you instrumented it while it was healthy and you're watching for drift.
• A published standard, like vibration severity bands, that lets you judge the reading outright.
• Or a fleet of similar machines, where the outliers show themselves.

One machine with no baseline and no peers gives you orphan data. If none of those three references exists, the sensor can wait until one does.

Question Two: How Long is the Machine Staying?

How long will a machine be used in a manufacturing facility? This question gets skipped more than it should, and it's the cheaper one to ask.

If a machine's on a 2-year path to replacement anyway, whatever you spend instrumenting it walks out the door with it. Data infrastructure has to earn its keep over the equipment's full remaining service life, which usually runs well past a single budget cycle.

There's an exception. If the machine being replaced is one you're rebuilding rather than scrapping, that data has somewhere to go: straight into the design of what replaces it. Paired with whoever's building the replacement, it says which parts of the old machine worked and which didn't, so the new build only re-engineers what needs it and doesn't regress the parts that were already fine.

You can absolutely justify data collection on aging equipment, as long as the machine you're wiring up is one you're keeping long enough to earn it out, or one whose data is feeding directly into its replacement.

That means asking the capital planning question before the engineering question. If nobody on your team can say with confidence whether a machine has 2 years left or 10, find that out first.

A 5-minute conversation with whoever owns the capital plan will tell you which case you're in: keep the machine long enough to earn the sensor package out, feed the data forward into whatever replaces it, or walk away because neither applies.

Why “Staying” is Harder to Answer Than it Sounds

Ask most plant managers whether a machine is sticking around, and you'll get a confident answer. Ask the finance team the same question, and you'll often get a different one.

Capital plans shift. Product lines get discontinued. A machine everyone assumed had 5 years left gets replaced in 18 months because the part it makes got redesigned out of the product.

That gap between the assumption and the plan is exactly where instrumentation budgets go to waste. Before committing to a sensor package, get both answers and make sure they match.

Don’t Make the Mistake of Starting with the Sensor

We build real-time systems for manufacturers, and the mistake we see most is starting from the sensor instead of the decision it's supposed to inform.

What the Sensor Budget Doesn't Cover

Most of what gets sold as a legacy-data service is a power monitor or an accelerometer clamped onto a machine, priced cheap because the sensors themselves got cheap. That was never the expensive part.

The real cost is the time your engineers and maintenance team spend gathering a number that never should have been collected, instead of spending those same hours scoping the rebuild the machine needs.

A sensor package runs a few hundred dollars. A week of engineering time doesn't, and that's the cost nobody prices into the proposal until the invoices start arriving.

Ask Both Questions Before the Sensor Gets Ordered

If you're not sure whether a project would survive the test, run it small. Pick the machine where the case seems strongest and instrument that one first. Confirm the data actually changes the decision it was meant to inform before expanding anywhere else.

A single working example does more to justify a broader data program than any spec sheet, and it gives you real numbers instead of assumptions the next time someone asks for a bigger budget.

Use the chart below to evaluate every proposed data project before it reaches a purchase order. It keeps the budget pointed at data that actually changes something instead of dashboards nobody opens.

A number that doesn't change a decision within the year, on a machine that isn't sticking around, is a distraction with a price tag.

This article was written and contributed by Matt Moseman, founder and president of DEVELOP LLC.