What should you look for when choosing OEE software?

Why does the question list matter more than the feature list?

Because feature lists converge. Every vendor in this market shows OEE, availability, performance and quality, a timeline, a downtime Pareto and an alert. Read four websites and you will not be able to tell them apart, which is the intended effect.

What separates them is answerable in a demo and almost never asked: what the software can read from the machines you own, where your data physically sits, what an operator has to do that they do not do today, and what the second year costs. Each criterion below is written so you can put it to a vendor as a question and judge the answer. The wording of a weak answer is included because it is usually a fluent, confident sentence that does not contain a fact.

What can it actually read from the machines you have?

This is the criterion that eliminates most of a shortlist, and it is worth settling in the first call. A product that reads CNC controls directly is solving a different problem from one that reads a production monitoring device, which is different again from one that needs sensors installed on each machine. The right answer depends entirely on what is bolted to your floor.

Take your actual equipment list into the conversation. Not "we have twelve machines" but the makes, the models, the control generations, and which of them already have something counting parts. The answer for machine three is frequently different from the answer for machine one.

Ask them: here is my machine list. For each line on it, tell me exactly what you read, over what protocol or from what device, and what hardware you would have to install to do it.

A weak answer sounds like: "we integrate with everything" or "our platform is hardware agnostic". Universal connectivity is a claim that costs nothing to make and shows up as a change order later. A strong answer is boring and specific, and includes at least one machine they would have to think about.

Where does the software run, and does plant data leave your network?

Three arrangements are common: the software runs in the vendor's cloud and a device in your plant sends data out to it; the software runs on a server you own inside the plant network; or a vendor hosts a server for you. They are not variations on a theme. They differ in who can read your production history, what happens when the plant's internet link drops, and which of your policies the purchase has to clear.

Get your own answer before you shortlist. Whoever writes your data policy will decide this faster than any vendor evaluation will, and finding out in week six is expensive.

Ask them: name every outbound connection the system makes, what is in each one, and what stops working if the plant loses its internet connection for a day.

A weak answer sounds like: "everything is encrypted" or "we are SOC 2". Both can be true and neither answers the question, which is about where the data sits and who can reach it, not how it is protected in transit. Watch for a hosted product described as on-premises because an appliance sits in your rack.

What happens to your data if you stop paying?

The question nobody asks in a demo, and the one that quietly decides how much leverage you have at every renewal. Three years of production history is the most valuable thing the system will ever hold, and on a subscription you may be renting access to your own records.

There are honest answers at both ends. Some vendors give you a full export on exit. Some give you a CSV of summaries, which is not the same thing. And a one-time license with an optional annual fee behaves differently again, because the software keeps running whether or not you renew.

Ask them: if we cancel, what exactly do we get, in what format, and how long do we have to collect it? Can I query the database directly today, or only through your application?

A weak answer sounds like: "you own your data". Everybody says it and it describes a legal position, not a mechanism. The follow-up that separates them is whether the export includes event-level records or only the aggregates their reports display.

Does it work with the equipment you already own, including the old generation?

Plants do not run one generation of anything. There is the line installed last year, the two lines from a decade ago, and the machine everybody agrees should have been replaced. A product that reads the new hardware and not the old one gives you two systems and an argument about which one is right.

Older equipment is also where support statements get vague. A vendor's compatibility page usually lists what it is happy to sell you today, not what it will still read.

Ask them: here are the model and firmware versions of my oldest units. Do you read them today, does the history from them appear in the same reports as the new hardware, and what happens to those reports if I never upgrade?

A weak answer sounds like: "we recommend upgrading those". That may be sound advice and it is also a budget you did not have, converted into your problem. If the answer is a genuine no, the useful follow-up is what the old lines look like in the meantime.

What does the operator have to do differently?

