A dashboard is not a reporting artefact. It is a decision instrument, and every tile on it should have an owner and an action attached. If nobody would do anything differently based on a number, that number is decoration.
Start with the decision, not the data
Write down, in plain language, the five decisions the dashboard is meant to support. For a production floor these are usually: do we need to move labour, do we need to escalate a machine problem, are we going to ship on time, is quality drifting, and are we spending overtime we did not plan. Every tile then has to justify itself against that list.
Define metrics to the point of tedium
The most common cause of dashboard death is two people disagreeing about a number in a meeting. That is a definition problem, not a data problem. Each metric needs a written spec before it is built:
| Field | Example |
|---|---|
| Name | Line efficiency |
| Formula | (Produced units x SMV) / (Operators x minutes worked) |
| Numerator source | Hourly output log, end-of-line scanner |
| Denominator source | Attendance system, actual clocked minutes |
| Excludes | Sampling, rework, meeting time |
| Grain | Line, hour |
| Target | 62 per cent for weeks 1-2 of a style; 78 per cent thereafter |
| Owner | Production Manager |
The "excludes" row is the one that ends arguments. Half the disputes about efficiency are really disputes about whether sampling minutes count.
Match refresh rate to decision rate
Refresh frequency should equal the frequency at which someone can actually act. Hourly output belongs on an hourly refresh because a supervisor can move an operator within the hour. Absenteeism trend belongs on a weekly refresh because the response is a hiring decision. Real-time refresh on a metric with a monthly response cycle produces anxiety, not action.
The layout that works
- Top strip: four to six tiles, current shift only, each with target and variance. No history. This is the "is anything on fire" row.
- Middle: trend for the same metrics over 14 days, so today's number has context. A single number without a trend invites over-reaction to noise.
- Bottom: the breakdown — by line, by style, by defect type. This is where someone goes after the top strip tells them something is wrong.
Three sections, one screen, no scrolling on the display it will actually be shown on. If it needs a scroll on a 1080p wall screen, it is two dashboards.
Handle the OEE trap
OEE is availability × performance × quality, and it is genuinely useful on capital-intensive equipment. It is close to useless as a headline for a sewing floor, because the constraint is labour rather than machine time, and because a single composite number hides which of the three components moved. If you publish OEE, publish the three components beside it, always.
Build the "why is this number wrong" path
Every metric will be challenged. Give each tile a drill-through to the underlying rows — the actual production entries, the actual downtime records. A dashboard that cannot show its work loses the first argument it has, and it never recovers its credibility afterwards.
Test for abandonment early
Four weeks after launch, check the access log. If the supervisors it was built for are not opening it daily, the dashboard has failed and no amount of visual polish will fix it. Ask them what they look at instead — usually a whiteboard or a WhatsApp group — and find out what that source gives them that yours does not. In my experience the answer is almost always speed and trust, not detail.
Discussion0
Sign in to join the discussion.