OEE and downtime tracking
OEE software
OEE software measures how much of your production time actually makes good parts at full speed. Before comparing products, two things are worth knowing that no vendor page says: the number is easy to improve without changing anything on the floor, and improving it on the wrong machine makes the plant worse.
What is OEE software?
OEE software measures how much of your available production time actually produces good parts at full speed. It multiplies three figures: availability, performance and quality. Products in this space include Evocon, MachineMetrics and Sepasoft's OEE module, and most capture downtime either from an operator screen or directly from the machine.
Overall equipment effectiveness is one number carrying three different stories, which is both its strength and the reason it is so often misread. A plant at 60% might have a breakdown problem, a speed problem or a scrap problem, and the headline figure does not say which.
Before comparing products, there are two things worth knowing that no vendor page will tell you. The first is that OEE is easy to improve without changing anything on the floor. The second is that improving it on the wrong machine actively damages the plant.
This page is written for manufacturers between roughly fifty and five hundred people, where downtime is currently recorded on paper at the machine and typed in later, if at all.
Where do the hours actually go?
From calendar time, you lose unscheduled hours, then breakdowns and changeovers, then the gap between actual and ideal speed, then scrap. What remains is fully productive time. OEE is that number as a percentage of scheduled time, and each step hides a different problem.
| Component | What it loses | What to know |
|---|---|---|
| Availability | Breakdowns, changeovers, waiting for material or an operator | The biggest loss in most job shops, and changeover is usually the largest part of it. |
| Performance | Running slower than the ideal cycle, and short stops nobody logs | The most under measured. Micro stops of under a minute rarely get recorded by a human. |
| Quality | Scrap, rework, and the parts made during a bad start up | Often the smallest of the three, and the one most likely to be already tracked elsewhere. |
Two further points about the components are worth stating, because they decide what the number is good for. Availability and performance interact in a way that hides losses: a machine that runs slowly but never stops can score the same as one that runs at full speed and breaks down regularly, and the two plants need entirely different responses. And quality losses are frequently counted twice, once as scrap and once again as the time spent producing it, which is correct but surprises people reviewing the figure for the first time.
The multiplication is what makes the headline number deceptive. Ninety percent on each of the three gives 73% overall, which sounds like a plant in trouble when each individual figure looks respectable. Conversely a plant reporting 85% has either genuinely excellent operations or a generous definition of planned downtime, and from the outside those look identical.
This is why the underlying hours matter more than the percentage. A plant that knows it lost 41 hours to changeover and 12 to breakdowns last month can decide what to do. A plant that knows it scored 64% cannot.
How is OEE gamed?
Five ways, all of them legal and none requiring dishonesty. Redefine planned downtime, soften the ideal cycle time, exclude unmanned shifts, measure the machine that runs well, or change reason codes mid year. Each moves the number without moving a single part.
| Method | How it works | When it is and is not reasonable |
|---|---|---|
| Redefine planned downtime | Move changeovers into planned time and availability jumps | Legitimate for a scheduled maintenance window. Not legitimate for every setup, which is the loss you most want to see. |
| Soften the ideal cycle time | Set the theoretical rate to what the machine usually does rather than what it can do | Performance approaches 100% and the gap you were trying to find disappears. |
| Exclude unmanned shifts | Count only staffed hours | Reasonable if you never intend to run them. Misleading if capacity is the question you are asking. |
| Measure the easy machine | Report plant OEE from the line that runs well | The average looks healthy while the constraint stays invisible. |
| Change reason codes mid year | Recategorise what counts as what | The number moves, the plant does not, and the trend line becomes meaningless. |
A sixth method deserves its own mention because it is the most common of all: simply not measuring the hours when things went badly. A machine down for three days waiting on a part gets excluded as an exceptional event, the month reads well, and the single largest loss of the quarter never appears in any figure. Exceptional events are where the hours are.
None of this is usually deliberate fraud. It happens because somebody has to define what counts, those definitions are genuinely debatable, and the person defining them is often the person the number reflects on. That is a structural problem rather than a character problem, and the fix is structural too.
Three things protect you. Write the definitions down before the first measurement and date them. Report the underlying hours alongside the percentage, so a change in counting is visible as a change in counting. And when the definitions do change, which they legitimately will, restate the previous period on the new basis so the trend line survives.
The fourth row is worth singling out. Plant level OEE reported as an average across machines is close to useless, because the constraint and the feeder machine contribute equally to it. If you report one number to a board, report the constraint's number.
Does improving OEE always help?
No. Improving OEE on a machine that is not your constraint usually makes the plant worse. It produces more parts that then wait in front of the bottleneck, which converts cash into inventory and often lengthens lead times. Only the constraint's utilisation translates into what you ship.
This is the most expensive misunderstanding in the category, and no software vendor will raise it, because products are sold and licensed per machine or per line.
Consider a shop with a bottleneck press. Running the feeder machine from 55% to 75% produces a third more components. The press cannot process them any faster, so they queue. Work in progress rises, floor space fills, cash is tied up in half finished parts, and the quoted lead time gets longer rather than shorter. Every local measurement improved and the business got worse.
So the first question is not which machines to instrument. It is which machine actually limits what you ship. Often the plant already knows: it is where work piles up in front and starves behind, the machine people schedule around, the one everybody mentions when a date slips.
Instrument that one first. If its utilisation genuinely rises, the plant ships more. If you cannot identify the constraint, measuring for a month will show you where the queue sits, which is a perfectly good reason to start measuring, as long as you do not start by measuring everything.
Should downtime be operator entered or captured from the machine?
Both, eventually. Machine signals catch every stop including the short ones people never log. Operator input supplies the reason, which no sensor can infer. Starting with operator entry is cheaper and works on any equipment, and plants that begin there usually add machine capture to the constraint later.
| Approach | What it is | Strength | Weakness |
|---|---|---|---|
| Operator entered | A screen at the machine where someone selects a reason | Cheap, fast to deploy, works on any equipment | Short stops go unrecorded, and reasons drift toward whichever button is nearest |
| Machine signal | Reading the PLC, CNC or a sensor on the machine | Catches every stop including micro stops, no human effort | Tells you that it stopped, never why |
| Both | Automatic detection, operator asked to attribute a reason | The combination most plants end up at | Needs the prompt to be quick, or operators stop answering honestly |
The weakness of operator entry is worth understanding rather than dismissing. Short stops, the three minute clear of a jam, are the losses people do not record because stopping to log them costs nearly as long as the stop itself. Those micro stops accumulate into a large number that only appears when a machine signal is counting.
The weakness of machine capture is the reverse. A sensor records that the machine stopped for eleven minutes at 14:20. It cannot tell you that the operator was waiting for a crane, and without the reason the data supports no decision at all.
Practical sequencing that works: put a simple reason screen on the constraint, agree a short code list, run it for a month. You will learn whether reasons get recorded honestly before spending anything on sensors. If the screen is ignored, no amount of automatic capture fixes the underlying problem, which is that nobody has explained what the data is for.
Why do OEE and downtime tracking projects fail?
Five failure modes: measuring everything at once, reason codes nobody governs, treating the number as the goal, improving a machine that is not the constraint, and never feeding the data back to the floor.
| Failure mode | What it looks like | What prevents it |
|---|---|---|
| Measuring everything at once | Sensors on forty machines, a dashboard nobody opens, no decision changed. | Instrument the constraint first. One machine, one month, one decision. |
| Reason codes nobody governs | Forty codes, half unused, three meaning roughly the same thing. | Start with eight to twelve codes, review them monthly, and let the floor rename them. |
| Treating the number as the goal | OEE rises because counting changed, not because the plant did. | Track the underlying hours as well as the percentage, so gaming is visible. |
| Improving a non bottleneck | The feeder machine runs beautifully and inventory piles up in front of the constraint. | Ask what the plant ships, not what the machine makes. |
| No feedback to the floor | Data flows up to a report and never back to the people who could act on it. | Put the number where the work happens, updated often enough to matter. |
The second row is the real project, and it is not a software problem. Reason codes decide whether the data means anything, they need to be few enough that an operator can choose quickly and specific enough that the answer is actionable, and they must stay stable long enough to compare months.
Start with eight to twelve. Let the floor rename them into words they actually use, because a code called "material unavailable" gets used and one called "input logistics exception" does not. Review them monthly for the first quarter, then leave them alone.
The last row decides whether anyone keeps entering data. If the information goes up to a monthly report and never comes back, operators correctly conclude that logging downtime is paperwork, and the quality of entry degrades within weeks. A screen on the floor showing today against yesterday does more for data quality than any amount of training.
Is 85% a realistic OEE target?
Not for most job shops. The 85% figure comes from high volume repetitive manufacturing where changeovers are rare. A make to order shop running short batches with frequent setups can be operating well at figures far below that, and chasing 85% there usually means running longer batches than customers want.
The number is repeated across this category as though it were a universal standard. It is a benchmark from a specific kind of plant: long runs, few changeovers, stable products. Transplanted onto a shop that changes over four times a shift, it measures how little you change over rather than how well you run.
Worse, it is achievable in exactly the wrong way. Batch sizes can be increased until setups become rare, and OEE will rise. Lead times lengthen, inventory grows, and the business becomes less able to serve the customers who buy small quantities at good margins. The metric improved and the strategy quietly changed.
A more useful approach is to compare yourself to yourself. Measure, establish where you actually are, then set a target that reflects your own mix. The direction of travel matters and the absolute number against someone else's plant does not.
If a board wants a single figure, give them the constraint's availability and the hours lost to changeover. Both are concrete, neither is easy to game quietly, and both point at an action.
Do you need full OEE, or just downtime tracking?
Most plants need downtime tracking first. Downtime tracking software answers when the machine stopped and why, which is the question almost everyone actually has. Full OEE adds performance and quality, which needs an agreed ideal cycle time and a trustworthy good parts count that many plants do not yet have.
| Scope | What it tells you | What it needs |
|---|---|---|
| Downtime tracking only | When, how long, and why the machine stopped | Cheaper, faster, and answers the question most plants actually have. Needs no cycle time data. |
| Full OEE | Availability, performance and quality combined | Needs an agreed ideal cycle time and a reliable good parts count. More work, more insight. |
| Machine monitoring | Continuous signal from the machine itself | Catches short stops nobody logs. Tells you that it stopped, never why. |
The distinction matters commercially because the two are priced and scoped differently, and because the performance component is the one that quietly causes arguments. Performance compares actual output to an ideal cycle time, and somebody has to decide what ideal means. Set it from the machine's specification and performance looks terrible. Set it from what the machine usually achieves and the gap you were looking for disappears.
Downtime tracking avoids that argument entirely. A stop either happened or it did not, and its duration is not a matter of opinion. For a plant that has never measured anything, starting where the data is unarguable is worth more than starting where it is complete.
Add performance later, once the changeover and breakdown picture is clear and somebody has the appetite to agree cycle times properly. By then you will also know whether anyone is using the data, which is a better reason to extend than a feature list is.
What should you test in a demonstration?
Five things, none of which is a feature list. Your oldest machine, a ninety second micro stop, a changeover, the time it takes an operator to log a reason, and who can edit history afterwards. Every product demonstrates beautifully on a modern machine with clean data.
| Test | Why it separates products |
|---|---|
| Your oldest machine | Not the new CNC in the brochure. The 1998 press that makes money and exposes nothing. |
| A micro stop | Stop the machine for ninety seconds and see whether it appears at all, and what it is attributed to. |
| A changeover | Watch how it is classified by default. Planned or unplanned changes the headline number more than anything else. |
| The reason prompt | Time how long an operator takes to log a stop. Over about ten seconds and it will be skipped under pressure. |
| Editing history | Ask who can retrospectively change a reason code, and whether the change is visible. This decides whether the data is evidence. |
The first test is the one that matters most in a plant of this size, because the machine earning the money is frequently the oldest one on the floor. A product that assumes a modern controller with an open protocol will quote happily and then discover your press has a relay panel and no network port.
The fourth test decides whether the system survives contact with a bad day. If logging a stop takes twenty seconds, it will be done accurately on a quiet Tuesday and skipped entirely during the week everything goes wrong, which is precisely the week you most wanted the data.
The fifth is about trust rather than function. If anyone can retrospectively recategorise a breakdown as planned maintenance without a trace, the number is an opinion. Ask to see the audit trail, and ask who holds the permission.
What about machines that expose no data?
Most older equipment can still be monitored, usually by sensing something external rather than reading the controller. A current clamp on the motor, a proximity sensor on a moving part, or a signal taken from the stack light will tell you running or stopped without touching the machine's own electronics.
This is the practical reality in plants between fifty and five hundred people, where the machine generating the most margin is often older than the people operating it. Vendor pages tend to assume a fleet of networked CNCs. Your floor probably is not that.
Stack light sensing is the usual starting point. The machine already signals its state with a tower lamp; reading those lamps gives you running, stopped and fault without any integration at all. Crude, reversible, and sufficient for availability.
Current sensing on the main motor distinguishes running from idle, and often distinguishes cutting from running as well. A clamp around a cable requires no modification to the machine and no vendor involvement.
Proximity or cycle sensors count parts or strokes where a part count is what you need. Simple, cheap, and accurate enough for most purposes.
What none of these give you is the reason, which brings it back to the operator screen. The combination that works on old equipment is a sensor saying when and a person saying why, and that is achievable without replacing anything.
One caution worth stating plainly: anything attached to production equipment should be installed by someone who understands the machine and the relevant electrical regulations. Reading a stack light is low risk. Interfering with a control circuit is not, and the saving is never worth the consequence.
What does OEE software cost?
Licensing is usually quoted per machine or per line and is rarely the largest number. Sensors and installation, the time to agree reason codes and cycle times, and integration into the systems that will use the data typically exceed it, and the last of those is the line most often missing from a quote.
Published pricing in this category is inconsistent and mostly vendor supplied, so rather than add another figure, here is where the money actually goes.
Hardware and installation. Sensors are inexpensive. Getting them fitted safely by someone competent, during a window that does not stop production, is the real cost and it scales with the number of machines rather than the software licence.
Definition work. Agreeing reason codes, deciding what counts as planned, and establishing ideal cycle times if you are doing full OEE. Days rather than weeks, but it needs the people who understand the plant and they are the ones you can least spare.
Integration. Downtime data sitting in its own dashboard is worth a fraction of the same data reaching the schedule and the job costing. If a proposal does not name your ERP, that work has not been scoped and it will arrive later as a surprise.
The habit. Somebody has to look at the numbers weekly and act on them. This costs nothing in software and is the single largest determinant of whether the project pays back. A plant that buys the best product and never changes a decision has bought a dashboard.
The question worth asking every vendor is what the total looks like for one machine in the first year, including fitting, definition and getting the data into the system you already run. Compare that number, not the per machine licence.
What do you do once you have the data?
Read the largest reason code and act on that one thing. In most job shops it is changeover, and the answer is a setup reduction project rather than more measurement. The data is only worth collecting if it changes a decision within the first month.
| If the biggest loss is | The answer is usually | What to do |
|---|---|---|
| Changeover is the biggest loss | Setup reduction, not more monitoring | Film one changeover, list every step, separate what could be done while the machine still runs. Usually the largest single win available. |
| Breakdowns dominate | Preventive maintenance on the specific failures | The reason codes will name the two or three failures that account for most of the hours. Fix those rather than writing a general maintenance policy. |
| Waiting for material | A scheduling or purchasing problem, not a machine one | The constraint is starving. Monitoring it harder tells you the same thing every week. |
| Waiting for an operator | A labour or certification problem | Often one person is the only one qualified. Cross training is cheaper than any software. |
| Many short stops | This is where automatic capture earns its cost | Humans cannot log a ninety second stop reliably. If this is your pattern, sensors pay for themselves. |
The first row is the common case and it is worth being specific about, because the response is often misdirected. A plant discovers changeover is costing forty hours a month and buys more monitoring to understand it better. The monitoring reports the same forty hours next month in higher resolution.
What actually moves that number is watching one changeover end to end, writing down every step, and separating the work that genuinely requires the machine to be stopped from the work that could have been done while it was still running. Preparing tooling, staging material, pre setting fixtures. Shops frequently find half the setup time is work that did not need the machine idle at all.
The third and fourth rows are worth noticing because they are not machine problems. If the constraint is regularly starved of material or waiting for the one certified operator, no amount of equipment monitoring addresses the cause. Those are scheduling, purchasing and training questions, and the value of the downtime data is simply that it proved where the hours went and ended the argument.
The last row is the honest case for spending money on automatic capture. A pattern of many short stops is invisible to manual logging and genuinely expensive in aggregate. If a month of clipboard data shows long gaps that nobody can account for, that is the signal that sensors will tell you something a person cannot.
Worth saying plainly: OEE software does not improve anything by itself. It shortens the distance between a loss happening and somebody knowing about it, and that is genuinely valuable, but the improvement comes from the decision taken afterwards. A plant with excellent data and no weekly review habit has bought visibility it does not use.
One habit matters more than any of this. Someone has to look at the numbers weekly, pick one thing, and change it. Plants that do this with a clipboard outperform plants that buy an excellent system and review it quarterly, which is an uncomfortable thing for anyone selling software to admit.
How would Voliom approach this?
Identify the constraint, instrument that one machine, agree a short reason code list with the people who will use it, and put the result back on the floor where the work happens. Then widen only once a decision has actually changed because of the data.
Find the constraint before buying sensors. Usually the plant already knows which machine limits what ships. Where it does not, a fortnight of observation settles it more cheaply than instrumenting everything and reading dashboards later.
Reason codes with the operators, not for them. Eight to twelve, in the words the floor already uses. We run that session with the people who will press the buttons, because codes written in an office get ignored at the machine.
Read the machine where it is practical. Many machines expose a signal already, and many older ones can have a simple sensor added. Where neither is realistic, operator entry on the constraint is a perfectly respectable place to start and far better than nothing.
Numbers go back to the floor. A screen showing today against yesterday, updated continuously. This is the single thing that keeps data entry honest, and it costs almost nothing compared with the capture itself.
Then connect it to the rest. Downtime data is most valuable when it reaches the schedule and the costing, which is integration work rather than a new system. A loss recorded and never used is paperwork with better graphics.
What can you do this month without buying anything?
Three things. Name the constraint. Put a clipboard on it with eight reason codes and a clock. Total the hours at the end of the month and see which loss is largest. That exercise costs nothing and tells you whether you need software or a changeover project.
Name the constraint. Ask three people where work piles up. If they all say the same machine, you have your answer. If they disagree, that disagreement is itself worth resolving before spending money.
Clipboard and eight codes. Breakdown, changeover, no material, no operator, quality issue, waiting on inspection, planned maintenance, other. Written by hand, at the machine, with a start and end time. Crude and genuinely sufficient to find the biggest loss.
Total it at month end. One of those codes will be much larger than the others. In most job shops it is changeover, and the implication is a setup reduction project rather than a monitoring purchase, which is a cheaper and faster answer than anything on this page.
If after a month the clipboard shows losses scattered across many short stops nobody could capture by hand, that is the clearest possible signal that automatic capture would earn its cost. You will have established the need rather than assumed it, and you will know exactly which machine to start on.
FAQ
Common questions
What is OEE software?
OEE software measures how much available production time produces good parts at full speed, by multiplying availability, performance and quality. Products include Evocon, MachineMetrics and Sepasoft's OEE module. Most capture downtime either from a screen the operator uses or directly from the machine's own signals.
How is OEE calculated?
Availability multiplied by performance multiplied by quality. Availability is running time against scheduled time. Performance is actual output against the ideal rate for that running time. Quality is good parts against total parts. Ninety percent on each gives 73% overall, which is why the headline figure often looks worse than its components.
Is 85% OEE a good target?
Not for most job shops. The 85% benchmark comes from high volume repetitive manufacturing with rare changeovers. A make to order shop with frequent setups can run well far below it, and chasing 85% there usually means increasing batch sizes, which lengthens lead times and ties up cash.
Should we track downtime with operators or sensors?
Operator entry is cheaper, works on any equipment, and supplies the reason a sensor cannot infer. Machine signals catch short stops people never log. Most plants start with a reason screen on the constraint and add machine capture later, once they know reasons are being recorded honestly.
Does improving OEE always improve the business?
No. Improving OEE on a machine that is not your constraint produces parts that queue in front of the bottleneck, which raises work in progress and can lengthen lead times. Only the constraint's utilisation converts into what you ship, so instrument that machine before any other.
How many downtime reason codes should we have?
Eight to twelve to begin with, written in the words the floor already uses. Too many and operators pick whichever button is nearest; too few and the data supports no action. Review them monthly for the first quarter, then keep them stable so months remain comparable.
Can OEE be manipulated?
Easily, and usually without any dishonesty. Moving changeovers into planned downtime, softening the ideal cycle time, excluding unmanned shifts or changing reason codes mid year all move the number without changing the plant. Report the underlying hours alongside the percentage so a change in counting is visible.
Do we need machine monitoring software as well?
Only once you know what decision it would change. Machine monitoring software captures stops automatically, including micro stops a person would never log, which matters most on a constraint running short cycles. On a machine with few long stops, a reason screen gives most of the value for a fraction of the cost.
Can you connect downtime data to our ERP?
Yes, and that is usually where the value is. Downtime figures are most useful when they reach the schedule, so planning reflects real capacity, and the costing, so job margins include the hours actually lost. That is integration work around your existing system rather than another platform to maintain.
Keep exploring
Related services
- Production scheduling softwareWhere downtime data becomes capacity
- Manufacturing softwareShop floor, scheduling and ERP gaps
- Systems integrationGetting the data into your ERP
- Manufacturing software guideWho writes the rankings, and why
Let's talk
Tell us what you're building.
Get a free 30-minute strategy call. You'll leave with a clear plan, a realistic estimate and our honest opinion, whether or not you work with us.
- Email usmail@voliom.com