How production management software works

The core idea: one shared document and stock engine

To understand how production management software works, start with the one design decision everything else rests on: every transaction is a document, and every document lives on a single shared engine. A work order, a material reservation, a material issue, a WIP booking at an operation, a finished-goods transfer — none of these is a stray row in a spreadsheet. Each is a linked document that references the ones before and after it. That is why the numbers reconcile and why a finished lot can be traced back to the exact material and operations that made it.

In Fast Production Software that engine is literally shared with the rest of the suite. Stock movements — reserve, issue, WIP and transfer — post to the same store ledger the warehouse uses, and commercial documents such as the work order sit on the same document tables as every order and invoice in the wider system. There is no nightly export and no CSV handed from production to inventory: production and inventory are reading and writing the same rows. When people say a real manufacturing execution system (MES) has "one source of truth", this is what they mean — not a slogan, but a schema.

The rest of this guide walks that chain one document at a time. If you want the business-level narrative of the same journey — why each stage exists and what it costs to skip it — read the production management process guide; this page deliberately stays under the hood. For the wider definition, start with what production management software is. Compressed, the six documents look like this:

Step 1 — a released BOM and route sheet become the source of truth

Nothing on the floor can start until the engineering definition exists and is released. That definition has three parts held in the platform's BOM/BOR family: a header for the manufactured item and its revision, the material positions — the child items, quantity-per and scrap or yield allowance at each level — and the resources, meaning the machines, labour, tools and operations each level consumes. Alongside it sits the route sheet: the ordered sequence of operations, each on a work center, each with a standard time. These are not small tables in a real plant — in one live reference deployment the position table runs to over ten thousand rows and the operation-time table past forty thousand, which is what "the definition of everything we make" actually looks like at scale.

The mechanical detail that matters is status. A BOM is born at draft and is invisible to production until it is moved to released status. Only a released BOM and process list can be exploded by a work order, and when a released definition has to change it goes through a controlled engineering change so the revised version becomes active while superseded revisions stay traceable — no silent edits to something the floor is already building against. Get this right and every downstream document inherits a definition it can trust. See BOM & Bill of Resources and Process & Route Sheets.

Step 2 — the work order becomes an executable job

A released BOM is a design; a work order is an executable job. This is the document that says "make this quantity of this item by this date", and it is a first-class commercial document on the shared engine — an internal work order made to stock, or a sales work order raised against a specific customer order so a make-to-order job stays tied to its demand. It can be entered by hand or generated straight from the plan, which is how planning and execution become one continuous chain rather than two disconnected steps.

Under the hood the work order is a small state machine driven by status codes: it starts at draft, moves to released when it is ready to run, sits in progress while the floor works it, and ends at completed or closed — with cancellation and short-close paths for jobs that stop early. Cancellations even echo through the downstream stock documents with a cancel prefix so the record stays clean. Along the way the order prints job cards as shop-floor packets, carries any work-order specifications, and tracks consumption against BOM so actual usage can be compared with the standard. See Work Orders & Job Cards.

Step 3 — reserve, then issue: how stock is committed

Moving material onto a work order is a deliberate two-step discipline, and it is the key to a system whose stock figures you can trust. First the work order's released BOM is exploded into a production material requisition — the shopping list of what this job needs. Then two distinct documents do two distinct things.

Reserve earmarks stock against the work order so it cannot be double-committed to another order. Crucially, reserving does not reduce stock — the material is still physically in stores, and a reservation is a promise, not a movement. This earmark is often created upstream by MRP, and production draws against it. Issue is the real stock deduction: material leaves store stock and is charged to the work order via an issue slip. A wrong issue can be reversed, unused material returns through the same slip, and both reserve and issue can be cancelled cleanly.

This is the single most important thing to internalise about how the system works: on-hand stock only truly changes on the two highlighted rows. Align any customization, integration or reconciliation to those two commit points and every discrepancy will trace to an issue or a transfer. See Material Issue & WIP.

Step 4 — booking WIP as the work happens

