Tracking a job's actual progress on the shop floor with Eryxon Flow

A batch has cleared cutting but has not reached the bending cell. The planner’s screen still shows one line: “in production.” A customer asks when the parts will be ready. That single status cannot answer the question. Someone needs to know which operation is complete, what can start next, and whether the work is waiting for people, material or a drawing decision.

This is the practical purpose of job-level tracking in Eryxon Flow. A manufacturing execution system, or MES, sits between the production plan and events on the floor. The phrase “real time” deserves some caution, though. The screen reflects the latest event someone reported or an integrated system supplied. Software cannot infer a stoppage that nobody recorded.

One order can contain several different realities

An ERP order has a due date and a planned quantity. On the floor, its parts may pass through cutting, bending, welding and assembly. Some pieces may be complete while others have not started. If the only available status belongs to the whole order, the difference disappears.

Useful tracking therefore needs a clear unit of work. The job identifier, part, quantity and sequence of operations must remain connected. When cutting finishes, the cutting operation changes state; the next cell can see what is ready and what is not. “How much did we make?” and “Where is the job?” become two questions that can be answered separately.

That does not mean recording every motion. Starting an operation, stopping it, finishing it, and recording accepted or scrapped quantities are sensible first events. More data does not help if nobody agrees on what the statuses mean. A long list of vague reasons simply produces a more detailed form of uncertainty.

A shift at the bending cell

Imagine three jobs due at the same bending cell. Cutting is complete for the first. The second has only some of its cut parts available. The third is waiting for approval of a drawing revision. If the planner’s spreadsheet puts all three under “bending,” the operator has to call around before choosing the next job.

In a job-tracking workflow, the first job can show its completed cutting quantity. The second can show a partial quantity. The third can carry an issue rather than looking ready. The queue distinguishes work that can be started from work that is merely assigned to the cell. When an operation is completed, its successor can be evaluated against the actual handoff rather than the date on a plan.

Eryxon Flow describes cell queues, visible ready, running and overdue work, and reporting of time, good quantity, scrap and issues against operations. The three jobs above are an illustration, not a claim about a real installation. Each shop must define its own routings and reasons before a screen can reflect its practice faithfully.

What makes a live status trustworthy?

Refresh speed is not the first thing to check. The age and origin of the last event matter more. “Running” is a weak statement if nobody has touched the record since the previous shift. Store when a status changed, which operation it concerns, and whether the change came from an operator or an integration. A stale status should be recognisable as stale.

The next question is what “done” means. Did the operator finish their task? Was the part inspected? Has the batch physically reached the next cell? Those are not interchangeable events. Promising a shipment on the strength of an operation-complete flag is risky if the parts are still waiting for measurement or transport.

Quantity also matters. If cutting shows complete but only part of the required batch is usable, bending may not be able to work through the full order. Showing good and scrapped quantity beside operation status provides a more honest view than a single progress percentage. Where a report is missing, “unknown” is often a better answer than confidently repeating yesterday’s state.

Start with one route, not the whole factory

A practical rollout can start with one family of parts moving from cutting to bending. Define a stable job identifier, the route, the events worth reporting and the meaning of each status. Specify where operators report a start or stop, who can correct an accidental entry, and what should happen when the next cell receives less than the planned quantity.

Then compare the screen with the physical flow for a shift. Can a job marked ready actually start, with the required material and current drawing? Has a job marked complete really moved to its next step? When those answers disagree, look at the process and the interface before demanding more data entry. A cumbersome reporting step often creates exactly the blind spot the system was supposed to remove.

Integration boundaries need the same attention. ERP planning data and shop-floor events may use similar field names while describing different facts. Decide how a drawing revision, a split batch or rework retains its identity across systems. Decide what happens to events when a connection drops and how they are reconciled afterwards. A dashboard cannot repair conflicting definitions by displaying them faster.

An earlier article on paperless work orders covered getting instructions to the operator. Job tracking looks in the other direction: getting meaningful observations from the floor back to planning. The two flows may share an interface, but they answer different questions.

Visibility should lead to a specific decision

A count of waiting jobs is useful only up to a point. Waiting for material, a drawing approval, available capacity and quality inspection call for different actions. If the MES groups them all under one label, the display becomes a faster way to discover whom to telephone.

A small set of well-defined reasons is more valuable than an elaborate wall of charts. A revision hold can trigger a planning change; a capacity queue can be resequenced. The point is not to make every movement look immediate. It is to preserve enough reliable context that the person responsible can make the next decision without reconstructing the history from memory.

Sources: the Eryxon Flow product page and Luke van Enkhuizen’s overview of open-source manufacturing tools. Product capabilities here reflect those descriptions; the rollout guidance is a general design approach.