OEE Calculator

What this tool does

CM8-04 calculates overall equipment effectiveness across as many machines as you like. Record one row per production run — a machine, on a shift, making one product. It works out availability, performance, quality and OEE for every run, aggregates them correctly by machine and by period, converts the three loss types into comparable minutes, and prints a report. Everything runs inside this single file: no account, no upload, no network request.

The three factors

OEE asks one question — of the time you intended to produce, how much produced good parts at full speed? — and splits the answer into three losses, so it tells you what to fix and not merely that something is wrong.

Availability is the time the machine ran out of the time it was supposed to run. Performance is how fast it ran while running, against the fastest it could. Quality is the share of what it made that was right first time. They multiply rather than average, because each acts on what the one before left: 90 % available, 90 % of rate and 90 % good is not 90 % — it is 72.9 %. The division by 10,000 only keeps the units straight, and the × 60 converts run time from minutes into the seconds the ideal cycle is measured in. Miss that conversion and performance is sixty times wrong — at least that is obvious. The subtle errors are the two sections below.

Aggregating correctly

This mistake survives longest, because the result looks plausible. Never average the OEE percentages of individual runs. For a machine, a filter or a whole plant, add the components first — planned time, downtime, units, good units, ideal seconds — calculate availability, performance and quality once from those totals, then multiply.

The reason is weighting. A 30-minute run and an 8-hour run are not equal votes on how a machine performed, but an average of percentages treats them as though they were: a short run that happened to go perfectly pulls the average up several points while contributing almost nothing to the week's output. The same applies across machines, where a busy one and one that ran a single shift are not equally responsible for the plant's effectiveness.

Every aggregate here — tiles, machine table and its foot row, both grouped charts, the trend line — is built from summed components. Run percentages appear only in the register and the runs-needing-attention table, where they describe one run rather than standing in for many. Rebuilding from the CSV export? Sum the columns and divide once.

Planned production time

Planned production time — loading time — is the shift length minus planned non-production time: normally contractual breaks, no demand, planned preventive maintenance, scheduled meetings, and time the machine was deliberately not scheduled.

Here is the honest part: what you exclude changes the number, and there is no universal right answer. Take an hour of planned maintenance out of the denominator and availability rises; leave it in and availability falls, though the machine behaved identically. Both are defensible. What is not defensible is changing convention between machines, between months, or between the figure you review internally and the one you show a customer.

Decide once, write it down where whoever fills the tool in can see it, and put it in the report notes — one line, such as "the 8-hour shift less two 15-minute breaks and the 30-minute clean-down". Total effective equipment performance, measured against calendar time instead, is deliberately not calculated here: a guessed TEEP is worse than none.

Ideal cycle time

The ideal cycle time is the theoretical fastest cycle for that product on that machine, in seconds per unit: the design rate, or the best rate you have ever sustained. It belongs to the product and the machine together, which is why it sits on every row — the same machine running a different part has a different ideal cycle.

The temptation is to enter the average rate you normally achieve. Do not: performance would then come out near 100 % on every run, the speed losses would vanish, and OEE would quietly become a complicated availability measure. Minor stops and reduced speed are usually the largest and least visible losses on a shop floor, and the ideal cycle time is the only thing here that can see them.

The six big losses

The classic six map onto the three factors, which is what makes OEE diagnostic rather than descriptive:

• Loss — What it looks like — Hits
• Breakdowns — The machine failed and had to be repaired — Availability
• Setup and changeover — Changing over, adjusting, waiting for tooling — Availability
• Minor stops and idling — Short stops cleared by the operator, jams, sensor trips — Performance
• Reduced speed — Running below rate: wear, a trainee, a cautious setting — Performance
• Start-up rejects — Scrap made while the process settles after a start or changeover — Quality
• Production rejects — Scrap and rework in steady running — Quality

The line between a minor stop and a breakdown is time, and it is yours to set — many plants use five or ten minutes. Below it a stop is rarely logged as downtime, so the loss lands in performance instead.

The waterfall chart puts all six on one axis. Each bar is a machine's planned production time split into fully productive time, availability loss (unplanned downtime), performance loss (run time spent slower than the ideal cycle) and quality loss (time spent making units later rejected). The four blocks add to planned time exactly, which is what lets a stoppage, a slow run and a scrapped part be compared honestly. The downtime chart ranks reasons by stopped minutes alone — read it with the waterfall, not instead.

The 85 % figure

You will be told 85 % is world-class OEE, made of 90 % availability, 95 % performance and 99 % quality. Those are the defaults in Settings and worth knowing — but they came from a particular kind of manufacturing, in a particular era, and were never a universal standard.

Most plants measuring honestly for the first time land between 40 % and 65 %, and the ones reporting 85 % on day one have almost always defined planned time generously or set the ideal cycle to the achieved rate. A first honest number in the fifties is normal.

The real failure is chasing the number instead of the losses. OEE is trivially easy to improve on paper: exclude more time from the denominator, slow the ideal cycle, count reworked parts as good. All three raise the percentage and none makes an extra part. Set the target where your next genuine step is, freeze the definitions, and judge yourself on which loss bucket is shrinking.

Comparing machines

In the OEE-by-machine chart the bar is the score and the figure beside it splits that score three ways. Two machines on 70 % can need entirely different work — one losing a shift a week to breakdowns, the other never stopping but running at three-quarters speed. Only the split tells you which.

The worst machine is not automatically the best thing to fix. If it is not the constraint — it already produces more than the next process can take — raising its OEE converts effort into stock and improves nothing anybody can sell, while an hour recovered on the constraint is recovered for the whole plant. Use the ranking to see what is happening; use your knowledge of the bottleneck to decide what to do.

The spreadsheet workflow

If the run data already lives in a spreadsheet, you do not have to retype it.

• Spreadsheet template in the toolbar saves a CSV whose headings are exactly this tool's column names, with a guidance row underneath showing what each column expects — the date format, the accepted values for the shift and loss-reason lists, and the unit for each number.
• Open it in Excel or any other spreadsheet, fill in one row per production run, and delete the guidance row before saving. Keep the file as CSV.
• Import spreadsheet reads it back. Columns are matched by heading, so their order does not matter and extra columns of your own are ignored; numbers, dates and list values are converted for you. Rows missing a required column, or failing a validation check, are skipped and reported by row number.

The file is read by this page in your browser: nothing is uploaded and the original spreadsheet is not changed. Importing adds to what is already here rather than replacing it.

FAQ

Should rework count as good? No. A part reworked into acceptability consumed capacity twice, and counting it as good hides that.

One row per shift or one per product? One per machine, per shift, per product. If a machine ran two products in a shift, enter two rows and split the planned time between them — each product has its own ideal cycle time.

What happens when planned time is zero? The tool prints a dash rather than a confident wrong number.

Can I compare our OEE with another company's? Only loosely, and only if you know how they define planned time and set ideal cycle times.

Saving your work

Runs, settings and the report header are written to this browser's local storage as you type. That storage belongs to one browser on one computer: another browser, a private window or a second machine will not have it. Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you every filtered run with its calculated percentages. Reset asks twice, then erases everything. There is no undo.

Accuracy & disclaimer

The arithmetic is standard and the tool does it faithfully. Everything that matters sits underneath it: whether the ideal cycle times are design rates or achieved ones, whether planned production time is defined the same way on every row, and whether the counts and downtime minutes were written down at the time or reconstructed afterwards.

Change the definition of planned time and every percentage here moves without a machine running differently. That is why OEE compares a machine with itself over time far better than it compares one plant with another. This is a calculation and record-keeping aid, not a measurement system and not a certification of capacity.