Production Work Order Data Model: Header, Routing, BOM and Status

Key takeaways

• A production work order (also called a manufacturing order, production order or job) authorises making a quantity of one part by a date. It is not a maintenance work order.
• The data model has four layers: the order header, the operations copied from the routing, the material lines copied from the BOM, and the transactions recorded while it runs.
• The field that most models get wrong is ideal cycle time per operation. Without it you cannot find the bottleneck or score the run.
• Book good and scrap quantities per operation, with a reason code, or you will never know where the parts were lost.
• The ERP owns the plan, the shop floor systems own what really happened, and actuals must flow back so the next plan is honest.

What a production work order is (and what it is not)

A production work order is an instruction to make a stated quantity of one item, to one revision, by one date. It carries its own copy of the routing and the bill of materials, so changes to the master data do not rewrite orders already on the floor.

Different systems use different names: manufacturing order, production order, shop order or job. The structure below applies to all of them.

A maintenance work order is a different object. It asks a technician to inspect or repair an asset, and it links to a machine, not to a part number or a customer order.

If you came here for corrective, preventive or inspection orders, read work order types explained. This page covers only the production side.

The order header: fields and meaning

The header holds one row per order. It answers what, how many, by when and for whom.

Keep qty_completed and qty_scrapped as derived totals of the transactions, not as numbers someone types. Typed totals drift away from the records within weeks.

Status lifecycle and what triggers each state

A clean lifecycle has seven states. Each one should be triggered by a specific event, so the status always means the same thing.

Two rules keep the lifecycle honest. No bookings before Released, and no bookings after Closed.

On hold should always carry a hold reason and a timestamp. Otherwise a late order and a blocked order look identical in every report.

Operations: the routing inside the order

The routing lists the steps and where they happen. When the order is created, the routing is copied into order operations, one row per step.

For the difference between the two master data structures, see BOM vs routing.

The distinction between ideal cycle time and standard run time matters. Many routings carry a standard padded with allowances, which is fine for costing but useless as a speed target.

Store both if you need both. Our guide to ideal cycle time explains how to set the fast one.

Material lines: the BOM inside the order

The bill of materials is copied into order components, one row per material. Each line can point to the operation that consumes it.

Backflush vs manual issue

Manual issue means someone picks the material and books it to the order before or during the run. It is accurate but costs a transaction every time.

Backflush means the system deducts qty_per × reported quantity when an operation reports output. It is cheap, but scrapped parts still consumed material, so the stock goes wrong if scrap is not booked at the right operation.

Lot tracking

For lot-tracked components, record which component lot went into which output lot. That link is your genealogy when a customer complaint arrives.

Execution records: what happens while it runs

The header, operations and components are the plan. The transaction records are the truth, and every report should be built from them.

Note that a downtime event belongs to the machine first and the order second. A machine can stop with no order on it, and that time still needs a reason.

Keep the reason lists short and specific. Our guide to downtime reason code design shows how to build one.

How the entities link

In words: one item has one or more routings and BOMs. One work order makes one item and copies one routing into many order operations and one BOM into many order components.

Each operation runs on one work center and collects many quantity reports, scrap records, labour bookings and events. Downtime events link to the work center and, when a job was running, to the order and operation.

The composite key order_no + op_no is the spine of the model. Almost every question about a job ("where did we lose the time?") is answered by grouping on it.

Worked example: planned hours, bottleneck and per-order OEE

Order WO-24017 asks for 1,200 pcs of bracket BRK-220 rev C. The routing has three operations.

1. Planned hours per operation

• Operation 10: 1,200 × 42 s = 50,400 s = 840 min = 14.0 h, plus 0.75 h setup = 14.75 h.
• Operation 20: 1,200 × 55 s = 66,000 s = 1,100 min = 18.33 h, plus 1.0 h setup = 19.33 h.
• Operation 30: 1,200 × 18 s = 21,600 s = 360 min = 6.0 h, plus 0.25 h setup = 6.25 h.

2. Find the bottleneck

