Cases / Manufacturing · Order-to-shipment platform
Client under NDA Integrations and calculations

An order now reaches the shop floor in hours instead of days, and 92% of shipments leave on time instead of 70%.

70% → 92%
shipments on time
4 days → 4 hours
from order to shop floor
~4 mo
to the full loop

The client is under NDA, so the industry and size are given as a range. The figures are the client’s own, comparing the periods before and after launch; on similar projects the result landed on both sides of these numbers. Run the numbers on your own volumes →

Context

The days were lost between order confirmation and the shop floor.

A serial manufacturer, around 200 staff, one site. Orders arrived by email or in the CRM, a manager copied them into a spreadsheet, and procurement worked out material requirements by hand — from a product’s bill of materials kept in another spreadsheet, against stock figures from the accounting system that were a day or two behind. Every step was a re-keying, and every re-keying cost a day: an order reached a job list three to five days after it was confirmed. Some batches then stalled on the floor because the material was short — which surfaced at the moment of release rather than before it. Delivery dates were quoted with a buffer, and roughly every third order still shipped later than promised. Stock lived in two places: the accounting system, and the storeman’s head.

Solution

One platform between the order, the bill of materials and the stock.

The same stack as on our other projects: Python and Django at the core, PostgreSQL as the source of truth for the order, the bill of materials and the material. An order is entered once, the platform expands the batch into requirements from the product’s bill of materials, calculates them against actual stock and purchases already placed, and turns a shortfall into a procurement request on its own. We did not replace the accounting system — it stayed the system of record and documents, and the platform exchanges data with it.

Architecture
Ordersemail · CRMBills of materialsnorms and routingStockbalances and batchesPurchasingrequests and datesPlatform coreorder · BOM · materialAccounting systemrecords and documentsJob listfloor and cellsProcurementsupplier requestsOrder statusmanager and customerReportingdates and cost
What we built

Six loops in four months.

The order was set by the money: first the thing that removes the lost days, then everything else.

01
Order and bill of materials
An order is entered once and expands into requirements from the product’s bill of materials. The bills and the consumption norms live in one place and in one version, instead of one spreadsheet on the process engineer’s machine and another in procurement.
02
Material requirements
Calculated against actual stock and purchases already placed. A shortfall goes to procurement as a request rather than an email, and it shows up before release instead of on the floor.
03
Release to the floor
The platform builds the job list itself, from confirmed orders that have their material, and shows its reasoning line by line: what is constrained by what and what has to move. The production manager approves it or changes it. Order to job list went from three to five days down to hours.
04
Stock and write-offs
Material is written off against actual output rather than once a week, and stock stopped drifting away from the accounting system.
05
Dates and statuses
The manager and the customer can both see where an order stands, and nobody walks onto the floor to ask. On-time shipments went from 70% to 92%.
06
Reporting
Cost is calculated per order, and missed dates are broken down by cause — material shortfall, rework, downtime — instead of collapsing into one "we were late".
Before and after

Before and after.

Before
Shipments on time~70%
Order to shop floor3–5 days
Bills of materialsin spreadsheets
Material requirementsyesterday’s stock
Material shortfallfound on the floor
Stock write-offsonce a week
Cost per orderafter closing
After
Shipments on time~92%
Order to shop floorhours
Bills of materialsone version
Material requirementsactuals and purchases
Material shortfallbefore release
Stock write-offsagainst output
Cost per ordervisible as it runs
Limits
What stayed with people, on purpose.
—The consumption norms and the routing. The process engineer sets them; the platform calculates from them, it does not invent them.
—Approving the job list. The platform assembles it and explains every line, but the production manager signs it off, not an automation.
—Negotiating dates and prices with a supplier. The request goes out automatically, a person does the talking.
—Accepting incoming material on quality. That is eyes and hands, not a line on a delivery note.
Stack
Python Django PostgreSQL Accounting system exchange Task queues Reporting Monitoring and alerts
Straight about where the loss was

The days were lost between systems, not on the shop floor.

The floor was working fine, and we touched neither the machines nor the people on them. The loss sat between order confirmation and release: four re-keyings in a row, a day on each. We did not replace the accounting system either — it stayed where it was, and the platform sits alongside it and exchanges data. The four months did not go on code: the consumption norms and the bills of materials had to be put in order first, because there is nothing to calculate material requirements from when the norms exist in three versions. That part was done by the client’s own process engineer, and without it the launch would have been pointless.

Related

What this case is made of.

The service pages explain the method behind this project; the solution pages take the same building blocks on their own, each with its own scope and price.

Want the same for your process?

A free mini-audit projects the ROI for your highest-impact process — then the build is a fixed price.

Get a free mini-audit →