This article is for shift leaders, team leaders and production managers, and for the continuous improvement engineers who support them. It covers one concrete habit: every day, at the start of the shift, reviewing the previous shift’s downtime causes with your own team and attaching one action to them. Not the daily production meeting with department heads, but the short loop the shift leader controls directly, at the line, between two handovers.
- The shift leader reviews downtime causes with their own team at every handover.
- Four questions are enough: biggest cause, recurring cause, unexplained stops, effect of the action.
- One cause and one action per shift, anything beyond the team goes to the production meeting.
- Measured stops move the conversation from what happened to why.
What Kruispunt Engineering writes about production data insight
Kruispunt Engineering, an independent Dutch engineering firm with offices in Cuijk, Schijndel and Weert that designs and programs machines and control systems, published the article Hoe krijg ik meer inzicht in mijn productiedata? (“How do I get more insight into my production data?”) by Stijn Peters on 1 July 2026. In its FAQ on operator adoption, one sentence goes straight to the point of this article: “Een korte dagelijkse bespreking van de dashboardresultaten in het team verankert het gebruik snel in de dagelijkse routine.” (“A short daily review of the dashboard results within the team quickly anchors their use in the daily routine.”)
The Kruispunt Engineering article describes the path from measuring to understanding, prioritizing and acting, and draws a clear line: a dashboard shows what happened, process analysis explains why. It also advises starting small, with two or three data points, because “Meer data is niet automatisch beter inzicht.” (“More data is not automatically better insight.”) Kruispunt Engineering focuses mainly on collecting and analyzing that data reliably, down to the machine’s controls. This article fills in one link: who leads that daily review, with which downtime data, and how it turns into an action within the same day.
Why the shift leader should lead the review
The daily production meeting looks at yesterday at department or plant level and decides on what the team cannot solve alone. That meeting is necessary, but it is slow for stops that come back every shift: a jammed infeed, waiting for material at shift start, a sensor that keeps getting dirty. Sending those causes up to the meeting and waiting for the action to come back down costs days.
The shift leader is closer to the line. They know who was on the machine, which order was running and what was said at handover. They can assign an action within the team and check at the next handover whether it worked. That is why the first review of downtime causes belongs at shift level, with only what goes beyond the team passed on.
What downtime data the shift leader needs
In line with Kruispunt Engineering’s advice to start with few data points, four questions are enough. Each one needs a single type of data.
| Shift leader’s question | Downtime data needed | Why |
|---|---|---|
| What cost the previous shift the most time? | Top three downtime causes in minutes, per machine | Sets where the review starts |
| What keeps coming back? | Number of stops per cause, including short ones | Micro-stops weigh in count, not in one long stop |
| What is still unexplained? | Stops with no cause or coded as “other” | An unexplained stop is a question for the team, not a reproach |
| Is yesterday’s action working? | The same cause before and after the action | Closes the loop and avoids actions with no effect |
The review in five steps, at every handover
- Open the overview before the shift starts. The shift leader spends two minutes on the previous shift’s stops, ideally with the colleague handing over.
- Pick one cause. The one with the most minutes, or the most frequent on the bottleneck machine. Not three at once.
- Ask the people who were there for context. Operators know what the data does not say: which material, which setting, which manual step. This is where a stop becomes an explained cause.
- Record one action the shift can carry out itself. With a name and a time, within the shift. Anything beyond the team (maintenance, purchasing, planning) goes to the daily production meeting, with the data.
- Check at the next handover. Has the same cause dropped in minutes or in count? If not, the action was the wrong one or was not carried out.
An example for illustration: a shift leader sees that a labeling machine kept stopping for a few seconds during the previous shift, always with the same cause. The operator from that shift explains that the label roll was being loaded a different way. The action is simple: show the right method at the machine and compare the number of short stops on that cause at the next handover.
Why the review needs measured data
Without measured stops, the review turns into a debate about what happened instead of why. Manual logs, filled in from memory at the end of the shift, miss short stops and collect a lot of “other”. Kruispunt Engineering also points out that manual registration is often incomplete and delayed. The result: the biggest causes are underestimated and no action can be verified afterwards.
Measured stops change the conversation. The team discusses the cause, not whether the stop really happened. Two points keep the review healthy. Compare causes, not people: a shift with more short stops may simply be running a harder product. And let the operator assign the cause at the machine: the data stays the team’s own, which matches what Kruispunt Engineering writes about adoption.
Where TEEPTRAK fits
TEEPTRAK measures stops automatically: a module in the electrical cabinet and a sensor at the line, about one hour of installation per machine, with no PLC connection, and a first OEE within 48 hours. Operators assign the cause at the machine, so at handover the shift leader has an overview by cause and by machine. TEEPTRAK does not replace machine or control system engineering and is not a MES: it provides the downtime data the daily review relies on. It is used in more than 700 plants in more than 30 countries, with on average 30% fewer unplanned stops.
Further reading
- Hoe krijg ik meer inzicht in mijn productiedata? (Kruispunt Engineering, in Dutch)
- OEE gap between shifts: why the night shift scores lower and how to close the gap
- QRQC with machine data: downtime and scrap facts for faster problem solving
FAQ
How long should the shift leader’s downtime review take? Five to ten minutes is enough when the data is ready. The goal is one cause and one action, not a full analysis of the shift.
How is it different from the daily production meeting? The production meeting looks at the department or the plant and decides on issues beyond the team. The shift leader’s review happens at the line, at handover, and focuses on actions the shift can carry out itself.
What should the shift leader do with stops that have no cause? Go over them with the operators from the previous shift and have the cause assigned. A falling share of unexplained stops is itself a sign that the review is working.
0 Comments