For manufacturers we automate what happens between the order and the shop floor: one entry point for an order, requirements expanded from the bill of materials, stock and open purchases checked before release, and a job list the production manager approves rather than assembles. On our manufacturing project an order reached the floor in hours instead of three to five days, and on-time shipments went from 70% to 92%.
An order is copied from email into the CRM, into a spreadsheet, into the accounting system. Every copy costs a day and adds one more place to be wrong.
Norms and bills exist in several versions on several machines, so requirements get calculated from whichever file happened to be open.
Requirements are worked out against yesterday's figures, and the shortfall surfaces at release instead of before it.
Everyone knows the order shipped late. Nobody can say whether it was material, rework or downtime, so the same cause repeats next month.
One entry point for an order, propagated to every system that needs it, with retries and alerts instead of silent failure.
Expand a batch into requirements from the bill of materials, check against actual stock and open purchase orders, and draft the job list for approval.
Read incoming invoices, delivery notes and supplier specifications, match them to the purchase order, and post what clears your rules.
Answer where-is-my-order from the systems that already know, so nobody walks onto the floor to ask.
from order to shop floor
Client under NDA. The figures are the client's own, comparing the periods before and after launch.
This is the project behind the case above, described the way it happened rather than as a method. 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 calculated material requirements by hand against stock figures that were a day or two old. Nothing on the floor was broken — the days were lost in four re-keyings before it.
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, in one version, instead of one spreadsheet in engineering and another in procurement.
Calculated against actual stock and purchases already placed. A shortfall becomes a procurement request rather than an email, and it appears before release instead of on the floor.
The platform builds the job list from confirmed orders that have their material, and shows its reasoning line by line. The production manager approves it or changes it. Order to job list went from three to five days down to hours.
Material is written off against actual output rather than once a week, and stock stopped drifting away from the accounting system.
The manager and the customer can both see where an order stands. On-time shipments went from 70% to 92%.
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'.
Four months, and most of it did not go on code: the consumption norms and the bills of materials had to be reduced to one agreed version first, which the client's own process engineer owned. What deliberately stayed with people: setting the norms and the routing, approving the job list, negotiating dates and prices with suppliers, and quality acceptance of incoming material.
One to two weeks. Fixed, and credited in full against the build.
A fixed quote against the scope the audit produced.
On this project. Two to four months is the range across our cases.
Model and infrastructure usage plus maintenance. Moves with volume.
Every batch keeps the materials it consumed, the version of the norms it was released against and who approved it, because reconstructing a batch is what a customer audit asks for.
Anything that moves a machine stays with the systems certified to move it. We build above that line and say so before the contract rather than after.
Stock, documents and accounting keep their home. The platform calculates and proposes; the record stays where your auditor already looks for it.
Requirements can only be calculated from data that agrees with itself. Consolidating the norms is the first task on every project of this kind, and it is your process engineer who owns it.
The path from a confirmed order to a runnable job list — three to five days of re-keying on a typical site, and where the fastest payback usually is.
Expanding a batch from the bill of materials and checking it against actual stock and open purchases, so a shortfall appears before release rather than on the floor.
Invoices, delivery notes and specifications read and matched to the purchase order, which removes a whole category of retyping at once.
PLC, SCADA and anything with a safety function: we do not build it and we do not modify it.
We will not replace a working ERP or MES to make an automation easier — the platform sits alongside them and exchanges data.
If the norms and bills of materials disagree between departments, that is a data project first. No calculation built on top of them will be right until it is done.
Each page states the workflow, the systems it integrates with, what it costs and when it is the wrong choice.
Sorts mixed incoming documents by type and routes each one to the queue, folder or system that owns it.
Reads incoming invoices, checks totals, tax and supplier against the ERP, and posts only what clears the rules.
Watches tender portals for matching notices, extracts the requirements and flags the ones worth bidding on.
No. We work above the shop floor: orders, bills of materials, requirements, stock and documents. Machine control and safety systems stay with the people and vendors who certified them.
We don’t propose an off-the-shelf product either. The audit is there precisely to see where your process differs from the ordinary one, and the build is shaped around that difference. And if it turns out a standard tool covers you well enough, we’ll say so plainly — the process map stays with you in any case.
It’s a fair thing to ask, and responsibility matters more here than accuracy. A person answers for it, and the system is built so that they can: a doubtful case is never posted quietly, it goes to a review queue. Low confidence isn’t an error for us, it’s a route. Around 70% clears straight through and a person looks at the rest — and where exactly that line sits is yours to decide.
That’s a common requirement, and a reasonable one. We fit the setup to your data rules: if nothing may leave, the model runs locally inside your own perimeter, and the documents never cross it.
That’s not unusual, and it’s fine. Integrating without an API is the most underestimated line in a quote, which is why integration surface comes first among the four cost drivers, and why we don’t name a fixed price before the audit. Working without an API is perfectly possible — files, exports, email — it simply costs more, and it’s better to know that early. Which is why, fairly often, we build the API for you.
It happens often, and usually for one reason: the pilot was measured on the happy path and the exceptions were left for later — though the exceptions are where most of the work turns out to be. So we look at the share that clears without a person rather than at extraction accuracy, and we agree in advance who handles the rest, and how.
No, that isn’t what this is about. What goes is the retyping, not the people: decisions stay with a person — the disputed document, the non-standard transaction, the conversation with the client, the signature under the reporting. On one accounting project, closing a client month went from three days to four hours, not because anyone was let go, but because a qualified specialist stopped keying in details by hand. The time that frees up most often goes into growth: more clients with the same team, without the costs rising alongside.
It’s a fair question, and sometimes doing it yourselves really is the right answer. We say so when the volume doesn’t justify a build: below roughly 300 documents a month the arithmetic usually doesn’t work. The calculator on this site includes running costs, so you can weigh that up before you ever talk to us.
They do change, and that’s exactly what we build for: the model is a replaceable part here, not the foundation. The source of truth is our own database — the document, the counterparty, the entry. The model is attached to the side, and we update it whenever something better appears; for you that’s planned maintenance, not a rebuild.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy