A production management system succeeds or fails on one number: how long it takes a supervisor to record what just happened. Every other design decision is downstream of that, and most failed implementations can be traced back to getting it wrong.
What the system has to contain
At minimum, a production system needs five things. Anything less and it cannot answer the questions it will be asked.
- A plan that can be re-sequenced by the person who actually re-sequences it — and that recalculates what depends on it.
- Work orders and job cards derived from the plan, showing each machine and shift only what it needs.
- Output capture at the point of work, including short quantities with a reason and downtime with a cause.
- Stage-wise WIP with ageing, so material stalled between stages is a list rather than a discovery.
- Consumption booked against the job, so yield and loss are known per job rather than per month.
Design the capture screen first
Before any data model, design the screen a supervisor will use twenty times a shift. Work backwards from it. If the capture screen needs a field, the data model must supply it; if the data model wants a field the screen cannot justify, the field is probably not worth collecting.
A good capture screen has the machine, job, shift and operator already known — from the device, the login, or the time — and asks for a quantity, a reason code if the quantity is short, and nothing else. Large targets, because the user may be wearing gloves. Confirmation that the entry was accepted, because the network in a plant is not reliable and an uncertain user will enter it twice.
Handle shifts properly, from day one
Shifts that cross midnight are the most common source of wrong production reports, and retrofitting the fix is unpleasant because historical data has to be re-attributed.
Keep production date separate from entry date. An entry made at 00:40 by the night shift belongs to the previous production day. Get this right at the start and the daily report reconciles without anyone adjusting it.
Separate the three kinds of output
Fresh production, rework and scrap must be distinct routes with distinct records. It is tempting to record rework as production because the quantity did pass through the machine — and it inflates output while hiding the cost of quality.
Once separated, two useful numbers appear that most plants do not currently have: the true first-pass yield, and the proportion of capacity being consumed by work that has already been done once.
Reason codes: short, fixed, and reviewed
Reason codes turn 'the line was slow' into a ranked list of causes. They only work if the list is short enough to be chosen from quickly — eight to twelve options, not forty — and if it is reviewed after a few months.
Watch for the code that absorbs everything. If sixty per cent of downtime is booked as 'other', the list is wrong and the data is not telling you anything. That is a design problem, not an operator problem.
Build in this order
| Phase | What it delivers | Why this order |
|---|---|---|
| 1. Output capture | Current production position by line and shift | Immediate visible benefit; earns cooperation for everything after |
| 2. Material issue against jobs | Consumption and yield per job | Makes costing and yield analysis possible at all |
| 3. WIP and stage tracking | Ageing WIP, stalled jobs | Usually the fastest available delivery improvement |
| 4. Quality gate | Inspection on completion, dispatch control | Removes the most expensive class of error |
| 5. Planning | Re-sequencing with downstream recalculation | Built last, because it needs the actuals from phases 1–3 to be useful |
Planning last surprises people. The reason is simple: a planning module built before you have reliable actuals is planning against assumptions, and it will be ignored the first time reality disagrees with it.
Do you need machine integration?
Not to begin with, and for many plants not at all. It earns its place on high-speed machines where manual counting is impractical, or where downtime must be measured to the minute. Making the whole project depend on it is a reliable way to ensure it never finishes.
How to tell it is working
- The daily production report exists at shift end, without anyone compiling it.
- You can state current WIP by stage without walking the floor.
- A yield problem surfaces within days rather than at month-end reconciliation.
- Downtime has a ranked cause list that people actually argue about — which means they believe it.
- Nobody is maintaining a parallel production register.
Written by the team at Nij Web Solutions, who build operational systems for manufacturing and industrial businesses. If something here describes your operation, the next step is usually a conversation rather than a proposal.
Book an Operations Automation Consultation