Manufacturing Software: Work Orders, OEE, Traceability

What this covers, and what it does not

This page is about execution: what happens between the release of a work order and the completion of a finished item. Work orders and routes, terminals at the machine, downtime and scrap, OEE, bills of materials, lot traceability, subcontracted operations and shift calendars.

It is not about statutory accounting, which stays in the package the finance team already uses and is connected rather than replaced — see integrations. It is not a CAD or product data management system; drawings and revisions stay where the engineering team keeps them, and the manufacturing system references them. And it is not a demand forecasting product: it records what happened and what is in progress, which is what makes forecasting possible, but the forecast itself is a separate question.

Operation-level work orders

This is the central design decision, and everything else on the page depends on it. A work order is not one record with a status; it is a sequence of operations along a route, each of which is a record in its own right.

The route

A product family has a route: an ordered list of operations, each with a work centre or machine, a setup time, an ideal cycle time per piece and, where relevant, a quality check. Routes are not always linear. Two operations can run in parallel and rejoin. An operation can be sent to an outside supplier for plating or heat treatment and come back into the sequence. A failed inspection can branch into a rework loop that has its own operations and its own cost. A model that only supports a straight line forces those cases back onto paper, and paper is where visibility is lost.

What an operation record holds

Start time and finish time; the operator and the machine; the good quantity and the scrap quantity with a reason code per scrap entry; the material lots consumed; every pause with its own reason and duration. That is the complete raw material for cost, for OEE and for traceability. If any of it is missing, the corresponding number downstream becomes an estimate, and estimates are what plants already have.

The terminal at the machine

Data that is entered later is entered wrong, so entry has to happen where the work happens, and it has to be faster than writing it down. In practice that means a fixed screen or tablet at the work centre, badge or barcode identification rather than typed logins, a start action that is one scan and one tap, and reason codes as large buttons rather than a dropdown list. Free-text fields are kept to a minimum, because free text cannot be counted. The design constraint is an operator wearing gloves who has a machine waiting.

Dispatch and the queue

When an operation is completed, the next one in the route becomes available at its work centre. Each terminal therefore shows a live queue: what is waiting here, in what order, with what quantity and against which delivery date. That queue is also the honest answer to where an order is, and it is usually the first thing a plant manager notices they never had.

Downtime and scrap: the reason codes are the product

Both downtime and scrap are worthless as bare numbers. Four hours of stoppage is a fact nobody can act on; four hours of stoppage of which most was waiting for material is a decision. The value of the system is in the code list, not in the total.

What matters when designing that list:

Planned and unplanned stops are separated at the source. Setup, tool change and planned maintenance are not breakdowns, and merging them makes the availability figure meaningless.
The list is short enough to be used honestly. A screen with forty reasons produces one heavily used reason called Other. Ten to fifteen codes per work centre type is usually where accuracy and usefulness meet.
Scrap has a cause and a stage. The same defect discovered at the first operation and at final inspection cost very different amounts, because everything spent between the two is lost as well.
Rework is not scrap. A part that goes back through operations is a cost and a capacity consumer, not a loss of material. Counting it as scrap understates capacity use and overstates material loss at the same time.
Codes change, history does not. Reason codes are versioned so that last year's analysis still means what it meant when it was recorded.

OEE, and the ways it is usually got wrong

Overall Equipment Effectiveness is availability multiplied by performance multiplied by quality. The formula is standard; the difficulty is entirely in the inputs, which is why two plants can both report OEE and mean different things.

Component	Definition	Where it goes wrong
Availability	Run time divided by planned production time	Planned production time comes from the shift calendar, not from the clock; unmanned shifts and planned maintenance must be excluded consistently or the figure is not comparable week to week
Performance	Total count multiplied by ideal cycle time, divided by run time	Ideal cycle time has to be a real engineering figure per product and machine; a single plant-wide average produces a number that moves with the product mix rather than with performance
Quality	Good count divided by total count	Good count means first-pass good; counting reworked parts as good hides the cost of the rework and makes the quality figure flattering and useless

