Best practice for daily tier meetings using live machine data is to review a short, fixed set of machine signals (OEE, downtime minutes and output counts) against target at the start of each meeting. Each signal that is off target gets an owner, an action and a date. Anything the team cannot fix goes up to the next tier with the data attached.
At a glance
- What it is: a daily tier meeting that starts from the last completed shift's machine signals, shown on the same board every day.
- Signals to review: OEE, downtime minutes by line and category, and cycle or output counts against target. Four to six signals per line is enough.
- Timing: 5 to 10 minutes at Tier 1. Tier 2 reviews escalations and recurring losses across lines.
- Rule: every signal that is off target has an owner, an action and a date, or it is escalated.
- Related: tiered daily management and the real-time daily management approach.
Why use live machine data in a tier meeting?
Machine data answers the first question every tier meeting asks: what happened on the line since the last one. Without it, the team spends the meeting rebuilding the shift from memory and operator notes. With it, the meeting starts from the same numbers every day, so time goes on deciding what to do rather than finding out what happened.
Live data does not replace the people on the line. It tells the team where to look, and the operator still explains why.
Which machine signals belong on the board?
| Signal | What it tells the team | Where it is reviewed |
|---|---|---|
| OEE | How much planned time became good output, and which of availability, performance or quality is dragging it down | Tier 1 board, trend by shift |
| Downtime minutes and category | Where time was lost and whether the same stop keeps coming back | Tier 1 for the shift, Tier 2 for the week |
| Cycle or output counts | Whether the line is running at rate | Tier 1 board |
| Scrap and rework counts | Quality loss from the same line, so the quality board sees it too | Tier 1, linked to the quality review |
OEE on its own does not say what to fix. Show its three factors beneath it, so the team can see whether the loss is availability, performance or quality. The OEE factors come from Nakajima's TPM work, and ISO 22400 sets out the manufacturing KPIs they sit within. Agree the definitions across shifts before the board goes live.
How do you run the meeting with live data?
- Refresh the board before the meeting, so the numbers come from the last completed shift.
- Start with the signals that moved against target, not the whole board.
- For each downtime event, check that a category and a cause were recorded. A blank category is an action in itself.
- Review the actions from the previous meeting first, then assign an owner and a date to each new action.
- Escalate anything the team cannot fix in its own area to the tier above, with the figures and the event notes attached.
- Once a week, review the trend at Tier 2, so a repeat loss gets a root cause rather than another line in the log.
What makes machine data useful and not just more numbers?
- Agreed definitions. One definition of OEE and one list of downtime categories, used on every shift and every line.
- Current. The data is up to date when the meeting starts. A figure from yesterday's shift is a history lesson, not a decision.
- Explained. A number does not say why it moved. The operator note or the cause code does.
- Checked. Counters and sensors can fail. A sensor fouling, or a counter that resets at changeover, can look like a loss. Someone on the line confirms an odd figure before the team acts on it.
- Connected to actions. Open actions sit next to the signal they address, so the board shows whether a fix is working.
How does this fit with the wider daily management system?
The tier meeting is one part of the system. The real-time daily management approach explains how issues are raised and seen as they happen, so the meeting reviews a live picture rather than a summary. For the Tier 2 layer, see digitising Tier 2 meetings. If downtime keeps recurring, the method in equipment downtime analysis shows how to find the pattern in the notes you already keep.
In TeamAssurance
TeamAssurance's tiered daily management capability puts safety, quality, delivery, OEE and downtime on the same tier boards, with actions that carry owners and dates and escalate up the tiers. Downtime is recorded as events by line and category, with the notes, which is the record the Tier 2 review needs. You can see the OEE view on the OEE software page, or book a demo to see the tier boards with your own lines.
Frequently asked questions
How long should a daily tier meeting last when it uses machine data? At Tier 1, five to ten minutes. The data should make the meeting shorter, because the team is reviewing a picture rather than building one. If it runs longer, the board has too many signals or actions are being discussed rather than assigned.
Which OEE figure should the tier board show? One figure, using one agreed definition across every shift. Show availability, performance and quality beneath it, so the team can see which loss to address.
Do you need automated machine data to run a good tier meeting? No. A manual count with consistent downtime categories, recorded every shift, is more useful than automated data that nobody reads. Automation helps once the team already reviews the figures every day.
How do you stop the board becoming a report? Every signal that is off target has an action with an owner and a date, and the next meeting checks those actions first. A board with numbers and no actions is only a report.
What should go up to Tier 2? Losses the Tier 1 team cannot fix in its own area, losses that return after an action was closed, and anything that needs another function such as maintenance, engineering or quality.
Sources
- ISO 22400: Automation systems and integration, key performance indicators for manufacturing operations management.
- Nakajima, S. (1988). Introduction to TPM: Total Productive Maintenance. Productivity Press. The original source of the OEE availability, performance and quality factors.