Operation 20 has the longest cycle, so it is the bottleneck. At 55 s per part it can deliver at most 3,600 ÷ 55 = 65.5 parts per hour, however fast turning runs.

If operations overlap, milling sets the finish date; if the whole lot moves at once, every operation adds its full time. See bottleneck analysis for the wider method.

3. Book the actuals

The transaction records for the order show the following. Operation 10 scrapped 12 parts, so 1,188 reached milling.

4. Score the operation

• Availability = 1,150 ÷ 1,320 = 87.1%
• Performance = 1,188 × 55 s = 65,340 s = 1,089 min; 1,089 ÷ 1,150 = 94.7%
• Quality = 1,170 ÷ 1,188 = 98.5%
• OEE = 87.1% × 94.7% × 98.5% = 81.3%

Check it in one step: 1,170 good × 55 s = 64,350 s = 1,072.5 min, and 1,072.5 ÷ 1,320 = 81.25%, which rounds to 81.3%. The method is the same as in our OEE calculation guide, just scoped to one order and one operation.

Efficiency against the routing standard, here equal to the ideal cycle, tells a similar story. Standard minutes earned are 60 setup + 1,089 run = 1,149, and 1,149 ÷ 1,320 = 87.0% (see production efficiency for why the two numbers differ).

5. Close the order

Operation 30 scrapped 2 more, so the order completes 1,168 good and 32 scrapped (12 + 18 + 2). Yield against the order is 1,168 ÷ 1,200 = 97.3%.

The order is 32 short. Because scrap was booked per operation with a reason, the planner knows 18 of the 32 came from oversize bores at milling, and can add a scrap factor or fix the process before the next order.

Where the data lives: ERP, MES and OEE system

No single system owns the whole model in most plants. The split below is the common pattern, and it works when each field has exactly one owner.

Our pages on the manufacturing execution system and MES vs ERP cover the boundary in more depth.

What should flow down

• order_no, item_no and item_rev, so every machine record is tied to the right part
• qty_ordered and the operation list, so the floor knows what to run where
• ideal_cycle_time per operation and work center, so each run is scored against the right target
• priority and due date, so the sequence on the floor matches the plan

What should flow back up

• good and scrap quantities per operation, with scrap reasons
• actual setup and run minutes, and labour booked
• downtime minutes by reason, so capacity plans stop assuming a perfect machine
• material consumed and lots used
• status changes: In progress, On hold with reason, Completed

If actuals never flow back, nobody sees that the routing standard is wrong. In the example, milling was planned at 19.33 h and really took 22.0 h.

Six mistakes in production work order data

1. No ideal cycle time on the routing

Without it, performance cannot be calculated and the bottleneck has to be guessed. A padded standard hides slow running inside "normal".

2. Scrap booked only at the end

If scrap is booked as one number at order close, you know how many were lost but not where. Book it per operation with a reason, as in step 5 of the example.

3. Setup and run time mixed together

Setup is per order and run time is per part. Mixing them breaks planned hours for every order size except the one the standard was built on.

4. Downtime stored only against the order

Stops between orders then disappear. Store downtime against the work center and link the order when one was running.

5. Revision not frozen on the order

If the order points to the live BOM or routing instead of a copy, an engineering change can rewrite a job that is half finished.

6. Manual totals instead of transactions

Typed totals disagree with the records and nobody knows which is right. Derive qty_completed and qty_scrapped from the scrap and quantity reports.

For the lot side of the order, with supplier lots, lot status and genealogy, see our lot traceability data model.

How Fabrico helps

Fabrico does not create, plan or schedule production orders. Your ERP keeps that job.

Fabrico measures what happens on the machine while an order runs: OEE, downtime, short stops and cycle times, captured through PLC connections, IoT sensors and AI cameras.

Order data such as the product and its ideal cycle time can come in from your ERP, so each run is scored against the right target. The AI assistant answers questions about a machine's losses in plain language.

On the maintenance side, Fabrico is a full CMMS: your team creates maintenance work orders, runs preventive plans and tracks spare parts consumed per work order, from web or mobile apps.

Want to see how your orders really run on the bottleneck? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.