Production Control: Frequently Asked Questions for Organising Work

When an order comes to a standstill, a delivery date changes or two people are working from different versions of the same information, the issue is not always a lack of effort. Often, there is no shared way of seeing what needs to be done, what has been completed and what is blocked.

Production control helps organise this information. This article explains what it covers, what data is worth recording, where its limits lie and when it makes sense to consider a tool tailored to your business.

Definition questions

What is production control?

It is the management of the work needed to turn a request, an order or an internal job into a completed delivery. Its practical function is to show the status of each job, pending tasks, those responsible, the materials or resources required and any issues that may delay it.

It is not just about noting that an order is "in progress". It should make it possible to understand which stage has been completed, what comes next and why a job cannot move forward.

What is the difference between production control and production planning?

Planning determines which jobs will be done and when they should be done. Production control checks what is actually happening while they are being carried out.

For example, planning may assign an order to a particular week. Control records whether the order has started, is waiting for materials, needs a review or is ready for delivery. Both are necessary, but they address different points in time.

Is production control only useful for factories?

No. It can be applied to any business that repeats a process of preparation, execution and delivery. A workshop, an assembly company, a bakery, a printing business or a team providing services with defined stages may need it.

The tracking unit does not have to be a manufactured part. It may be a work order, a project, a batch, a repair or a contracted service.

Scope questions

What should production control make visible?

At a minimum, it should make it possible to locate each order and answer the following without searching through conversations, paperwork or scattered files:

• what needs to be done;
• which stage it is at;
• who is assigned the next action;
• what date or priority it has;
• what resource, material or approval is missing;
• what issue has occurred;
• when each relevant step was completed.

The level of detail depends on the process. Recording every movement may be excessive if you only need to control stages. However, an operation with traceability requirements may need to link an order to specific batches, controls or documents.

What information should a production order include?

The short answer is: what is needed for another person to continue the work without having to interpret incomplete data.

It is usually useful to define an order identifier, the product or service, the quantity or scope, relevant dates, status, the person responsible and execution instructions. If materials, equipment, suppliers or controls are involved, it is also worth deciding what relationship should be recorded.

Before designing a screen or spreadsheet, separate three layers:

This separation prevents choosing an application before knowing what needs to be controlled.

Should it include inventory and purchasing?

Only if they are part of the decision you want to make. Production control can alert you that a material is missing or link its availability to an order. However, managing stock, suppliers, receipts and replenishment involves additional rules and data.

It is useful to distinguish between "I need to know that material is missing to continue" and "I need to manage the entire inventory cycle". They are different scopes, although they are connected.

Can it manage urgent jobs or priority changes?

Yes, provided you define who can change a priority, what effect this has on orders already planned and how that change is communicated. Marking an order as urgent without reviewing its dependencies may hide the conflict rather than resolve it.

The system should reflect the decision, but priority remains a human decision. No automatic rule can independently know the actual commitments made to customers, people or suppliers.

Technical questions

Which statuses are worth using?

Use statuses that correspond to observable decisions or situations in the process. For example: pending preparation, in progress, pending review, blocked, completed or delivered.

Avoid overly broad statuses, such as "in process", if they can include situations requiring different actions. Also avoid creating too many statuses if no one can apply the distinction consistently.

A simple test: each status should indicate what can be done next and who should do it.

How are bottlenecks identified?

First, you need to record consistently where each order is waiting and why. A bottleneck may appear when jobs accumulate at one stage, when one person or piece of equipment concentrates too many tasks, or when a dependency repeatedly blocks progress.

It is not enough to see a long list of pending items. You need to distinguish between work not yet started, work in progress, blocked work and work awaiting validation. That distinction turns a list into useful information for decision-making.

What is traceability in this context?

Traceability is the ability to reconstruct an order's journey: what was done, when, by whom, and which elements or controls it was associated with.

Not all businesses need the same level of traceability. In some cases, a history of status changes is enough. In others, it may be necessary to associate batches, issues, documents or review results. First define which question you need to answer after an incident; this will prevent you from storing data you will not use.

Is a spreadsheet or an application better?

A spreadsheet can be useful for validating fields, statuses and responsibilities when the process is simple and only a few people update it. Its limitations become apparent when several people edit it at once, different permissions are required, manual tasks are repeated or it becomes difficult to know which data is current.

An application may be suitable when you need information to be consulted and updated through a shared workflow, with rules, alerts, history or connections to other tools. The choice does not depend on one option being more modern, but on the actual complexity of the process and who will maintain it.

What should be tested before implementing a system?

Test complete workflows, not just individual screens. For example: create an order, assign it, move it through a stage, record a blockage, resolve it and close the job.

It is also worth checking what happens with incomplete data, priority changes, permissions for each role and data-entry errors. Define who validates that the system reflects the agreed process and what result is considered correct at each step.

Limits and exceptions

Does a production control system replace the person in charge?

No. The system organises data and makes statuses, pending items and issues visible. The person in charge still interprets priorities, available capacity, exceptions and commitments to customers or suppliers.

Presenting information clearly helps people make better decisions, but it does not remove the need to review sensitive decisions.

What happens if every job follows a different process?

You do not need to force all jobs into the same sequence. You can define different routes by order type, provided the distinction is stable and understandable for those using them.

If every exception requires inventing a new status or leaving the system to complete the work, review the design. The process may need optional fields, rules by order type or an analysis stage before automating it.

When is it not advisable to develop a custom tool?

It is not advisable to start with development if you still do not know which stages exist, which data is reliable or who will be responsible for maintaining it. Nor is it advisable if a tool you already use covers the process without introducing significant duplication.

First define the objective and test a way of working that the team can follow. You will then be in a better position to decide whether you need to adapt an existing solution or build a specific tool.

Next decision

How do I know whether I need to improve my production control?

It is probably worth reviewing if you find it difficult to answer confidently where an order is, what is blocking it or who needs to act next. It is also worth reviewing if the team duplicates data, relies on messages to know the actual status or loses the history of changes and issues.

Start by describing a typical order from the moment it arrives until it is delivered. Note its stages, those responsible, decisions, exceptions and required data. This walkthrough will help you define the problem before choosing technology.

If you have already identified this process, you can explain your production control project through AVSISTEC's business applications. The next useful step is to review the objective, the actual scope and the rules that a tool would need to respect.