Retire the day-by-hour sheet

Why the hour-by-hour board stops working

The day-by-hour sheet is a good idea: state the target, record the actual, note why you missed. As a lean discipline at the line it earns its place. As a source of data for deciding where to spend money, it has problems that no amount of diligence fixes.

• It gets written retroactively. Boxes filled in at the end of a shift are recollection, not measurement, and the small stops are the first thing forgotten.
• An hour is too coarse. A line that lost twelve minutes across nine micro-stops looks identical to one that lost twelve minutes once, and the fixes are completely different.
• Reason codes collapse into a few favorites. "Machine down" and "material" absorb everything, because they are the fastest thing to write.
• It is not comparable across time. Trending twelve weeks of paper against each other is a project nobody has time for, so nobody does it.
• It costs operator attention. The person best positioned to fix the problem is spending part of their shift documenting it.
• Nobody fully trusts it. Which means arguments about what happened get settled by whoever is most senior rather than by evidence.

The goal is not to blame the sheet. It is to stop asking people to be the sensor.

What we instrument

The point is change over time

A number by itself is trivia. The same number across weeks, crews, tools, and seasons is where the value is, and it is the thing paper cannot give you. Once collection is automatic and consistent, ordinary questions become answerable:

• Is this drifting? Cycle times and process variables creeping in one direction is usually the earliest warning of a developing problem.
• Did that change help? Before-and-after on a new fixture, supplier, tool, or set point, measured instead of argued.
• Is it the shift or the equipment? The same line performing differently across crews is a training question; across tools it is a maintenance question.
• What preceded the bad lot? Cycle-level history means you can look backward at what the process was doing when quality turned.
• What is normal? Most plants cannot state their own baseline with confidence, which makes every improvement claim hard to defend.

This is also the honest prerequisite for anything predictive. Machine learning on manufacturing data fails far more often from missing, inconsistent, or unlabeled history than from the wrong algorithm. If someone proposes a predictive model on a line that has no trustworthy history, they are selling you the roof before the foundation.

Most of what you need is already in the PLC

The common assumption is that this means covering the plant in new sensors. Usually it does not. Your controllers already know when a station started, stopped, faulted, and completed a cycle, and often already hold the analog values worth trending. Much of the work is tapping what exists, giving it consistent meaning, and storing it somewhere it can be compared later.

New instrumentation gets added where there is a genuine gap, and every added sensor should answer a question someone has actually asked. Data nobody acts on is not an asset, it is a maintenance obligation.

Keep the humans where humans are better

Automatic collection is excellent at detecting that a line stopped and exactly how long for. It is frequently poor at knowing why. The design that works is to let the system capture the event and its duration automatically, then ask the operator only for the reason, at the moment it happens, from a short list that matches how they actually talk about the line.

That is a few seconds of input instead of a shift of documentation, and the reason codes get dramatically better because nobody is reconstructing yesterday from memory.

Do not throw away the board on day one

What a deployment looks like

Signs you need this

• Your downtime reasons are dominated by two or three generic codes
• You cannot state last month's true OEE without someone spending a day on it
• Two departments have different numbers for the same line
• You know which station is the bottleneck by opinion rather than measurement
• A quality problem sends people hunting through paper to reconstruct conditions
• Someone has proposed a predictive model and nobody can say what data would train it

Why this work is fixed-rate

Instrumentation rarely produces a profit number you can honestly attribute to it. Knowing your true bottleneck does not save money; acting on it does, and that action is usually a separate project. Rather than invent an ROI to justify a share, we scope this work and quote a fixed, predictable rate.

It is also frequently phase one. Once a line has trustworthy history, the projects built on top of it, defect inspection, part differentiation and recipe selection, or predictive quality models, do have measurable returns, and those are the ones we are glad to take on a profit-sharing basis. Establishing the baseline honestly here is what makes measuring the gain credible later.