Production Tracking Software and MRP: A Practical Guide

Production tracking software ties every job on the shop floor to a numbered work order and shows you which station it sits at, who has it, and how long it has been waiting. MRP — material requirements planning — works backwards from those same work orders to answer a different question: which material, how many units, and by what date do I have to order it. They are not the same thing. Tracking records what happened; MRP plans what will. When a production system does only one of the two, the outcome is always identical: either the warehouse swells or the promised delivery date slips. There are three ways to put this in place — buy an off-the-shelf production tool, switch on the manufacturing module of the ERP you already run, or build a system around your own process. Below you will find the six data points worth collecting, the work order and routing skeleton, the net requirement maths behind a bill of materials, the three buying routes, and the five mistakes that sink these projects.

What production tracking software actually does

What this software produces is not reports; it is questions you can answer. “When does this order ship”, “how many hours did we stand still yesterday and why”, “what does this part really cost” all rest on the same data: how much time a job spent at each station. In a workshop run on spreadsheets those questions are not unanswered — they are answered by guesswork. That is the whole difference. Once the system settles, you get three concrete outputs: promised dates are based on capacity, scrap and downtime become countable, and when an operator leaves, the knowledge of how the job was done stays in the company.

Which data does it collect?

Before choosing any tool, decide which six data points you will capture; off-the-shelf software and custom builds alike are constructed on top of these:

• Work order — which product, how many, for which sales order, by which date. A job without a number cannot be tracked, and as long as verbally assigned work stays outside the system, no report will be correct.
• Operation and station — where the job sits in the routing. A single “in production” status is not enough; a bottleneck only becomes visible step by step.
• Time — the start and finish stamp of each operation. This is the only source of true cost, real capacity and any credible delivery estimate.
• Quantity and scrap — good units and scrapped units counted separately. Do not lump scrap into one number; ask for the reason too: machine setup, material, operator error.
• Downtime — how long the machine stood still and a coded reason (breakdown, waiting for material, die change, break). Uncoded downtime data never turns into an improvement.
• Traceability — which raw material lot went into which work order. In food, medical, automotive and defence work this is not a preference but a requirement.

Five of these six are already recorded somewhere in your workshop — in a notebook, on a whiteboard, or on the shift supervisor’s phone. The job of the software is not to invent new data; it is to collect what exists in one place and in one format.

What is MRP, and how does it differ from ERP?

MRP is the method that takes your production plan and spreads material requirements across time. It has three inputs: the bill of materials (which product needs how many of which component), the stock position, and lead times. It has exactly one output: how many units of each material must be ordered, and by which day at the latest. ERP is the roof above that — it unifies sales, purchasing, accounting and the warehouse in a single database, and MRP usually ships inside it as a module. If your company has not made the ERP decision yet, reading what an ERP is and what it does for companies first is the more sensible order.

The practical distinction: production tracking measures the past, MRP plans the future, and ERP connects both to the rest of the company. Install tracking alone and you will see exactly what you ordered too late — while continuing to order it too late.

Work orders and routings: the core of the system

Before selecting software you have to write your own production down in this skeleton. A routing defines which operations a product passes through and in what order; a work order is that routing executed for a specific quantity. Without four fields, no production software works:

• Operation sequence and station — which machine or bench performs each step. If two machines can do the same job, define them as alternatives; a routing bound to a single machine throws away the whole plan the day that machine breaks down.
• Standard time — setup time and per-unit run time kept separate. Adding them into one number makes capacity maths flatly wrong on small batches.
• Material consumption point — at which step of the routing the raw material is deducted. Deducting everything at the first step breaks your stock report; deducting everything at the last step breaks your cost report.
• Quality check step — inspection existing as an operation inside the routing. In systems that leave inspection outside, a rejected part still counts as “produced” and scrap figures are never right.

The threshold is this: once you are tracking more than 15-20 concurrent jobs, or production spreads over two shifts, the problem is not your team’s attention but the absence of a queue structure. The same threshold shows up on the warehouse side; we covered where basic stock control stops being enough in stock control software versus a custom build.

From bill of materials to net requirement: the core MRP calculation

The whole of MRP reduces to one sentence: subtract what is on hand and on order from the gross requirement, add back what is already reserved for other orders, and buy the remainder. If a component is a sub-assembly, the same calculation repeats one level down. The function below performs that explosion — these are the most-argued-about thirty lines in any production system:

type BomLine = { childId: string; qtyPer: number };
type Bom = Record<string, BomLine[]>;

interface StockRow {
  onHand: number; // physical quantity in the warehouse
  onOrder: number; // open purchase orders / in transit
  allocated: number; // reserved for other work orders
}

/**
 * Computes the NET quantities to buy or produce for a work order.
 * stock must be a working copy: the function reserves what it consumes so a
 * component appearing twice in the tree is not counted twice.
 */
