OEE dashboard examples, and the question each tile answers.

One rule decides what goes on a dashboard

Every tile answers one question, written down, in words, before the tile exists. If you cannot write the question, delete the tile. If two tiles answer the same question, keep the one somebody can act on.

It is the only discipline that stops a dashboard growing into a wall of charts nobody reads, because it forces every chart to name a decision. “Which machine is dragging the shift down?” is a question. “Are we going to finish this job before the shift ends?” is a question. “OEE over time” is not — it is a chart title, and a chart title is what you write when you have not decided who is looking. Apply the rule honestly and you get three boards rather than one, because a setter, a production manager and a director ask different questions on different clocks.

Why a single OEE number on the wall is the least useful chart on it

OEE is three ratios multiplied together, so the headline figure tells you the size of a problem and nothing about its address. A shop at 74.8% might be losing to breakdowns, to a slow cycle or to scrap, and those three demand different people, different budgets and different weeks. The number has told you to be unhappy and then stopped.

On a multi-machine board it is worse. A factory OEE of 74.8% can be nine machines at 80% and one at 30%. The average is true and useless; the distribution is where the money is, and the distribution is exactly what the headline hides. So that figure earns its place on one condition: it sits next to its own three components and a per-machine breakdown, on the same screen. Alone and in a large font, it is decoration. What each component measures, and the ways each gets flattered, is on our plain-English OEE guide — worth reading first, because a dashboard inherits every definition argument underneath it.

Board one: the shift board

Audience: operators, setters, the team leader, anybody walking past. Window: live, plus shift-to-date. Nothing older than today appears on it. This board goes on a television on the wall, so it is designed to be read from across a bay by somebody carrying something.

Four rules for a screen that lives on a wall:

• State is colour plus a glyph plus the word. Roughly one in twelve men on a shop floor cannot reliably separate the red and green andon boards are built from, and a board they cannot read gets ignored rather than queried.
• Put a last-updated stamp on it. A frozen screen showing yesterday’s good news is worse than a blank one, because people act on it.
• Nothing that needs a mouse. No hover tooltips, no drop-downs, no legend to decode. If a tile only makes sense to somebody sitting at it, it belongs on the weekly.
• Never show a shift that has barely started as 0%. At 06:05 a shift-to-date OEE is arithmetically real and practically meaningless. Say the window is too short, or wait.

Board two: the manager’s weekly

Audience: production manager, engineering manager, whoever runs the Monday meeting. Window: last week, with the week before it beside it. This is the only board on which “is it getting worse?” is answerable, so every tile on it should be comparative.

• Downtime Pareto in hours, by reason, with unclassified on the chart. The tile most often built wrongly — see the next section.
• OEE by machine, as a ranked bar chart. Never one factory average. The ranking is the point: the bottom two bars are next week’s work.
• Availability, performance and quality per machine, side by side. Three small bars against each machine name tells you which leg lost, which decides who fixes it. A single OEE column per machine sends everybody to the same meeting.
• Standard-cycle exceptions. Machines whose raw performance ran over 100% for a sustained period. Not a compliment — a list of standards to re-time, and the cheapest data-quality tile you will ever build.
• Scrap by reason, and scrap by machine. Two charts: the dominant defect and the machine it belongs to are different findings with different fixes.
• A data-quality tile, at the top of the page rather than the bottom. Unclassified downtime as a share of stopped time, hours outside any defined shift pattern, and intervals where a sensor or meter dropped out. If that tile is bad, everything below it is decoration — and putting it first stops a meeting arguing about a number nobody measured.

One discipline holds the weekly together: every number on it must be traceable downwards in one step — factory, location, machine, then the timestamped event or job behind the figure. If a bar cannot be opened, it is not evidence. The first time somebody senior asks where a figure came from and the answer is a shrug, the board is finished.

Board three: the director’s monthly

Audience: the board, the owner, whoever signs off capital. Window: the month, against a rolling twelve. Four tiles is plenty, and the temptation to add a fifth should be resisted harder than anything else in this guide.