Two more rules keep the figure honest. OEE is calculated per machine and per shift and only then aggregated, because an average across dissimilar work centres tells you nothing about which one to fix. And micro-stops — the short stoppages nobody writes down — are the gap between a plant's reported figure and its real one; they are the main reason to connect machines directly once operator entry is established.

Bills of materials and recipes

A bill of materials is stored as parent and child rows with a quantity per unit, so an assembly can contain sub-assemblies to any depth. Around that core, the details that decide whether it survives contact with a real plant:

Versions with effective dates. Revisions are added, never overwritten. A work order produced in March has to keep the recipe it was actually made from, otherwise cost history and traceability both break.
The bill is copied onto the work order at release. A later revision changes what will be produced next, not what was produced last quarter.
Scrap allowance per line. Expected loss differs by material; a single percentage across the whole bill misstates consumption for every line it does not fit.
Alternative materials. A permitted substitute is part of the bill, with its own quantity, so a substitution is a recorded decision rather than an unexplained variance.
Units of measure with conversion. Purchased in sheets, consumed in square metres, costed per kilogram. The conversion belongs in the data, not in a spreadsheet someone maintains.
By-products and offcuts. Where material comes back as usable stock, the bill records it; otherwise yield analysis is wrong in a way that is hard to find later.

Raw material traceability

Traceability is not a report. It is a chain of records, and the chain either exists or it does not; there is no partial version that works when a customer calls.

The chain runs: supplier delivery recorded as a lot, with document reference and certificate where one exists → the lot consumed at the specific operation that consumed it, recorded by scanning at the terminal → the intermediate item carrying its own lot → the finished item carrying its lot or serial number → the dispatch document that sent it to a customer.

With that chain in place, two queries become possible, and they are the only two that matter. Forward: this supplier batch was faulty, which finished items contain it and where did they go. Backward: this customer complaint refers to this serial number, which material, which machine, which operator and which shift produced it. Both are questions plants answer today by searching paper for days, and both are the reason traceability is usually the module that pays for itself first in regulated or safety-critical work.

The discipline it demands is small but absolute: material is not issued without a lot reference. A system that allows an unreferenced issue has a chain with a hole in it, and a chain with a hole is not a chain.

Shifts, and why they are not a cosmetic setting

The shift calendar defines planned production time, and planned production time is the denominator of availability. Get the calendar wrong and every efficiency figure in the plant is wrong with it. So shifts are modelled properly: patterns per work centre, breaks, planned maintenance windows, public holidays and overtime, with the calendar able to differ between lines running different patterns.

Two consequences follow. Performance is compared shift to shift, which is where real differences in method and training show up and where a plant-level average hides them. And handover becomes a record: what was left running, what stopped and why, what the next shift is taking over. Handover written down is one of the cheapest improvements available in a plant that currently does it verbally.

Where a packaged MRP stops

Packaged MRP and ERP systems do materials planning, purchasing and costing well, and where they fit we integrate with them rather than replace them. These are the specific points at which plants come to us:

Requirement	Typical packaged MRP	Custom manufacturing system
Route shape	Linear sequences; parallel steps, rework loops and subcontracted operations sit outside the model	Routes with parallel branches, rework loops and outside operations that leave and re-enter the sequence
Scrap	A single loss quantity per order	Reason code and stage per scrap entry, separated from rework, analysable by machine, shift and material lot
Costing basis	Standard rates applied to planned quantities	Actual recorded operator time, machine time and consumed lots, compared against standard as a variance
Data entry point	An office screen, filled in after the fact from notes	A terminal at the work centre, entered as the event happens, with scan-based identification
Traceability depth	Lot recorded at goods-in and at dispatch, with a gap in between	Lot recorded at the operation that consumed it, so the chain is unbroken through sub-assemblies
Subcontracted operations	Handled as a purchase, invisible as a production step	An operation in the route with dispatch, return, yield loss and its own elapsed time

When you should not build this

