This article is for plant managers, production managers, continuous improvement and operational excellence managers who are building or redesigning their dashboards. The most common problem is not a lack of data, it is the opposite: the same sheet, loaded with dozens of figures, travels from the line to the executive committee, and nobody finds in it what they need to decide. The question here: which OEE and downtime indicators to show at each level, how often, and which ones to leave on the shop floor.
- Each level of the plant makes different decisions and needs different indicators.
- The higher you go, the fewer indicators and the longer the horizon.
- Detail stays on the shop floor and only moves up by exception.
- A single OEE definition makes figures comparable across levels.
What Alain Fernandez sets out about the manager’s dashboard
Alain Fernandez, a specialist in performance management and decision support, presents his book on Piloter.org in the page Les nouveaux tableaux de bord des managers : référence du pilotage de la performance (in French). He describes a cooperative ten-step approach, the GIMSI method, illustrated with a practical case, for designing dashboards that serve decision making rather than technical concerns. He stresses that dashboards must be consistent with strategy and that information must be made reliable from data collection onward, and the latest edition adds a section on qualitative measures. Among the stated goals, the page lists: “Choisir les indicateurs de performance les mieux adaptés à chaque situation.” (choose the performance indicators best suited to each situation).
That idea is the starting point of this article. In a plant, the “situation” changes at every level: a team leader, a department manager, a plant manager and an executive committee do not make the same decisions, nor at the same pace. Each one’s dashboard must therefore hold different indicators, even if they all come from the same shop floor measurement. The design method belongs to Alain Fernandez’s book; here we apply it to OEE and production downtime indicators.
One dashboard per decision level
The right starting point is not the list of available data but the list of decisions made at each level. On the line, decisions are made in minutes: restart, call maintenance, correct a setting. In the department, they are made in days: where to assign technicians, which cause to tackle first. At plant level, trade-offs are made over weeks or months: improvement plans, maintenance budget, shift organization. At the executive committee, decisions are made by the quarter: investments, capacity, targets per site.
The table below proposes a typical split. Adapt it to the size and organization of your site, but the logic stays the same: the higher you go, the fewer indicators, the longer the horizon and the more aggregated the figures.
| Level | Who uses it | OEE and downtime indicators | Frequency | Decisions supported |
|---|---|---|---|---|
| Line, workstation | Operators, team leader | Real time machine status, current stop and its cause, micro-stops, actual rate against target rate | Continuous, start of shift huddle | Restart, call maintenance, correct a setting |
| Department | Production manager, maintenance, engineering | OEE per machine and per shift, top three to five downtime causes by duration, long unplanned stops | Daily, with a weekly summary | Assign resources, launch and follow corrective actions |
| Plant | Plant manager, site committee | OEE per department and on bottleneck machines, trend over several weeks, time lost per main cause family, action progress | Weekly, monthly | Set priorities, maintenance budget, improvement plans |
| Executive committee | General management, operations leadership | OEE trend per site, gap to target, capacity lost or recovered, two or three issues that need a decision | Monthly, quarterly | Investments, capacity, targets per site |
Do not drown management: what stays on the shop floor
An executive committee that receives the OEE of every machine, the list of micro-stops and thirty downtime causes cannot do anything with it. The detail is not useless: it is simply meant for other people. It remains available for anyone who wants to dig, but it only moves up by exception. How to present losses in hours of capacity is covered in another article; the question here comes earlier: who sees what, and how often.
Three rules prevent overload. First, exception rather than completeness: escalation thresholds defined in advance push an event to the next level only when it justifies it. For example, a long stop on a bottleneck machine can be reported to the production manager within the hour, while it will only reach the executive committee if it weighs on the month’s capacity. Second, clean aggregation: a consolidated OEE is calculated from cumulated times, not by averaging each machine’s percentage, otherwise a small machine weighs as much as a bottleneck. Third, a single definition: the same OEE, with the same downtime categories, from the workstation to the committee, so figures reconcile from one level to the next.
A number alone is not enough. For each gap that moves up, a short qualitative note (identified cause, action under way, owner, deadline) keeps the meeting from turning into an investigation. That note, more than the percentage, is often what lets management decide.
Building the escalation step by step
The approach below applies the “one decision, its indicators” logic to the shop floor; run it with the people who will use each dashboard, not only with those who produce it.
- List the decisions made at each level. For the line, the department, the plant and the executive committee, write down the decisions actually made and their pace.
- Attach one or two indicators to each decision. An indicator that serves no decision has no place on that level’s dashboard.
- Set a common definition. Same OEE calculation, same downtime categories, same rules for planned stops in every department and every site.
- Make data reliable at the source. If stops are entered by hand at the end of the shift, errors spread to every level. Automatic, time stamped measurement limits that risk.
- Write the aggregation rules. How you move from machine to department, then to site: consolidation by time, treatment of bottleneck machines.
- Define escalation thresholds. What must move up immediately, what waits for the daily meeting, what waits for the monthly committee.
- Align frequency with existing routines. Start of shift huddle, 15 minute daily meeting, weekly review, monthly committee: each dashboard has its slot.
- Review the dashboard every quarter. Remove what nobody looks at, add what was missing to decide.
What TEEPTRAK brings
TEEPTRAK measures OEE, downtime and micro-stops in real time on each machine. A module wired into the electrical cabinet and a sensor at the line record activity automatically, without connecting to the PLC; installation takes about one hour per machine and OEE is available within 48 hours. Stops are time stamped and qualified by cause, with an identical definition on every machine, so the same data can be consolidated from the line to the site without re-entry. The solution is deployed in more than 700 plants in more than 30 countries.
Further reading
- Les nouveaux tableaux de bord des managers : référence du pilotage de la performance (Alain Fernandez, Piloter.org, in French)
- Presenting production losses to management: from percentages to hours and capacity
- Daily production meeting: 15 minutes with yesterday’s downtime data
FAQ
How many indicators should the executive committee see? Few: the OEE trend per site, the gap to target, capacity lost or recovered and the two or three issues that need a decision. The detail remains available on request.
Should micro-stops be escalated to management? Not one by one. They are handled on the line and in the department. They move up aggregated in a cause family if they weigh on the site’s lost time.
How do you consolidate the OEE of several machines or departments? From cumulated times and with a common definition, rather than by averaging percentages; otherwise a small machine weighs as much as a bottleneck.
0 Comments