• OEE trend with its spread, not just its mean. The monthly figure as a line, the machine-by-machine range as a band around it. A flat mean hiding a widening spread is a factory becoming less predictable, and the mean alone will never say so.
• Losses converted into hours, then into capacity. “We lost 612 hours to unplanned downtime, which is one press running two shifts a day for nearly eight weeks” is a sentence a director can act on. A percentage is not. It is also the tile that answers whether the next machine needs buying.
• Cost per part, and be precise about what is in it. A real cost per part is a composite — energy plus material, labour and a fair share of overhead, tied to the works order that incurred it. If your sheet currently holds energy only, label the tile energy cost per part and mean it: calling an energy figure a cost per part is the fastest way to lose an argument with a finance director. Cavities matter here too — a four-cavity tool makes four parts a shot, and a cost per part that divides a cycle by one is out by a factor of four.
• Measured against entered. What share of the month’s figures came off machines, and what share was typed by a person. Nobody thanks you for this tile, and it is the reason the other three survive scrutiny.

The downtime Pareto, done properly

The highest-value chart in this set, and routinely built in a way that inverts its own answer. Five rules:

1. Rank by minutes lost, never by number of events. Ten two-minute material stops and one three-hour breakdown are twenty minutes and one hundred and eighty. Counted by events, material wins ten to one and you spend the quarter on the wrong problem.
2. Put the cumulative percentage line on it. Without it a Pareto is a sorted bar chart. With it you can see whether three reasons carry 80% of the losses — in which case you have a plan — or whether fourteen carry it evenly, which is a harder problem and worth knowing early.
3. Show unclassified as a bar, at its true height. The instinct is to exclude it so the chart looks clean. If unclassified is the tallest bar, that is the finding, and hiding it makes everything below a picture of the third of your downtime somebody happened to classify.
4. Use a two-level reason tree. Category — breakdown, changeover, material, quality, planned, other — then a detail underneath. Rank the weekly at category level, drill to detail for the fix. Fifty flat reason codes give you fifty two-per-cent bars and no answer.
5. One machine or one cell, one week. A Pareto covering a whole factory over a quarter averages away the machine that has the problem. It is a diagnostic instrument, and those get pointed at one thing.

The averaging trap, and the arithmetic that fixes it

This mistake quietly breaks more factory OEE figures than any other, and it survives in spreadsheets for years. Never average a percentage. Recompute it from the totals.

Two presses, one week. Press 1 had 80 hours of loading time and ran 72 of them — 90% available. Press 2 was wanted for one shift only, so it had 8 hours of loading time and ran 4 — 50% available. Average the percentages and you get 70%. Recompute from the totals and you get (72 + 4) ÷ (80 + 8) = 86.4%. Sixteen points, from a pivot table, on a shop with nothing wrong with it.

The same error hides in time. Seven daily OEE percentages averaged across a week give Saturday’s two-hour run the same weight as Tuesday’s double shift, and one quiet Sunday reported as 0% takes several points off a month that was fine. The direction of the error is unpredictable, which is what makes it dangerous: it is not a consistent bias you can learn to allow for.

The fix is structural, and it is the most important thing on this page. Store totals at the lowest level and derive every ratio at the level you display it. Loading minutes, run minutes, theoretical parts, parts made, parts scrapped — those add up. Percentages do not. A ratio stored in a cell will eventually be summed, averaged or pivoted by somebody in a hurry, and nothing downstream will flag it.

The spreadsheet layout that survives

If you are building this yourself, the shape of the sheet matters more than any chart on top of it. One row per machine per window — a shift, or a day. Never one row per week, and never one row per machine with the weeks running across in columns, which is the layout that makes every later question impossible. Columns, in this order:

• date, shift, machine
• loading_min — the time you intended to produce in
• run_min — the time it actually ran
• std_cycle_s, cavities, std_set_on, std_source
• parts_made, parts_scrapped
• downtime_min per reason category — or a key into a separate sheet holding one row per stop

The two provenance columns look like bureaucracy and are the difference between a sheet that lasts and one that does not. std_set_on is the date the standard was set; std_source is where it came from — a time study, a quotation, the machine manufacturer, somebody with a stopwatch in 2019. Performance is measured against that number, so a performance figure without its provenance measures an estimate nobody owns.

Then derive, never store:

• Availability = run_min / loading_min
• Theoretical parts = run_min * 60 / std_cycle_s * cavities
• Performance, raw = parts_made / theoretical — with a second column, capped = MIN(1, raw). Report both. When they disagree the gap is the finding, and it is almost always the standard rather than the machine.
• Quality = (parts_made - parts_scrapped) / parts_made
• OEE = availability * capped_performance * quality on the row — and for any roll-up, recomputed from the summed totals rather than averaged down the column.

Two formulas worth writing in on day one, because retrofitting them is much harder:

