This article is for plant managers, production managers, continuous improvement and maintenance leaders who are being asked, or pitched, to “put AI on downtime”. Before any model, any vendor demo or any budget line, there is one question to settle: which downtime problem are you actually trying to solve? Getting that wrong is cheap on paper and expensive on the shop floor.
- An AI model answers the question it is given, right or wrong.
- On a production line, the problem statement is written in the stop log.
- Manual logs miss short stops, round durations and overuse “other”.
- Measure every stop, rank losses, write the problem, then choose the role of AI.
The question nobody asks before the AI project
Many AI projects on downtime start from a solution. Someone wants to predict breakdowns, detect anomalies or automate reason codes. The project is scoped around the tool, the data is pulled from whatever exists, and the model is trained.
The trouble is that a model answers the question it is given. If the question is when a spindle will fail, you get a failure prediction, even if breakdowns are only a small share of the time the line loses. On many lines, for example, the bigger losses sit elsewhere: short stops of a minute or two that nobody writes down, changeovers that drift from the standard, waiting for material or for a technician. A perfect answer to the wrong question still leaves those minutes on the table.
That is why the first deliverable of an AI project on downtime should not be a model. It should be a problem statement that a production team agrees with and that the data can support.
Problem framing comes first: what Tim McMahon takes from Who Leads When AI Thinks?
Tim McMahon, founder of the A Lean Journey blog, puts the underlying principle at the center of his Book Review: Who Leads When AI Thinks? Leadership, Judgment, and the Art of Problem Framing. Reviewing Adrian Wolfberg’s book, he highlights the author’s argument that framing problems correctly is one of the most important responsibilities of leadership, and that this responsibility stays with people.
In closing, he writes that Wolfberg offers “a timely reminder that while technology may help us solve problems faster, it is still people who must ensure we are solving the right ones.”
Two other ideas from the review translate directly to the shop floor. First, the link to familiar lean practice: PDCA, A3 thinking and root cause analysis all start with careful observation and thoughtful problem definition. Second, the framework the book proposes for deciding whether AI should automate, assist, augment or simply inform a decision. Tim also notes that the book is not a technical guide to implementing AI. Its subject is judgment. And both ideas assume something that many plants do not have yet: a factual picture of where the time goes.
Why the stop log is your problem statement
On a production line, the problem statement for downtime is written in the stop log. Where did the line stop, when, for how long, how often and why? If those five answers are reliable, framing the problem is mostly a matter of reading them honestly. If they are not, every discussion about AI rests on assumptions.
Manual logs tend to fail in predictable ways. Short stops are rarely recorded because stopping to write them down takes longer than the stop itself. Durations get rounded. Reasons are filled in at the end of the shift from memory, and a large share lands in “other”. Train a model on that history and it learns the logging habits of each shift rather than the behavior of the machine.
| Question the AI project wants to answer | What the stop log must contain | Typical gap in a manual log |
|---|---|---|
| Which losses cost us the most time? | Every stop with its exact start and end time | Short stops missing, durations rounded |
| Which stops come back most often? | The count of stops, not only their total duration | Repeated small stops merged into one line or ignored |
| Why does the line stop? | A reason chosen from a short, shared list, close to the event | Reasons entered at shift end, many in “other” |
| When does it happen? | Shift, product, time of day, changeover context | Context lost when the log is typed in later |
| Did the action work? | The same measurement before and after the change | Before and after measured differently, so no comparison |
No model closes these gaps. They come from asking a question the data was never built to answer, and they have to be fixed at the source, where the stops are recorded.
Five steps to frame a downtime problem before choosing a tool
- Measure every stop automatically for a few weeks. Capture machine states with timestamps, including short stops, without relying on anyone to write them down. A few weeks of continuous data usually covers the normal mix of products, shifts and changeovers.
- Rebuild the loss picture. Separate planned from unplanned time, then split losses into availability, performance and quality. This is where OEE becomes useful: not as a score, but as a map of where the minutes go.
- Rank losses twice: by total time and by frequency. A breakdown that happens twice a month and a jam that happens forty times a shift are two different problems that call for two different responses. Looking at only one ranking hides half of the picture.
- Write the problem statement, A3 style. One sentence, with a location, a loss type, a size and a period. For example: “On line 3, stops shorter than two minutes at the case packer account for the largest share of lost time on night shift, mostly during the first hour after a changeover.” If the team cannot write that sentence from the data, the framing is not finished.
- Only then decide what role AI should play. Applied to downtime (the examples are ours, not the book’s), the framework highlighted in the review gives four options: automate (an alert when a stop exceeds a threshold), assist (suggesting a likely reason code to the operator), augment (finding patterns across shifts, products and machines that people would not spot) or simply inform (a clear view for the daily production meeting). For many plants, the honest answer today is “inform”, and a shared, factual view of last night’s stops is worth more than a model trained on guesses.
Who leads: keeping people in the loop
A well-framed problem also defines who does what. Operators know why the line stopped; the machine signal records exactly when and for how long. The most reliable stop logs combine both: the machine records the event automatically, and the operator qualifies the reason while it is still fresh.
This is the lean principle of respect for people applied to data. The goal is not to replace the conversation at the line or the walk on the shop floor, but to make it start from facts instead of impressions. When the daily meeting opens with last night’s stops, measured and qualified, the team spends its time on causes and actions, not on debating what happened.
A few signs that a downtime problem is still badly framed:
- The project is described by its tool (“an AI for maintenance”) rather than by the loss it targets.
- Nobody can say how many short stops the line had last week.
- The largest reason code is “other” or “miscellaneous”.
- Production and maintenance quote different figures for the same line.
- There is no agreed way to measure whether the action worked.
Where TEEPTRAK fits
TEEPTRAK measures OEE, stops and short stops in real time. A module wired into the electrical cabinet and a sensor at the edge of the line capture machine states automatically, with about one hour of installation per machine and no connection to the PLC, so OEE is available within 48 hours. Operators qualify the reason for each stop at the line. The result is the stop log that problem framing needs: complete, timestamped and shared by production and maintenance. TEEPTRAK is used in more than 700 plants in over 30 countries, where customers see an average gain of 10 to 15 OEE points and 30% fewer unplanned stops on average. Then the AI decision, whatever it turns out to be, starts from a stop log everyone trusts.
Further reading
- Book Review: Who Leads When AI Thinks? Leadership, Judgment, and the Art of Problem Framing (Tim McMahon, A Lean Journey)
- Downtime reason codes: the standard list and how to use them
- From measurement to root cause: measure then explain
FAQ
Do we need AI to reduce downtime? Not to start. Most plants find their biggest losses simply by measuring every stop automatically, ranking losses and acting on the largest ones. AI becomes useful once the problem is clearly framed and the data is reliable enough to support it.
How much data is needed before framing a downtime problem? A few weeks of continuous, automatic stop data is usually enough to see the main losses, as long as it reflects normal production. Completeness matters more than the length of the history.
Can AI fix an unreliable manual stop log? Not really. A model trained on incomplete logs learns the gaps: missing short stops, rounded durations and vague reasons. The fix is to capture stops automatically and let operators qualify the reasons at the line.
0 Comments