Every OEE system that produces reason codes is asking somebody on the floor for something. The question is what, how often, and how long it takes. Two taps at a stop is a system that gets used. A login, four dropdowns and a free-text box at every stop is a system that gets a default reason picked to make the screen go away, and then you are making decisions from a field somebody filled in to get back to work.

Watch it happen rather than hearing it described. Ask to see the operator screen used by an operator, at a machine, during a real stop, and count the seconds.

Ask them: walk me through everything an operator touches during one downtime event and one job change. How many taps, and what happens if they are wearing gloves?

A weak answer sounds like: "it is very intuitive" or a demo that only ever shows the supervisor dashboard. The operator screen is the part of the product that decides whether the dashboard means anything, and it is the screen least likely to be shown to you.

What happens to downtime nobody labels?

Every plant has stops that never get a reason. The measure of a downtime system is not how good the Pareto chart looks, it is what share of stopped time is sitting in an unlabelled bucket, and what the system does about it.

Good behaviour here looks like prompting for a missing reason at the machine, letting a supervisor code a stop after the fact, requiring a written explanation on long stops, and being able to split one recorded stop into the two things that actually happened. Whether corrections are audited matters too, because an editable history is only trustworthy if you can see who changed what.

Ask them: show me the report that tells me how much of last month's downtime has no reason on it. Then show me how a supervisor fixes a stop that was coded wrong, and where that edit is recorded.

A weak answer sounds like: "the operators will code it". They will not code all of it, at any plant, ever. A vendor who has been on a floor knows that and has built for it.

Can you see how the OEE number was calculated?

OEE is a simple formula over inputs that are all judgement calls. What counts as planned downtime, whether a changeover is a stop or scheduled, what the ideal cycle time is, when a shift starts. Two systems on the same line will disagree, and the argument that follows is not about arithmetic.

You want a system where anybody can drill from a headline number down to the events behind it without asking the vendor. The first time a plant manager disputes a number, that is the feature that settles it.

Ask them: click this OEE figure and take me down to the individual events it is built from. Then show me where the ideal cycle time and the planned downtime rules are configured, and who is allowed to change them.

A weak answer sounds like: "it uses the standard OEE calculation". There is a standard formula and no standard set of inputs. If the drill-down stops at a daily summary, you will be exporting to a spreadsheet within a month.

Who installs it, who maintains it, and what does IT have to allow?

This is the criterion that decides your project timeline, and it is usually discovered after the purchase order. An on-premises product needs a server, an operating system somebody patches, firewall rules, a TLS certificate, a backup target and a support access path. A cloud product needs an outbound route and a conversation about what goes through it. Neither is free of IT; they need different things from different people.

Bring your IT lead to the second call, not the sixth. The requirements document is the cheapest way to find out whether the project is a purchase or a programme.

Ask them: send me the server requirements, the network access list and the update procedure before we go further. Who applies updates, on whose schedule, and what does a restricted site with no internet access do instead?

A weak answer sounds like: "installation is included". Installation being included says nothing about what your IT department has to sign off on. Ask for the document. A vendor who cannot produce one has not deployed into a plant with a real security review.

What does year two cost, and what is the unit?

Published prices in this market are not comparable in their published form. Per machine per month, per site, per user, per module, and one-time license with an annual fee all exist, often with a device minimum underneath. A three-machine plant and a forty-machine plant land in completely different places on the same two price lists.

Normalise everything to one number before you compare: five years, your real device count, with support, integration work and renewals in it. Then ask what is not in it.

Ask them: price my exact device count for five years. What is the minimum I can buy, what does year two cost, what is excluded, and what does the number do when I add ten machines or a second site?

A weak answer sounds like: a price with no unit attached, or one that arrives only after a discovery call. Integrations, on-site visits and training are the three lines most often outside a quoted price.

Can you change a report without the vendor?

Every plant wants one number nobody else calculates. If each of those is a support ticket and a quote, you will stop asking, and the system settles into producing the reports it shipped with.