function explodeRequirements(
  productId: string,
  quantity: number,
  bom: Bom,
  stock: Record<string, StockRow>,
  out: Record<string, number> = {},
): Record<string, number> {
  for (const line of bom[productId] ?? []) {
    const gross = line.qtyPer * quantity;
    const row = stock[line.childId] ?? { onHand: 0, onOrder: 0, allocated: 0 };
    const available = Math.max(0, row.onHand + row.onOrder - row.allocated);
    const net = Math.max(0, gross - available);

    // Reserve the part covered by stock; the remainder is the net requirement.
    row.allocated += gross - net;
    stock[line.childId] = row;
    if (net === 0) continue;

    out[line.childId] = (out[line.childId] ?? 0) + net;
    // Sub-assembly: explode its own tree for the quantity we are short of.
    explodeRequirements(line.childId, net, bom, stock, out);
  }
  return out;
}

The quantities this function returns are not enough on their own: every line also needs a “order by” date, found by counting the lead time backwards from the delivery date. Those two numbers — how many and by when — are the only real contribution a production system makes to purchasing. Everything else is reporting.

Who enters the data? The real risk on the floor

Most production software projects collapse for a non-technical reason: data entry became a burden on the operator. There are three routes on the floor, and usually all three are combined:

• Terminal entry with a barcode or QR code — the operator scans the work order, starts, finishes. The most common and most durable method. The critical detail: one transaction must not exceed two scans. An interface that walks through three screens gets filled in wholesale, and made up, at the end of the shift.
• Automatic capture from the machine — reading counts and downtime straight from a counter, PLC or IoT module. This is the most accurate data, but not every machine is ready for it; on older equipment the cost shifts to hardware.
• Shift supervisor entry — one person enters the whole shift in bulk. Easiest to set up, lowest data quality. Acceptable as a transition, not as the permanent answer.

If you already run a system for staff and shifts, the two must not overlap; we detailed where working-hour data belongs in time and attendance software (PDKS). Carrying production reports up to management is a separate job again — we covered the link between measurement and decision in business intelligence and reporting dashboards.

Off-the-shelf tool, ERP module, or custom software

None of the three routes is better than the others; the answer depends on how standard your production is:

• Off-the-shelf production tool — starts fast, runs on a subscription, arrives with industry templates. The right choice if you run classic batch production. Its limit: when your routing does not fit the tool’s data model, you end up changing the process to suit the software.
• The ERP manufacturing module — the option with the least integration pain, because stock, purchasing and accounting already live in the same place. If you have an ERP, this is the first place to look; the go-live cost usually comes not from licences but from writing correct bills of materials and routings.
• Custom software — the only realistic route if your production is genuinely specific: engineer-to-order, made-to-measure, complex quality records, customer-specific traceability. Not more expensive, differently expensive: no licences, but development and maintenance. We compared the decision criteria in custom software versus an off-the-shelf solution.

What you actually pay for

Comparing a single headline figure will mislead you; in these projects the budget always splits into four items:

• Software — a per-user monthly or annual subscription for a ready-made tool, or day-rate development for a custom build. We broke down how custom pricing is constructed in the cost of custom software.
• Shop-floor hardware — terminals or tablets, barcode scanners, label printers, and machine data collection modules where needed. Even in a small workshop this item can exceed the software.
• Data preparation — writing the bills of materials and the routings. The most underestimated item in the project and the number one cause of delay; nobody can do it for you.
• Training and parallel running — for the first month or two the old method and the new system run side by side. Projects that leave this out of the budget return to the old notebook at the first wrong report.

Five mistakes that sink the project

• The bill of materials does not match reality. If the recipe on paper differs from what is actually consumed at the bench, MRP generates the wrong purchase order on every run. Verify the trees of your ten best-selling products on the floor before go-live.
• Scrap and downtime reasons are not coded. Downtime without a reason only carries bad news; it produces no improvement. Start with five or six codes and refine over time.
• Planning as if capacity were infinite. A plan that assumes unlimited capacity says yes to every order, and then none of the promised dates hold. At minimum, the bottleneck station’s capacity has to enter the calculation.
• Everything goes live at once. Open tracking, MRP, quality, costing and maintenance in the same month and the team trusts none of them. The order is clear: work order tracking first, MRP once the data settles, costing last.
• The operator interface is designed for a desk. Gloves, dust, poor light, standing up — the interface on the floor should amount to three large buttons. This single decision determines data quality more than all the others combined.

Conclusion

Production tracking software does not improve production; it makes the work you already do visible and measurable, and you do the improving. Success therefore has nothing to do with the brand on the box and everything to do with three things: correctly written bills of materials and routings, data entry that does not burden the operator, and a phased go-live. If you run standard batch production, start with a ready-made tool or the module in your existing ERP; if you build to measure, work project by project, or promise your customers lot-level traceability, take a look at our corporate solutions service or request a quote with a note about your product range and daily work order volume.