Choosing production monitoring software, without taking anybody’s word for it.

Four words that vendors use interchangeably, and should not

Most of the difficult conversations in this category come from four category names being treated as synonyms. A site that already has one of these does not need another of the same thing, and a site that needs one will not be helped by a different one.

Two consequences. SCADA and production monitoring software are not competitors: SCADA controls, monitoring measures, and software reading a controller over OPC UA read-only sits alongside SCADA rather than arguing with it. And MES and ERP overlap at one point and fight there — stock and works orders. Both want to be authoritative, and the honest answer is that one of the two refuses writes, visibly, with the reason on screen. A vendor who says they will simply “sync” is hoping you will not ask until after the order.

One thing predicts year two better than any feature list: which direction the product grew. Software that began as machine monitoring is usually strong on measurement and weak on paperwork; software that began as an ERP module is usually the reverse — good at works orders, vague about where the cycle count came from. Ask.

The case for buying nothing

If you have four machines, one product family and a foreman who knows what happened yesterday, this software will not tell you much you do not already know. A cycle counter and a whiteboard is a real answer and it costs nothing per year, forever. A system starts to earn its place when nobody in the building can answer a question about last Tuesday without asking somebody else, or when a number you give a customer, a board or a compliance scheme has to be defensible rather than approximately right.

And if your ERP vendor already sells a monitoring module that does what you need, it is usually worth more to you than a better standalone system: one supplier, one support route, one integration that already works. We would rather say that than win a deal you regret. The time to look outside the ERP is when its module cannot tell you where a cycle count came from — which, to be fair to those modules, is often.

Ten questions to put in an email before you book anything

Send these to every vendor on your shortlist at once, in writing, before the first call. Written answers are comparable in a way demos are not, and which questions go unanswered tells you nearly as much as the answers.

1. Which of my machines can you connect to with no new hardware, and which need something fitting? Send makes, ages and control types. A real answer is per machine.
2. What happens to the data when our internet goes down? You want local buffering and replay on reconnect.
3. Where does the standard cycle time come from, who can edit it, and is the edit logged? That one field moves OEE by several points. Editable and unlogged means your OEE is an opinion.
4. Do you report performance raw as well as capped at 100%? A machine beating its standard is information about the standard.
5. What does a window with no production in it display? The correct answer is that it says so. A convenient 0% is how a weekly average gets destroyed.
6. Do you report unclassified downtime as a figure in its own right? If a third of stopped time carries no reason, the Pareto is a chart of the third somebody classified.
7. If we already run an ERP, which system is authoritative for stock and works orders — and what does the other do when it is not?
8. What is the price per machine per year, in pounds, including year two? Ask what is charged separately: implementation, hardware, support tiers, extra users.
9. Can we export everything, in what format, and what happens to our data if we leave? Ask for a sample export file, not a promise about one.
10. What do you not do? The most useful question on the list. A vendor who cannot name a limit has either never been asked or is not going to tell you.

What to test in a trial

A demo is the vendor driving. A trial is you driving, and that is the whole point.

• Start with your worst machine. The 1998 press with no network port decides whether this works on your floor. Anybody can connect the new one.
• Have an operator use it unsupervised for a shift. If classifying a stop takes more than a couple of taps it will stop happening in week three, and every number downstream degrades from there.
• Change something yourself — a reason code, a shift pattern, a new machine. If your own people cannot, budget for the tickets.
• Take one number and drill all the way down: factory, location, machine, the timestamped event behind it. If the trail stops short of an event, the number is not evidence.
• Break the link. Unplug the gateway, keep producing, plug it back in, and watch whether the gap fills itself.
• Export a week and rebuild one figure in a spreadsheet. If your arithmetic and theirs disagree, you have found either a definition nobody mentioned or a fault.

What a trial genuinely cannot tell you

