Everybody on the floor knows the standard time is wrong. The system has no way to hear it.
The routing says forty minutes. It has said forty minutes since somebody typed it in, and the last eleven times the job ran it took nearer fifty-five. The supervisor knows. The operator knows. The planner plans in forty, the promise to the customer is built on forty, and the variance shows up at the end of the month as a cost nobody can trace to a cause, because the thing that would explain it, where the extra fifteen minutes went, and to what, was never written anywhere a system could read.
What you get with work orders
The number the system plans with finally tracks the day the floor actually had, and when a job runs long, where the time went stops being a mystery. Underneath that:
Operations live on the bill of materials and point at a work centre, so confirming a manufacturing order produces its work orders instead of requiring them, each with its own worksheet sitting on the step, not in a binder. Cycle time can be a duration a person maintains or one that learns from recent completed work, so the standard follows the shop. Expected duration is built from what actually moves it, the work centre's capacity for that product, its setup and cleanup, its efficiency, and a job can shift to an alternative centre that recalculates against its own numbers. And every logged interval gets a reason: material, breakdown, setup, speed, defect, yield or productive time, rolled into productivity loss and OEE over the month. The lost fifteen minutes stops being a variance and becomes a category.
All of it is native Odoo Community, nothing to add, no extra fee per user, running on the deployment you own, with no tier above it holding the real version. (One thing genuinely is not here, and it is what people ask first: the dedicated shop-floor tablet is an Enterprise module, on Community, operators run work orders and log time through the standard screens. The FAQ covers what that means; the model, the states, the time logs and the OEE reporting are all Community.)
What this is not: a scheduler. Capacity, efficiency, calendars, alternatives and dependencies are all modelled, and the planner respects them, but nothing here does finite-capacity scheduling or advanced planning. It will not solve the sequence, and it will not tell you which of two late jobs to run first.
What is the difference between a manufacturing order and a work order?
A manufacturing order is the whole run, what is being made, in what quantity, from which components. A work order is one operation within that run, performed at one work centre: cut, weld, assemble, test. The operations themselves are normally defined once on the bill of materials, in sequence, each pointing at the work centre that performs it, and confirming a manufacturing order against that bill of materials is what generates the individual work orders. The distinction is what makes shop-floor time measurable at all: the manufacturing order tells you a run took a day, and the work orders tell you which operation the day went into. A system that models only the manufacturing order can cost a run but cannot tell you where it slowed down.
What is a work centre, and what does it need to hold to be useful?
A work centre is the resource that actually performs an operation, a machine, a bench, a cell, sometimes a person. Modelling it as a name and an hourly rate is the common shortcut, and it is where duration estimates go wrong. To be useful for planning it also needs a working calendar, so availability follows real shift patterns rather than a flat twenty-four hours; a setup and a cleanup time, because those are paid and are not proportional to the batch; an efficiency factor, because a machine rated for something rarely achieves it; a capacity that can differ per product, because one machine is not equally fast at everything it makes; and a list of alternative work centres that can absorb the same job. Without those, the expected duration of every job is the operation's nominal cycle time multiplied by quantity, which is the number everybody already knows is wrong.
Where should a standard time come from?
Ideally from the work that has already been done rather than from the estimate that was typed in at implementation. A standard time entered by hand degrades quietly: the tooling changes, the operator gets faster, the product spec drifts, and the figure stays where it was because nothing forces anyone to revisit it. A system that can compute the cycle time from the tracked duration of recent completed work orders for that same operation closes the loop, the number the planner uses becomes a consequence of what the floor did rather than an opinion the floor is measured against. This only works where time is genuinely being logged against the operation, which is the real precondition; the point of automatic standards is not that they are cleverer, it is that they cannot rot without somebody noticing.
Why classify downtime by reason instead of just measuring it?
Because total downtime is a number nobody can act on, and downtime by reason is a decision. Fifteen minutes lost to waiting for material, to a machine failing, to a changeover, to running below rate, and to scrap are five different problems owned by five different people, and only the classification tells them apart. The standard grouping bundles those reasons into availability losses, performance losses and quality losses, which is exactly the decomposition overall equipment effectiveness is built from, so a system that captures the reason at the moment the time is logged gets OEE as a by-product, while a system that captures only the duration has to reconstruct the reasons later from memory. The cost of the classification is a single field on the time entry. The cost of not having it is that every downtime conversation starts from anecdote.