We build production planning, inventory, quality and plant integration systems for manufacturers, so the run sheet, the stock count and the ledger all read from the same records.
Most plants run on more systems than anyone planned. An ERP that stops at the office door, a scheduling spreadsheet a supervisor rebuilds every Monday, a historian on the line that nobody reads, and a clipboard for the quality checks. Each one is right about its own piece and none of them agree on what the plant can ship this week.
The cost shows up as decisions made on stale numbers. A run is planned from a stock figure taken before the last scrap report. Purchasing orders a material that is already sitting in the wrong warehouse. A customer asks which raw lots went into a batch and the answer means a search through paper travellers.
We build the layer that makes those numbers one set. Tradivoo, our own management system for trading and production businesses, plans the next run from sales history, pre-orders and stock on hand, and rolls it down into batches and the components each batch consumes, whether that structure is a recipe with sub recipes or a bill of materials with sub assemblies. Where an ERP exists, we build around it.
Lead times slip, a supplier substitutes a grade, a minimum order quantity forces a buy you did not want. Purchasing reacts in email while the schedule and the stock system carry on as if nothing changed.
Lines expose data in whatever their controller supports, and older machines expose almost nothing. Counts, downtime and reject reasons end up written on a clipboard and typed in later, if at all.
The quote used a standard cost set some time ago. What the batch actually consumed, the scrap, the rework and the price the material was really bought at, is reconciled later, by which point the next quote has gone out.
A recall or a customer audit asks which raw lots went into which finished batch and which operator signed the check. That chain usually sits in batch sheets in a filing cabinet, not in a system anyone can query.
A plan built from sales history, pre-orders, par levels and stock on hand, rolled down into batches and components. The approved plan is laid against lines and shifts in changeover order, so a rush order shows what it pushes back.
On-hand, reorder level and available units for every part in every warehouse, with in-transit stock kept separate. Reorder suggestions come from live stock and lead times, and purchase orders carry landed cost and match against packing lists on receipt.
Collectors that read from controllers, historians and file drops, plus operator terminals for the lines that expose nothing. Data buffers locally when the network drops and syncs when it returns, so a bad hour does not lose a shift.
In-process checks captured at the station rather than on paper, with limits, sign-off and non-conformance handling. Lot genealogy links raw material receipts to finished batches, so a trace query returns an answer instead of a search.
Materials actually consumed at the price actually paid, plus labour hours, scrap and rework, costed per batch and set against the standard. Supplier invoices and certificates are read and extracted rather than retyped by the buying desk.
Tradivoo's demand forecast plans the next production run for a kitchen or plant from the last four weeks of sales, pre-orders, par levels and stock on hand. It rolls the finished goods into sub-recipe batches and raw ingredient quantities, so the kitchen gets a prep list, not a spreadsheet.
Tradivoo's stock overview shows on-hand, reorder level and available units for every SKU in every warehouse, with in-transit stock kept on its own page. Low-stock lines surface on their own, transfers and adjustments are logged, and the same numbers feed purchasing and the books.
Lot and batch traceability that has to survive a recall or a customer audit. Food safety record keeping on lines that produce food, including hold and release steps. Document control and change history that a quality audit expects to be able to read. Plant network segmentation, so machine data can be collected without exposing the control network.
Still unresolved? A 30-minute conversation with an engineer usually settles it faster than another page of copy.
No. Often the existing ERP handles finance and orders well enough and falls short on the floor. We usually build the planning, inventory and quality layer around it and integrate, so the ERP stays the system of record for what it is good at. Replacement is a decision we would only recommend if the existing system is genuinely blocking you.
It depends on what each line exposes, and we survey that first. Modern controllers and historians give us a clean read. Older machines might offer a serial output, a file drop or nothing at all, in which case we capture at an operator terminal instead, with reject reasons and downtime codes as a short list the operator can hit rather than type.
On your own hardware in the plant or in your cloud account, and the choice usually comes down to how reliable the link out of the plant is. Floor terminals and collectors keep working and buffer locally when they lose the network, so a bad hour does not cost you a shift of records. The data is yours, in a schema we document, and you can export all of it whenever you want.
Yes. The planning model works on a structure, and that structure can be a recipe with sub recipes or a bill of materials with sub assemblies. Both roll a demand figure down into what each unit consumes. Where discrete work differs is routing and changeover, and that is scheduling, which we build against your lines and shifts. The food specific parts, hold and release for example, are optional.
A 30 minute conversation with an engineer is usually enough to scope it honestly.