Good OEE software does three things: it captures run time, stops, output and rejects from your machines automatically, it calculates OEE the same way every time, and it shows you the losses behind the number so you know what to fix. This buyer's guide lists the features that matter, the data-quality checks that make the score trustworthy, the questions to ask vendors and the red flags to watch for.
If you need a refresher on the maths first, our guide on how to calculate OEE with a worked example covers the formula, Availability, Performance and Quality. This article assumes you know it and focuses on choosing a tool.
Why spreadsheets and manual OEE break down
Most plants start OEE on paper or in a spreadsheet. That is a sensible way to learn the method, but it stops working once you have more than a few machines or more than one shift.
- Data arrives late. Operators fill in sheets at the end of the shift, so the numbers describe yesterday, not what is happening now.
- Short stops disappear. Nobody writes down a two-minute jam. Dozens of them a shift add up to real lost time that never shows in Availability, and often gets hidden as a Performance loss instead.
- Definitions drift. One shift counts a changeover as planned, another as downtime. One supervisor uses the nameplate speed, another uses last month's average. The scores stop being comparable.
- Formulas break quietly. A copied row or a deleted column changes the result and nobody notices for weeks.
- Nobody can drill down. A weekly average of 62% tells you little. You need to know which machine, which shift, which product and which stop reason.
The point of OEE tracking software is to remove the typing, fix the definitions in one place and make the losses visible while there is still time to act on them.
Must-have features in OEE software
Treat these as the minimum.
Automatic data capture from machines
The software should read machine state (running, stopped, idle) and part counts directly from the PLC, a gateway, a historian or a simple sensor. Automatic OEE calculation depends on this. If the tool relies on operators typing in run time, you have bought a nicer spreadsheet.
Correct handling of planned and unplanned stops
Breaks, planned maintenance and "no orders" time should be removed from planned production time. Breakdowns, changeovers and material shortages should count against Availability. Check that you can define shift patterns, holidays and planned events, and that the software applies them consistently.
Ideal cycle times per product
A machine that runs several products has a different ideal rate for each one. The software must let you set an ideal cycle time per product (and per machine, where the same product runs on different machines), and pick the right one based on what is actually running. A single rate per machine will make Performance wrong every time the product changes.
Reason codes for stops
A stop without a reason cannot be fixed. Look for a short, editable list of reason codes, grouped into categories, that an operator can assign quickly. Also check what happens to stops nobody codes: they should be visible as "uncoded", not quietly dropped.
Quality and reject capture
Quality is often the weakest part of an OEE system because rejects are counted later, at inspection. Check whether rejects can come from the machine, a downstream check or an operator entry, and whether scrap and rework can be recorded separately.
Shift, line and plant views
Operators need their machine for the current shift, supervisors the line, managers the plant by day and week. The same data should support all three views.
Drill-down from OEE to the losses behind it
This is the feature that separates a scoreboard from a tool you can manage with. From any OEE figure you should be able to click through to Availability, Performance and Quality, then to the individual stops, their durations and their reasons, ideally as a Pareto of the biggest losses. Our guide to reducing unplanned downtime shows how that Pareto is used week to week.
Alerts
A score you only look at on Monday does not stop a machine sitting idle on Friday night. Look for alerts when a machine stops for longer than a set time, when output falls behind target, or when a reading crosses a limit. Check the channels (email, messaging apps, webhooks) and whether an unacknowledged alert escalates to someone else.
History
You need months and years of data, not weeks, to see whether improvement projects worked. Ask how long raw data and summaries are kept, and whether you can export them.
Data-quality features that make OEE trustworthy
An OEE monitoring system is only as good as the data it accepts. Two plants with the same software can get very different results depending on how carefully data is checked on the way in.
- Rejecting unknown data. Readings from a machine or tag that has not been registered should be rejected and logged, not silently added to a chart. Otherwise a mis-named tag or a test device can distort the numbers.
- Visible data gaps. If a machine stops sending data, the software should show a gap, not assume the machine was running or stopped.
- Audit of changes. Edits to ideal cycle times, shift patterns, reason codes and past stop records should be logged with who changed what and when. OEE is easy to improve on paper by editing the inputs.
- Sense checks. Performance above 100% usually means the ideal cycle time is wrong. Good tools flag it rather than display it.
Integration with machines, ERP and MES
Most plants have a mix of old and new equipment, so ask which industrial protocols the software supports. OPC-UA, MQTT and Modbus cover a large share of PLCs and gateways, and HTTPS is common for edge devices and newer systems.
Also ask:
- Can it read from your existing historian or SCADA, rather than connecting to every PLC again?
- Can it pull work orders, products and planned quantities from your ERP or MES, so the ideal cycle time follows the job?
- Can it send OEE and downtime data back out through an API or export, so it is not locked inside one tool?
- Who does the tag mapping during setup, you or the vendor?
Usability on the shop floor
If operators do not use it, reason codes stay blank and the drill-down is empty. Check the software in the conditions it will be used in:
- Large, readable screens that work on a tablet or a wall display, with gloves on if needed.
- Assigning a stop reason in two or three taps.
- A clear view of "my machine, this shift, against target" without menus.
Trial it on one real line with the people who will use it.
Security and deployment
Connecting production equipment to software outside the plant network needs care. Ask where the software runs (vendor cloud, your own cloud account, on-premises or a hybrid), whether data is encrypted in transit and at rest, and how access is controlled. Role-based access and multi-factor sign-in should be standard. Check that the connection from the plant is outbound only and read-only, so the software cannot change machine settings.
Pricing models
OEE software is usually sold as a subscription. The common models are:
- Per machine: you pay for each connected machine or asset. Easy to start small and grow. Check what counts as one machine, for example a line with several stations.
- Per site: a flat fee per plant. Predictable if you plan to connect everything, expensive if you only need a few machines.
- Per user: you pay for each named login. This can discourage sharing data with operators, which works against the whole point of OEE.
On top of the subscription, ask about setup and integration fees, any hardware, training, support tiers and the cost of adding machines later.
Questions to ask OEE software vendors
Take this checklist into every demo:
- How do you get run state and part counts from our machines, and do we need new sensors?
- How are planned stops, breaks and changeovers treated in the calculation?
- Can we set ideal cycle times per product and per machine?
- What happens to data from a machine or tag you do not recognise?
- Can we trace any OEE figure back to the raw readings behind it?
- Who can change ideal cycle times and past stop records, and is every change logged?
- How do operators assign stop reasons, and how are uncoded stops shown?
- Which alert channels do you support, and do alerts escalate if nobody responds?
- How long is data kept, and can we export all of it?
- Which ERP, MES and historian systems do you connect to today?
- Where is our data stored, and who can access it?
- What is the full cost for our number of machines, users and sites, including setup?
Spreadsheet vs basic dashboard vs full OEE platform
| Capability | Spreadsheet | Basic dashboard | Full OEE / monitoring platform |
|---|---|---|---|
| Data capture | Manual entry | Often manual or partly automatic | Automatic from machines |
| Short stops | Usually missed | Sometimes captured | Captured |
| Planned vs unplanned stops | Depends on who fills it in | Basic rules | Configured shift patterns and planned events |
| Ideal cycle time per product | Possible, error-prone | Often one rate per machine | Per product and machine |
| Stop reason codes | Free text | Limited | Structured, with Pareto |
| Drill-down to losses | No | Limited | From score to individual stops |
| Alerts and escalation | No | Sometimes | Yes, with escalation |
| Data validation and audit | No | Rarely | Unknown data rejected, changes logged |
| Best for | Learning OEE on one machine | Displaying numbers you already collect | Running OEE across lines and shifts |
Red flags when choosing OEE software
- OEE figures above 100% in the demo, or no explanation of how Performance is calculated.
- Manual entry presented as automatic. Ask exactly which numbers come from the machine and which are typed in.
- No way to see the raw data behind a score, or no export.
- Fixed definitions you cannot configure, such as treating all stops the same way.
- Per-user pricing that limits operator access, so the people who can fix losses cannot see them.
- Vague answers on security, or a connection that needs inbound access to your control network.
- Features described as available that are really on a roadmap. Ask what is live today and get it in writing.
Where MIE fits
OEE is only as good as the machine data underneath it, and collecting that data reliably is the first step. MIE, the ThinklytixAI Manufacturing Intelligence Engine, is machine monitoring software built for that step. Live today, it takes the readings your machines already have over HTTPS, MQTT, OPC-UA or Modbus, with no new sensors, and accepts data only from machines and tags you have registered; anything else is rejected and written to a log with the reason. It gives you a plant overview, trends and machine pages, sends alerts on Slack, WhatsApp or webhook with timed escalation until someone acknowledges, and lets you ask plain-English questions of your plant data.
MIE is not sold as an OEE calculator. It collects the readings OEE is built from. For reporting, custom dashboards you describe in plain English are next on the MIE roadmap, so views such as output against target or downtime by machine can be requested rather than built by hand.
Summary
Choose OEE software that captures data automatically, handles planned stops and ideal cycle times correctly, records stop reasons, and lets you drill from the score to the losses behind it. Check that it rejects unknown data and logs changes, fits your protocols and systems, and is simple enough for operators to use. Test it on one real line before rolling it out.