The plan, the stockroom and the floor should not be three systems
Most production planning goes wrong in the gap between them. An MRP run that reads today’s stock, plans against a pinned bill version, and hands the dispatch list to the bench closes that gap — and works offline when the bench has no signal.
· 4 min read
The spreadsheet next to the ERP is the diagnostic symptom of manufacturing software. It exists because the ERP’s planning run was slower to use than a spreadsheet, or ran monthly when the shop needed it on Tuesday, or planned against a bill that had changed since the job was released.
Every one of those is the same failure: the plan, the stockroom and the floor are three systems, and the spreadsheet is where somebody reconciles them by hand.
A regenerative run, on demand
The MRP run in Rutba Manufacturing is regenerative and you start it. It nets against on-hand and reserved stock — the real numbers, held by Rutba Inventory, which this product requires — respects lead times, and plans by lot policy.
What comes out is planned buy and make orders, each pegged back to the demand that caused it. Pegging is the difference between a planner who can act and one who can only look: without it, a suggested purchase order is a number with no story.
- Nets on-hand and reserved, so the plan is against real stock rather than a snapshot.
- Planned orders peg to the demand behind them.
- Firming survives the next run — a firmed order becomes supply, not a suggestion that gets re-suggested.
- A work-order timeline for the picture, and an exception list for the thing to do next.
The bill is pinned at release
Bills of material carry versions, effectivity, where-used and a change record. At release, the version the floor will build is pinned.
This is a small mechanism that removes an entire class of expensive mistake: an engineer revises a bill on Wednesday, and the job released on Monday continues to build what it was released to build. The bench and the plan cannot disagree, because they are reading the same pinned version.
A bill that changes underneath a released job is not a revision. It is a defect with a date on it.
The terminal on the bench
Shop Floor is an operator terminal on a shared device: clock on by PIN, take the dispatch list for the bench, start and stop an operation, report output and downtime. Stops are reported with a reason code, which is what drives an andon board the floor can read from across the room.
It has an offline queue, because a factory is a building with metal in it and the far bay has no signal. A terminal that stops working when the network does is a terminal the floor stops using, and a floor that stops reporting is a plan that goes back to being a spreadsheet.
Three of five, and which two are not
Maintenance is the interesting one. The work engine behind it is built by the facilities programme and shared, because a machine is an asset. When it lands, Maintenance and Rutba Facilities will be two surfaces over one engine rather than two registers of the same machines — so there is nothing to reconcile between them, ever.
Cost, computed rather than estimated
Standard cost is computed per bill version, from the bill, the routing and the work-centre rates. Batch and lot traceability is recorded, and the cost roll-up posts to the accounts. Nobody types a standard cost into a second system and nobody reconciles one afterwards.
| Plan | Price | What it is for |
|---|---|---|
| Starter | $32 / user / month | Simple assembly and kitting. |
| Growth | $74 / user / month | Planned production, with the floor reporting into it. |
| Enterprise | Custom, annual | Multi-plant and continuous production. |
Rutba Manufacturing
Every capability, the five applications with their real availability, and what shipped when.
See the product