The material left the store on Monday morning. Nothing has yet been received into finished goods. Somewhere between those two facts is a job, and the only reliable way to find out how far it has got is to walk out and ask.
That walk is the subject of this page. Not whether the job should have started, which is a question answered before release, but what happens to the answer afterwards. A released work order that cannot be located is a gap in the record, and it is a gap a manufacturing ERP needs to close.
The moment material leaves the store
Issue is where visibility is usually lost. Up to that point everything is tidy: the material is in stock, in a location, countable. If a system records the issue but does not track what happens during production, visibility stops at issue and resumes only when finished goods are received.
What happens in between is then invisible by design. The stock report is accurate and useless. Material has gone somewhere, output has not arrived, and the difference is real value sitting on the floor that the system has no way to describe. That is the problem work in progress exists to solve, and it is worth being precise about what it means.
What work in progress actually means
Operationally, work in progress is material that has entered production but has not yet been received as finished goods. It is a quantity attached to a job and a stage, not merely a figure reconstructed at month end.
The distinction matters more than it sounds. Treated as an accounting residual, WIP is something you work out later by subtraction. Treated as an operational position, it is something you can look at: this quantity, on this job, at this point in the process. Only the second version answers the question somebody actually asked.
It also puts the material and the job in the same place. Once WIP is tracked against the work order it belongs to, "where is the material" and "where is the job" stop being two separate enquiries with two different answers.
Stages are how a job becomes knowable
A percentage alone does not tell you where a job is. Its current stage does. Fabrication work is at cutting, or machining, or assembly; a run is between two defined operations. That sequence of stages already exists, because it is how the item is made, and how it is designed is a subject of its own. What matters here is that it gives execution somewhere to be recorded against.
With the sequence defined, progress becomes a series of small factual statements. This stage is complete. The job has moved to the next one. Each completion recorded as work progresses updates the job's recorded progress. Those recorded completions give the system the basis for showing the job's current stage.
Nothing about that is complicated. What makes it useful is that it holds for every open job at once, so the position of the whole floor is a query rather than a morning of asking.
How far through is it, really
Percentage complete is the figure everyone wants and the one most likely to be misread. Before trusting it, two things need to be clear, and they are worth asking about explicitly.
What does the percentage represent? Progress through the sequence of stages is one honest answer. Proportion of the quantity finished is another. Elapsed time against expected time is a third. They are different measurements that will disagree with each other on the same job, and each is legitimate for a different question.
What event moves it? A percentage that advances when a stage is recorded complete is telling you about recorded progress. If nothing has been recorded since Tuesday, the figure is Tuesday's, however current the screen looks.
A job showing sixty per cent is genuinely informative once both answers are known and useless while they are not. This is worth settling with a vendor, not assuming, because two systems can show the same number and mean different things by it.
The jobs that are late
Execution visibility becomes most useful when a job is no longer where it was expected to be.
When scheduled dates sit alongside execution status, the system can show which work orders are ahead or behind schedule and by how many days. Overdue work orders can be flagged rather than discovered only when somebody asks about delivery.
What has to be recorded for any of this to be true
Here is the part that vendor demonstrations tend to skip, and it decides whether everything above is real in your plant or only real in the demonstration.
An ERP can only show execution status accurately when the relevant execution events reach the system: material issued to the job, consumption against it, and stage completions as work progresses. Do not assume how that happens. The important questions are what event updates the record, how it is captured, and how quickly the record reflects the physical work.
So the questions to settle early are practical ones. Who is responsible for each event? What specifically changes the status of a job? How is that event recorded? How soon after the physical work does the record catch up? A system where completions are recorded promptly can tell you where the floor is. The same system with late recording can only tell you where the floor was.
This is not a reason to expect less of a system. It is a reason to be clear that execution visibility is a working practice supported by software, not a property the software has by itself.
Where execution data goes next
What is recorded during execution does not stay in execution. Material issued and time spent against a job become the actual side of what it cost, which is a subject with its own requirements and is covered in work-order costing and variance. Rejection and rework recorded at a stage change what completion means there, and belong to rejection and rework tracking. An operation performed outside the plant still has to report back into the same work order, which is the subject of job work and subcontracting. And the material moving through all of this carries an identity that has to survive the movement, which is covered in batch and lot traceability. The routing and the expected times the job is running against are set out in capacity, routing and process time.
The WIP position can also be valued rather than estimated at period end, though what that figure means and how it is built is a costing question, not an execution one.
What to make an ERP vendor demonstrate
Execution demonstrates well and proves little, because a prepared job always moves smoothly. The wider method for running an evaluation is set out in the ERP selection and evaluation guide; the sequence below is the one specific to execution.
- Take a released work order and issue material against it. Then find that material.
- Show where that job now sits, and show the same for every other open job in one place.
- Post a stage completion. Watch exactly what changes, and what does not.
- Ask what percentage complete represents on this system, and what event moves it.
- Show which open work orders are behind their scheduled date, without anyone compiling it.
- Show the time recorded against a job.
- Then the question that matters most: what event has to be recorded, how is it captured, and how quickly does it have to reach the system for all of this to stay accurate?
That last one is not a feature question and no demonstration answers it on its own. Ask it anyway. A useful answer should explain exactly what creates each record and how quickly it reflects physical work.
How exactllyERP tracks work-order execution
In exactllyERP, material issued to the shop floor is tracked as work in progress at every routing stage, so stage-wise WIP can be followed from issue through each step instead of disappearing between store and finished goods.
Stage completions are updated as work progresses. The current stage, the percentage complete and where each open work order sits in the process are visible without manual follow-up. Across open work orders, WIP quantity, current stage and time spent are visible in real time. Material consumption is recorded as it happens, not reconciled at month end, and production labour time can be captured against the job.
Scheduled dates show which jobs are running ahead or behind and by how many days, and overdue work orders are flagged automatically. Execution is recorded against the routing the item already follows, and rejection or rework can be captured at the stage where it occurs.
The broader manufacturing workflow this sits inside is described on the manufacturing ERP page, and the functional scope across procurement, inventory, production and finance on the features page. What happens before release, including whether a job should start at all, is covered in production planning and material requirement.
This page describes capability, not configuration. How many stages a job should be broken into, how each completion is recorded, and how promptly it is recorded are implementation decisions that depend on the plant and on how closely the floor needs to be followed. They are worth settling deliberately, because together they decide how much the recorded status is worth.
Common questions
What does work in progress mean in a manufacturing ERP?
Work in progress is material that has left the store but has not yet come back as finished goods. It is not a leftover figure at month end; it is a real quantity sitting somewhere in the production process at this moment. Treating it that way is what lets a system answer where a job is, because the material and the job are in the same place. Where WIP is not tracked, material simply disappears from stock at issue and reappears at finished-goods receipt, and everything in between has to be found by asking people.
How can you know what stage a work order is at?
By recording completions against the stages the job passes through, so the last completed stage tells you where the job now sits. That depends on two things being true: the sequence of stages has to be defined before the job runs, and each completion has to be recorded as work progresses. Given both, the current stage of every open work order is answerable from the system, not from a walk through the plant.
What has to be recorded for shop-floor status to stay accurate?
At minimum, the system needs the material issued to the job, the consumption against it, and each stage completion as work progresses. The important point is not to assume the capture method. What matters is that each event reaches the ERP accurately and promptly. It is worth deciding early how each event is recorded, who owns its accuracy, and how soon after the physical work the update appears, because status can only be as current as the underlying records.
What does percentage complete actually tell you?
Less than people assume, unless two things are clear: what the figure represents, and what event moves it. A percentage that advances when a stage is posted complete is a statement about progress through the process, not about how much of the quantity is finished or how much time is left. Both readings are legitimate and they answer different questions. The number is useful once everybody looking at it agrees which one it is, and misleading while they do not.
How can overdue work orders be identified?
By holding scheduled dates together with execution status, so the system can show which work orders are ahead or behind schedule and flag overdue work orders. The practical value is that lateness surfaces before somebody asks about a delivery, which is usually the point at which it becomes expensive.
How does exactllyERP track work-order execution?
Material issued to the shop floor is tracked as work in progress at every routing stage, so stage-wise WIP can be followed from issue through each step. Stage completions are updated as work progresses, and the current stage, percentage complete and position of every open work order are visible without manual follow-up. Across open work orders, WIP quantity, current stage and time spent are available together. Scheduled dates show which jobs are ahead or behind, and overdue work orders are flagged automatically. Material consumption is recorded as it happens, not reconciled at month end.
Where to start
Think of the job that went quiet last month. The one where somebody eventually walked out to find it, and it turned out to have been sitting at the same stage for a week without anyone noticing.
Ask every system you are evaluating what it would have shown about that job on each of those days, and what would have had to be recorded for that to be true. If exactllyERP is on your shortlist, bring the same job to the demonstration.