Single-operation production. If a product is made in one step on one machine, operation-level tracking adds records without adding answers. A simple output count is enough.
Routes that change with every order. True one-off job shops where nothing repeats get less from routing and more from project tracking; that pattern is on project tracking.
Nobody will maintain the master data. Cycle times, routes and bills of materials have to be kept current by someone in the plant. Without that owner the system reports precise numbers derived from stale standards, which is worse than no numbers.
The package genuinely fits. If your routes are linear, your scrap is low and uniform and standard costing is close enough, keep the package. We will say so.

How a plant starts

Model one product family

Its route, work centres, cycle times, bill of materials and quality checks. One family, not the whole catalogue — it is enough to expose every structural question the rest will raise.
Agree the reason codes

Downtime and scrap codes are written with the foremen who will use them, because a list produced in an office is a list filled in as Other. This step is short and it determines whether the data is worth anything.
One line live, in parallel

Terminals on a single line, running alongside the existing paper or spreadsheet method. The two are compared until they agree, then the manual method is retired on that line. Prototype in 2–4 weeks; first module in production in 2–4 weeks at $3,000–6,000.
Extend across the plant, then connect

Remaining lines, then the accounting bridge for stock and cost postings, then direct machine connection where micro-stops matter. A multi-department system is $8,000–15,000 over 4–8 weeks; the bands are on pricing.

Elevatora İMALAT, our lift-component manufacturing system, was built on this pattern and runs in production: work order creation and status tracking, production planning, stock movements, shipment records and quality records. It is described on cases. The general build approach is on custom software.

Frequently Asked Questions

What does operation-level work order tracking actually mean?

It means the unit of record is the operation, not the order. An order to produce a batch of parts becomes a sequence of operations along a route, for example cutting, bending, welding, coating and assembly, and each one is started and finished separately at the machine where it happens. Because each operation carries its own start time, finish time, operator, machine, good quantity and scrap quantity, you can answer which step a batch is waiting at, which machine is the constraint, and what an operation actually cost. An order-level record cannot answer any of those questions.

Can we calculate OEE without connecting to the machines?

Yes. OEE needs four inputs: planned production time, stop time with reasons, total quantity produced and good quantity. All four can come from operators entering start, stop, reason and count at a terminal. Machine connection through Modbus, OPC UA or MQTT improves the accuracy of the count and the stop detection, and removes the argument about whether a stop was recorded, but it is an upgrade rather than a precondition. Most plants should start with operator entry, get the reason codes right, and connect machines afterwards.

How are multi-level bills of materials and revisions handled?

A bill of materials is stored as parent and child rows with a quantity per unit, so an assembly can contain sub-assemblies to any depth. Each version is kept with an effective date rather than being overwritten, because a work order produced last quarter has to keep the recipe it was actually made from. Alternative materials, scrap allowance per line and units of measure with conversion are part of the line rather than notes attached to it. When a work order is released, the bill is copied onto it, so a later revision does not silently rewrite production history.

What does raw material traceability require from us?

Three things at goods-in, and one discipline afterwards. At goods-in, each delivery is recorded as a lot with its supplier, its document reference and its certificate where one exists. During production, the operator records which lot was consumed at the operation that consumed it, usually by scanning a label. On completion, the output carries its own lot or serial number linked to the inputs. The discipline is that material is not issued without a lot reference. With that in place, tracing forward from a supplier batch to every finished item, or backward from a customer complaint to the batch, is a query rather than a search through paper.

Where does a packaged MRP stop being enough?

At four points, in our experience. Routes that are not linear, meaning parallel operations, rework loops and operations sent to a subcontractor and returned. Scrap that needs a cause rather than a single loss field, because a scrap number without a reason cannot be acted on. Costing that has to use actual operator and machine time instead of a standard rate. And shop-floor data entry, where a package designed for an office keyboard is used by someone wearing gloves and is therefore filled in later from memory, which makes every downstream number an estimate.

Does the rollout stop production?

The rollout is phased precisely so it does not have to. One line or one product family runs first, in parallel with the existing paper or spreadsheet method, and the two are compared until the numbers agree. Only then is the manual method retired on that line, and only then does the next line start. This is slower than a single cutover date and it is the reason a plant does not have to bet a production week on a launch.

The shop floor writes the numbers, not the office at the end of the week