Production control is the work of organising and tracking production as it happens: releasing jobs, directing work between operations, recording progress and responding when work is blocked or conditions change. For a production manager coordinating several work centres, it connects the day’s plan to decisions about what the team can do next.

A scheduled start gives a job a place in time. Readiness depends on what has actually happened. Materials may need to be available, an upstream operation completed, a setup checked or a quality hold resolved. A useful control system makes those requirements visible and helps the responsible person act on them.

From planned work to actual progress

A work order describes what should be made. An operation is a step in making it, such as assembly or testing. Work in progress is production that has started but is not yet finished. Release conditions are the requirements that must be met before work is allowed to begin or move on.

Planning establishes the work and resources required; scheduling places that work in a sequence and assigns times. Production control follows execution and feeds actual progress back into those decisions. The disciplines overlap: a scheduling system can include readiness information and respond to changes. The distinction to preserve is between an intended start and evidence that the job can start.

That evidence differs by operation. Assembly might record a completed quantity. Testing needs its result. Material preparation may require confirmation that the correct components have been staged. Marking the entire work order complete to clear an assembly station would leave the test team with a misleading record. Recording assembly completion against its own operation tells them what has happened without claiming that the remaining work is done.

The test bench is free, but the setup needs checking

Consider an illustrative production job approaching a test bench. Its components are staged and an operator is assigned. The bench uses a fixture to hold the item during testing, and the business requires a setup verification whenever that fixture changes. This is an example of an operating policy, not a customer case or a machine-safety interlock.

The fixture has just changed. The job is scheduled to start, but the required verification has not been recorded. Moving its card to “ready” because the scheduled time has arrived would obscure the remaining work.

The useful message is specific: setup verification is missing for this fixture and setup version, and the designated verifier must complete it. The verifier needs to see the affected job and the check required. The operator needs to see why starting is unavailable. The production manager can then distinguish work waiting for verification from work waiting for materials and respond to the actual cause.

When the verifier performs the check, the record should identify the setup version checked, the result, who completed it and when. A satisfactory result against the current setup satisfies that prerequisite. Assuming the other requirements still hold, the operator can start. The control view should reflect the recorded result through the same work records, without requiring someone to maintain a separate readiness flag.

If the fixture changes again before the operator starts, the previous result no longer establishes readiness. Checking only when the screen first opens leaves a gap: the displayed information may be out of date by the time the operator acts. The start decision needs to use the current setup and its applicable evidence.

When a later job can reuse the check

Now suppose the team reviews its policy and decides that a verified, unchanged setup can serve several jobs during the same shift. The improvement is to reuse valid evidence. Requiring a new check for every job would defeat that purpose.

The revised rule needs to define which jobs qualify. In this example, reuse applies only to jobs covered by the same verification procedure, using the same fixture and setup version within that shift, while the successful check remains valid. A different setup requires a new check. A new shift also requires a new check under this particular policy.

The next qualifying job can therefore reference the existing verification. Its record should retain which check justified the start, so the team can explain the decision later. A job outside those conditions remains waiting for its own applicable evidence. “Checked today” is too broad to express this rule: it says nothing about which setup was checked or what work the result covers.

The business must decide whether reuse is appropriate for its process. Software can apply the agreed conditions, but recording a check does not establish that the physical check was performed correctly or replace required safety measures.

Build the control view around decisions

A progress percentage can show how far work has advanced. It cannot, by itself, explain why the next operation is waiting. In the test-bench example, the actionable information is the job, current setup, missing verification and responsible role.

Keep status distinctions that change someone’s next action. “Waiting for setup verification” gives the verifier work to do. “Ready to start” gives the operator a possible next job, subject to the start check. A further label that changes neither responsibility nor available action may add little.

When you review production control software, follow one handoff through it. Record the prerequisite, supply the evidence, change the setup and try again. Then test a legitimate reuse case. This shows whether the system represents the policy and whether the operator can tell what to do next.

Running that process in Keel

Keel is an operations platform shaped around how a business works. For this production team, that means clear work for the verifier and operator, with the setup policy built into their actions and room to improve it as the process changes.

In a proposed Keel implementation, the verifier’s work view would identify the setups awaiting checks. The start-job screen would show the fixture and applicable verification. Changing the reuse policy would change which evidence appears there and the conditions under which the job can start.

Keel supports guided human steps, background processing and business rules expressed in code. Those capabilities provide the means to implement the check and the job views. The setup relationships, role permissions and validity rules still need to be built and tested, including simultaneous changes and other routes that could start a job. Reporting can show the resulting state once configured and available for the implementation. Keel-led implementation and agreed handover are part of scoping this work; this example is not an installed production-control module.

A straightforward serial process may work well with a clear procedure and a correctly configured existing job system. Detailed machine integration and production execution requirements may favour a dedicated manufacturing execution product. The useful starting point for either choice is one handoff whose readiness you can explain: the evidence required, who supplies it, what invalidates it and when reuse is legitimate.

Bring that handoff and its release conditions to a conversation with Keel about how your team needs the work to run.