• The empty window. =IF(loading_min=0,"No production in this window",run_min/loading_min). A blank or a zero denominator must never become 0%. One line, and it prevents the commonest way a monthly figure gets destroyed — with the useful side effect that a text value cannot be averaged by a pivot table even if somebody tries.
• The reconciliation. loading_min - run_min - SUM(downtime_min) should be zero. It will not be. The residual is the downtime nobody wrote down, so put it on the sheet in a column called unclassified_min and chart it rather than letting it vanish into a rounding difference. It is the best single indicator of how much of your Pareto is evidence.

The same rules in Power BI, or any BI tool

A BI tool changes none of the arithmetic above, only where it lives. Four decisions matter.

• Import events, not summaries. One fact table of downtime and state events with start and end timestamps, one of production counts, and small dimension tables for machine, shift, reason and part. A pre-aggregated weekly extract cannot be drilled, so the first question anybody asks of it ends the conversation.
• Write measures, not calculated columns. Sum the minutes and divide inside the measure, so every filter level recomputes from totals. A percentage stored as a column is one that will eventually be averaged, and the trap above arrives the moment somebody drops it onto a matrix.
• Make the standard cycle a slowly-changing dimension with a valid-from date, so last March’s performance is measured against last March’s standard. Restating history silently is how a trend line becomes fiction.
• Return text, not zero, for an empty window, and put a visible refresh stamp on the page. A dashboard that cannot say how old it is will be believed at exactly the wrong moment.

How a spreadsheet version goes wrong over time

None of this is an argument against spreadsheets, and a sheet built as above will serve a small shop honestly for years. These are the six failures that arrive with age, roughly in the order they turn up.

1. The standard cycles go stale. Nobody owns the column, so a process improvement, a new grade of material or a tool refurbishment never reaches it. Performance becomes a measurement of a five-year-old estimate, the number moves for reasons nobody can explain, and people stop reading the report rather than fixing it.
2. Downtime gets typed rather than measured. Friday afternoon, from memory and a paper log. The three-hour breakdown is remembered exactly; the eleven short stops are not remembered at all. The Pareto becomes a chart of what people recall, biased towards the dramatic.
3. An empty window gets reported as 0%. An unstaffed Saturday shows as a zero, the zero pulls the average down, somebody explains it in a meeting, and next month the quiet periods get excluded by hand — a judgement about which periods were quiet, made after the numbers are known.
4. The tab-per-week fork. Somebody copies last week’s tab and changes the dates. Six months on, two tabs compute performance differently because one was fixed and the other was not, and nothing says which figures came from which.
5. Nothing records an edit. A number can be changed after the meeting in which it was questioned and the sheet looks identical afterwards. That is the point at which the figures stop being usable as evidence with a customer or an auditor, and usually nobody notices it happening.
6. The gap between the event and the entry widens. A stop at 02:40 written up at 09:00 by somebody who was not there. Every figure downstream inherits that gap, and it grows in exactly the weeks when production is busiest.

The common thread is provenance, not arithmetic. A spreadsheet faithfully stores what a person typed into it; by the time the numbers matter enough to be argued about, the question being asked is where they came from, and that is the one question a cell cannot answer.

When a spreadsheet stops being enough

The test is not the size of the factory. It is the first time a number has to be defended — to a customer, a board, an auditor or a compliance scheme — and somebody senior asks where it came from. A figure that traces back to a timestamped machine-state ledger survives that question. A figure assembled from classifications typed on a Friday does not, and the moment one fails, nobody believes the next one either.

What production monitoring software changes is that provenance. States are derived from real cycle data rather than declared; a stop opens its own downtime event, timestamped from when the machine actually stopped rather than when somebody noticed; unclassified downtime is reported as a figure in its own right; an empty window says so instead of showing a convenient zero; and raw and capped performance sit side by side rather than being reconciled into one. The mechanics are on the production monitoring page, where the dashboards ship as five role presets and every tile carries the written question it answers — the rule this guide opens with, because it is the rule that made the product usable.

It also does not have to replace the sheet you have. Software reading controllers read-only, with meters clamped onto supplies, runs alongside whatever you do today, so the sane move is to keep both for a quarter and compare rather than switching and hoping. Export a week, rebuild one figure with the formulas above, and if your arithmetic and the system’s disagree you have found either a definition nobody mentioned or a fault. Either is worth knowing before you commit to anything.

Three places to go next. To feel how sensitive the arithmetic is before you design a single tile, 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. For what each component measures and the six ways a figure gets flattered on its way upstairs, read OEE in plain English. And if you have got as far as comparing systems, choosing production monitoring software has the ten questions worth sending a vendor in writing before you book a single demo.