Work order and job structure
Work order and job structure is the way production work is split into records: work orders, jobs and operations.
Scheduling, shop floor terminals, costing and traceability all read from this structure, so it shapes most of the screens built after it.
Key facts
- One production record model uses work orders, jobs and operations; products may combine or name these levels differently.
- A terminal cannot show partial completion if quantity sits at the wrong level.
- Discrete production completes in counts. Batch production completes in measurements, with variable yield.
- Cost by operation requires appropriately detailed inputs, such as operator entries, machine events or integrated time records.
- Products name these levels differently. Some use jobs and operations and have no work orders at all.
What it covers
| Level | Answers | Owner |
|---|---|---|
| Work order | What, how much, by when, for which demand | Planner |
| Job | Which unit of that work is running, and where | Supervisor |
| Operation | Which step, at which resource, with which inputs | Operator |
Where quantity, status and consumption are recorded decides what every later screen can show.
The names vary between products and industries. What matters for design is the number of levels and what each level owns, whatever the product calls them.
The table is an example, not a required hierarchy or fixed division of responsibility. Redbrix validates levels, quantities and ownership against the production process.
Who uses it
Planners create and release orders, supervisors follow jobs through the shift, and operators record each operation. Accountants read the same structure later as cost.
| Role | Level they work on | What they need from it |
|---|---|---|
| Planner | Work order | Quantities, dates, demand behind each order |
| Supervisor | Job | Which jobs run where, which are blocked or late |
| Operator | Operation | The current step, its inputs and what to record |
| Accountant | All levels | Postings for labour, machine time, scrap and material |
What makes it hard to design
Discrete and batch differ. In discrete production, countable units move through a routing, completion is a count and a job splits cleanly. In batch production, material transforms over time in a vessel or line, completion is often a measurement, yield varies and output is known only when the step ends. Queues fit discrete work. Vessel and line state views fit batch work.
Effects on the operator screen.
- Status held only at work order level hides a blocked step behind an order marked in progress
- Consumption recorded against the order breaks the link between an input lot and the step that used it
- Without partial completion, an interrupted shift ends in a false completion or in no record
Labour, machine time, scrap and material are posted against this structure. If opening and closing operations is slow, postings arrive in bulk at shift end and the detail exists only on paper.
Trade-offs
- Operation-level records support more detailed costing and traceability when inputs and allocation rules are reliable. Redbrix compares manual entry with machine or integrated capture. A coarser model reduces detail and may reduce capture effort.
Common mistakes
- A system designed for discrete production extended to batch. The mismatch appears as a long list of small requests: variable yield, partial transfers between vessels, steps with a duration range.
- Status only at the top level. A blocked step is invisible behind an order marked in progress.
- Consumption against the order. The trace loses which step used which lot.
- Screens drawn before the levels are agreed. Quantity ends up at the wrong level and partial completion cannot be shown.
Where Redbrix has worked on this