Nextrun
Shop floor

Knowing what every machine is running right now

October 5, 20268 min read

Ask most owners what each machine is running at this moment and the answer involves walking out there. That walk is the most expensive report in the shop, and it is out of date by the time it is finished.

Walking the floor is not visibility

A walk through the shop answers one question at one moment for one person. It does not tell the estimator quoting a date whether the lathe is free next week. It does not tell customer service, taking a call about job 4471, whether that job is at weld or at paint. It does not tell the owner on a Tuesday evening whether the week is on track.

So the walk gets repeated. The foreman walks it, the scheduler walks it, the owner walks it, and each produces a slightly different account because they saw the floor at different times. The meetings that follow are spent reconciling those accounts rather than deciding anything. In a shop of eighty people this consumes several hours a day across the people least able to spare them.

What live status actually requires

Three things, and the third is where most attempts fail:

  • A booking event at the operation level. Not at the job level. Knowing a job is open tells nobody where it is. Knowing operation 030 was started at 9:14 on machine M4 tells everybody.
  • A path from that event to a screen within minutes. Not a nightly batch. A board that is accurate as of last night is a historical document, and people stop looking at it.
  • A reason for the operator to create the event. This is the one that decides whether the whole thing works.

Shop floor data collection projects fail at the third point far more often than the first two. The technology to capture a scan and display it is not difficult. Getting a machinist to scan consistently, every job, every shift, for years, when the scan does nothing for him, is difficult.

Making the event worth creating

The reliable answer is that the terminal has to give the operator something back. A screen that only takes data will be worked around. A screen that answers the operator's own questions will be used.

The questions an operator actually has are known and short:

  • What am I on next?
  • Is the material here?
  • Which revision of the print is current?
  • Am I ahead or behind on this one?
  • Who do I tell when something is wrong, and does telling them do anything?

A terminal that answers those will get used without enforcement. Clocking on becomes the way to see the next job rather than an administrative tax, and the data quality problem largely solves itself. A terminal that is purely a clock requires supervision to maintain, and supervision degrades the moment the shop gets busy, which is exactly when the data matters most.

The board the rest of the shop sees

Once operation-level events exist, the board is straightforward. It should show, for every open job, where it is, what it is waiting on, and whether it is ahead or behind its need-by date. It should update continuously. It should be visible on a screen on the floor and on a phone.

Two design decisions matter more than they appear to:

Show exceptions, not everything. A board listing nine hundred open jobs is a database with a web page in front of it. The useful board answers which jobs need attention today and puts them at the top. Everything else can be found by searching.

One board, not one per department. The moment sales, the floor and the office look at different screens, they return to arguing about whose numbers are right. The whole value is that there is one answer.

What the ERP already gives you

Most shops do not need new data capture to begin. If labor is being clocked at all, even imperfectly, the ERP holds operation-level transactions already. The problem is usually not that the data is missing but that reaching it requires a report request, and the answer arrives three days after the question stopped mattering.

So the first build is often not a data collection project at all. It is a read of data already being captured, surfaced on a screen that refreshes on its own. That is a short piece of work, it needs no change in operator behavior, and it reveals how good or bad the existing booking discipline is, which is what determines whether a scanning rollout is needed at all.

What changes

The visible change is that the walk stops. The more consequential change is that questions get answered where they arise. Customer service answers the call without walking out. The estimator quotes a date without asking the foreman. The foreman spends the morning on the two jobs that are actually at risk instead of surveying the other forty.

Shops describe the result as the floor getting quieter. What has actually happened is that information stopped being carried by people.


Request a demo

Nextrun builds live operation-level visibility on the ERP a shop already runs, and trains the floor on the terminals that feed it.