Once material is issued, the work order runs down its route, and the software's job at this stage is simply to record what happens at each operation — accurately, and at the moment it happens. The output of every operation is booked into three buckets that stay separate for a reason: good WIP, the quantity that passed and moves forward; reject or not-OK WIP, the quantity that failed at that operation; and process scrap, material removed from the route entirely. Each is its own posting on the store ledger, so good and reject are captured where they occur rather than lumped into a single end-of-line total.

The mechanism that makes this trustworthy is barcode process-status booking. Instead of an operator filling in a form at the end of a shift, the status of each operation is scanned at the machine as the work is done. Because the booking happens at source, the reject is tied to the exact operation, work center and work order that produced it — and defects can be mapped to their work center. That precision is not a nicety; it is the raw material for every meaningful rejection-reduction effort, and it only exists if capture happens on the floor rather than in an office afterwards. Production slips then move work-in-progress from one operation to the next, with an in-process inspection branch that can hand a step off to quality before the route continues. See Process & Route Sheets.

Step 5 — finished-goods transfer posts stock back

When the route is complete, the good output is transferred to finished-goods stock. Mechanically this is two linked postings — a manufacture event that creates the finished goods, and a transfer that puts them on-hand — and it is the second true stock-commit point. From here finished goods are visible in inventory for dispatch and finished-goods inspection. WIP bookings tracked quantity all the way down the route, but they never touched finished-goods stock; only this transfer does, which is why a plant can watch a job progress operation by operation without its inventory numbers moving until material actually leaves or finished goods actually arrive.

The transfer can be lot-tracked, so each batch keeps its own identity for traceability; semi-finished sub-assemblies transfer the same way to feed the next-level assembly; and over-production is handled as an explicit excess transfer rather than a fudge. As the transfer posts, the work order moves to completed or closed. Anything rejected on the line is captured against the part, the child part and the work order, and enters a controlled rework loop rather than being quietly written off — the mechanics of which are covered in FG, Rejection & Rework.

Step 6 — data becomes dashboards, and Dhruv AI

Here is the payoff of the whole design. Because every reservation, issue, WIP booking and transfer is already a document captured at source, reporting is a read over real data — not a separate data-entry exercise bolted on at month-end. Work-order follow-up and live job-card status come straight from the work-order and WIP documents; process-cost and rejection MIS come from the operation and WIP records; and OEE is derived from run time, output and reject measured against the standard operation times the route already carries. Nobody re-keys anything for a dashboard to exist, which is exactly why the dashboards can be trusted.

On top of that read layer sits Dhruv AI. It adds a production role dashboard, clusters free-text rejection and defect remarks into named recurring themes by work center or item — turning a pile of one-line reject notes into "here are your three biggest recurring causes" — and answers plain-English questions through a safe, read-only query sandbox, so a supervisor can ask about last week's rejection or open work orders without writing a report. It reads the same documents the rest of the system does; it never writes. For the wider return this visibility unlocks, see the benefits of production management software.

How it connects to planning, inventory and quality

Everything above works because production is not an island — it is the execution hinge in a longer chain, and it is at its best when it is natively connected to the modules on either side. The connection is not an interface; it is a shared ledger.

Upstream, planning decides what to make. Fast Planning / MRP turns demand into a plan, generates the work orders directly, and creates the reservation earmarks production issues against — so plan → work order → issue is one continuous chain. Alongside, inventory holds and receives the material. Because issue and finished-goods transfer post to the same stock ledger the warehouse uses, raw-material depletion and finished-goods receipt are visible to Fast Inventory the instant they happen — no double entry, no lag, no export. Downstream, quality inspects what is made, with in-process and finished-goods inspection branching into Fast Quality and line rejections and rework decisions flowing into its non-conformance handling.

That shared-ledger design is also the honest answer to the MES-versus-ERP question: rather than integrating two separate systems by file transfer, Fast Production is the execution tier of the same platform that carries the commercial side, so the two share one item, stock and document foundation. Under the hood it is an ASP.NET (Web Forms) application on SQL Server, built by Improsys in Pune — but the reason the numbers reconcile is not the framework; it is that every step is a linked document on one engine. To move from theory to your own shop floor, book a demo.

Frequently asked questions