Here we have to be careful, because our own trial has this limitation. A trial running on simulated data — ours does, deliberately, so you see something working the same day rather than six weeks after an install — proves the software and tells you nothing about your floor. It cannot tell you whether your machines will connect cleanly, whether the network reaches the far press, or what your real OEE is. Only meters on your own machines do that. A simulated trial standing in for a pilot is a limitation, not a feature, and we would rather you heard it from us. Four more things no trial will surface:

• Whether people are still classifying stops in month four. Adoption decays, fastest in the busiest week. The best proxy is how few taps the worst case takes.
• Whether your standards are right. If your standard cycle times came off a quotation five years ago, your first month of performance figures is measuring the quotation.
• What support is like when something is broken. Ask for the response time in writing, and what happened the last time a gateway died on a Friday afternoon.
• What it is like at your scale. Ten machines and a hundred behave differently, as do one site and five.

The claims worth checking

• “Works with any machine.” Usually true and usually meaningless, because the interesting part is how. There are only a few honest routes onto a machine — reading a controller, counting a spare contact, watching the electrical signature, metering the supply, or an open interface. Ask which applies to which of yours; what each involves is not a secret.
• “Real-time.” Ask for the sample interval in seconds and compare it with your cycle time. A twelve-second stroke sampled every thirty seconds is not being measured, and the error does not average out.
• A percentage improvement. “A 20% OEE uplift” means nothing without the baseline method. If the before figure was a spreadsheet and the after figure was the software, you are comparing two measuring instruments, not two states of a factory.
• “Cost per part.” Check what is inside it. A figure built only from energy is an energy cost. A real one composites energy, material, labour and overhead against an actual works order — the version you could quote from.
• Anything described as AI. Ask what happens when it is wrong, how you would know, and whether the system will admit to being uncertain. A forecast that never expresses doubt is not a forecast.
• Certifications and references. If a certification is claimed, ask for the number and the scope — scope is where these fall apart. For our part, SmartFactory and OneTek hold none in this area and claim none. Ask to speak to a reference at your scale; if that cannot be arranged, it is data.

How an OEE figure gets flattered, and how to spot it in a demo

Every OEE number in a sales meeting has been through at least one decision that moved it upwards, and almost none of it is dishonest — each step is a defensible choice made for a sensible reason. The usual six: reclassifying unplanned downtime as planned, slackening a standard cycle time, counting rework as good, silently excluding quiet periods, absorbing unclassified stops into “other”, and averaging across machines so one bad press disappears. The arithmetic is on our plain-English OEE guide, where slackening one standard cycle from 36 seconds to 40 moves OEE by over eight points while the machine runs at the same speed all week. Three questions separate a measurement from a presentation, and you should ask them of every vendor, including us:

• “Show me a window where nothing ran.” It should say that nothing ran. If it shows 0%, that zero will end up in a board pack.
• “Where did that standard cycle time come from, and can you show me the edit history?” The second half is the one people are not ready for.
• “What share of downtime in this dataset is unclassified?” A system that cannot tell you cannot tell you how much of its own analysis is evidence.

To feel how sensitive the arithmetic is before you sit in front of anybody, put one of your own shifts through the OEE calculator. It reports raw and capped performance side by side and refuses to give a percentage for an empty window — which is the behaviour to expect from any system you are considering, ours included.

End on the trial, not the demo

A demo is a vendor’s best day, on a machine they chose, with data they prepared. It is a reasonable way to spend forty minutes and a poor way to decide anything. Insist on the order: questions in writing, then a trial you drive yourself, then a pilot on your own machines with the decision rule written down before it starts — what you will measure, for how long, and what counts as yes. Write that rule while you are still unattached to the outcome.

The pilot answers what the trial cannot, and it does not have to replace anything. Software reading controllers read-only, with meters clamped onto supplies, runs alongside whatever you have today — so run both for a quarter and compare, rather than switching and hoping. A vendor who needs you to remove something before they can show you a number is asking you to carry a risk that should have been theirs. If you want this as a product rather than as advice, that is the monitoring page; the business case guide covers running a pilot with a decision rule in it; and the trial is ungated and starts the same day. Every question on this page is a fair one to ask us.