The realistic middle is a product that covers the common reporting itself, lets your own people build views without writing code, and can hand the data to the BI tool your analysts already use when the request goes beyond that.

Ask them: build me a chart I have just described, now, in this call. Then tell me what my analysts can reach directly, and what a custom report costs when it is genuinely custom.

A weak answer sounds like: "that is on the roadmap". A roadmap answer to a reporting question is a change order with a friendlier name.

Where does it stop?

The most useful five minutes of a vendor call is asking what the product does not do. OEE software borders on maintenance systems, quality systems, scheduling and improvement tracking, and the boundary is different for every vendor. A product that claims all of it usually means one of them is a form with a due date on it.

You do not need one tool for everything. You need to know which of these you are buying and which you are integrating, before the requirement turns up mid-project.

Ask them: what do your customers still run alongside this, and what do you integrate with rather than replace? Name a request you turn down.

A weak answer sounds like: a claim to cover maintenance, quality, scheduling and continuous improvement in one platform. Ask to see the maintenance module and judge it against a real CMMS.

Where do we fit against these criteria?

Written the same way we would want a competitor to write it, which means starting with the rows we lose.

Machine connectivity is not our strength. We read Vorne XL boards, on V1 and V2 firmware, plus SQL Server, PostgreSQL, REST APIs, Excel imports, MQTT and the ERP and scheduling feeds around them. If your floor is thirty machining centres from eight builders and nothing is counting parts yet, a product built around CNC and PLC control protocols is solving your problem and we are not. Our comparison with MachineMetrics goes through that row honestly.

We are not the fastest thing to switch on. A cloud product with a published per-machine price can be running in days with nobody from IT in the room. An in-plant install of ours cannot: it needs a server, network access and a security conversation. Letting us host it takes the server and most of that conversation off your side, and it is still a fitted deployment rather than a sign-up, because we start from your device list and your integrations. If being live this week with no involvement from your own people is the top criterion, that is a real reason to buy something else, and the Evocon comparison says so.

We are not a maintenance or quality system. There is no preventive maintenance scheduling, no MTBF dashboard, no SPC or inspection-plan module. What we do is get downtime and reject data out to the systems that own that work. If you want one tool that covers PMs and OEE, we are not it.

Where we do answer well:

• Where the data sits, and that it is your choice. The same product stack runs either way: on a server you own inside the plant network, or hosted for you. Choose the in-plant install and the production database stays in the building, with in-app alerts and email through an internal relay never leaving it at all. The full boundary, channel by channel, is on the alerting page, and the server and network requirements are published on the technical specifications page rather than sent on request, which is the document to hand your IT reviewer.
• Old hardware. V1 and V2 Vorne boards report side by side, and Data Converter rewrites V1 history into the V2 schema so a report can cross the changeover. Details are on the V1 conversion page.
• Exit terms, and the difference between our two models. On the one-time license, you own the software and the annual fee is optional for updates and support: everything except AI analysis keeps running whether or not you renew. On the subscription that is not true, and it is worth saying so - access ends at the end of the paid period, though no data is deleted and resubscribing picks up where you left off. On an in-plant install the database is on your own server, in SQL Server or PostgreSQL, so your own analysts can reach it directly; either way Pulse exports four datasets - Metrics, Rejects, Job Punches and Instants - as CSV, Excel or PDF. Both models are priced openly on the pricing pages.
• Unlabelled downtime. Work Tracker prompts for missing reasons at the machine and carries an extended-downtime explanation workflow, and a stop that was coded wrong can be split and recoded afterwards.

If you are working through this with Vorne XL boards already installed, the criteria shift enough to be worth their own page: what to look for in software for Vorne XL. If the evaluation is really about capturing stops and reasons, most of the decision lives in choosing a downtime tracking system. And if you already have one product in mind and want the field around it, the alternatives pages list the real options for MachineMetrics, Evocon and Shoplogix, and the comparison hub takes us on product by product, with sources and access dates.