The ERP was installed when George W. Bush was president. It does payroll and the GL, and it does them in a green-on-black terminal that two people on the floor still know how to drive. Everything the ERP can't do — scheduling, real job costing, anything resembling a dashboard — lives in spreadsheets that someone rebuilds every quarter, plus the part that lives only in your shop foreman's head. Ask for margin on the run you shipped last Tuesday and you'll get a number by Thursday, give or take.
That's not a margin number. That's an estimate dressed up as a fact.
What the gap actually costs
A manufacturing operation that can't see per-job margin in real time is flying on instruments that lag the aircraft. You quote the next job off the last job's "feel." You discover the run that ate its margin in scrap and rework only after the parts ship and the invoice goes out. You keep the customer who's quietly unprofitable because nobody's costed them honestly since 2021.
Put numbers on it. A shop doing $8M in revenue at a 14% gross margin is living on roughly $1.1M of gross profit. A 2-point quoting error across a third of your jobs — entirely normal when costing is retroactive and approximate — is $50–70k of margin you priced away before the first part was cut. That's not waste on the floor. That's waste at the keyboard.
Then there's the tribal-knowledge tax. When the foreman who knows the real setup times retires, the estimates that were "in his head" leave with him. You don't have a data problem then. You have a continuity problem, and it has a name and a retirement date.
We rebuilt exactly this kind of operation for Cadrivit — a 15-year-old core surrounded by spreadsheets — into one system. They cut 70–80% of operational cost and we shipped it 30% ahead of schedule. See the case study →
Why "just upgrade the ERP" misses the point
The standard advice is to rip out the old ERP and buy a modern one. Sometimes that's right. Usually it's the most expensive way to stay where you are.
A general-purpose ERP — NetSuite, Epicor, an Infor product — is a 400-module platform configured by a third-party implementer who learns your business over an 18-month engagement. The license is six figures a year. The implementation is six figures once. And at the end you get a system that does what every other shop's system does, with your specific workflows shoehorned into someone else's data model. The spreadsheets don't disappear. They reappear as "supplemental tracking" because the platform doesn't model the one thing that's actually unique about how you cost a job.
The 15-year-old ERP isn't the problem. The problem is that the layer where you make money — quoting, scheduling, real-time cost capture — was never modeled at all. It lives in the gaps between tools. Replacing the GL doesn't fill those gaps. It just gives you a newer GL with the same gaps around it.
The decision that determines everything: what is a job
Every operations build lives or dies on its central entity. In manufacturing, that entity is the job, and the first three weeks of real work are spent answering a deceptively simple question: what is a job, in your shop, exactly.
Is a job a customer PO, or a single run within it? When you re-run scrap, is that a new job or a charge against the original? How does a job relate to a work order, to a routing, to a material lot? Does labor get costed at standard rate or actual? Does machine time count, and at what burden?
Get this model right and everything downstream — costing, scheduling, reporting — falls out of it cleanly. Get it wrong and you've built a faster version of the spreadsheet chaos, with the bugs compiled in. This is the part that doesn't show up in a demo and determines whether the system still fits in three years.
// the model is the product
job → work_orders → routing_steps → { labor, machine_time, materials }
↘ cost rolls up in real time, not at close
Capturing cost at the source, not after the fact
The reason your margin is always retroactive is that cost gets captured after the work, in a separate act, by a separate person. The operator runs the part. Later, someone keys hours into a timesheet. Later still, someone reconciles material issues against the BOM. By the time those streams meet, the job is done and the number is history.
The fix is to capture cost where it happens. A tablet at the work center where the operator clocks on and off a specific work order. Material issued against the job at the moment it leaves the cage, scanned, not transcribed. Machine time pulled from a run timer, not estimated. None of this is exotic. It's the difference between a system that tells you what happened and one that tells you what's happening.
When cost lands on the job in real time, the dashboard stops being a Friday afternoon project. A job running 9% over its labor estimate at the halfway mark is a problem you address Wednesday — reassign, re-sequence, call the customer about a change order — instead of a postmortem you write next month.
What you build first, and what you leave alone
The mistake that sinks custom operations builds is trying to replace the entire ERP in one shot. Don't. The GL works. Payroll works. The terminal two people can drive — leave it running.
Build the layer that's currently missing: job costing, shop floor data capture, scheduling, and the reporting that sits on top. Let the new system own the operational truth and feed summarized financials to the old GL through a defined boundary. You run them in parallel until the floor trusts the new numbers more than the spreadsheets — and they will, fast, because the new numbers are right and current.
Phase two, if it's worth it, is absorbing the GL itself. Often it isn't. A modern operations layer feeding a boring, stable accounting system is a perfectly good end state. The goal was never "one vendor." It was one source of operational truth.
The build and the timeline
For a single-site shop in the $3M–$20M range, a focused operations platform — job model, shop floor capture, scheduling, costing, reporting — is a 4–6 month build.
Weeks 1–4 are the data model and a hard look at your real workflows, not the ones the org chart claims. Weeks 5–14 are the core: job and work-order management, floor data capture, cost roll-up. Weeks 15–20 add scheduling, the reporting layer, and the integration boundary to the existing GL. Then parallel-run, train, and cut over the operational workflows.
Budget runs $50k for a tightly scoped costing-and-capture build to $100k+ for multi-site, multi-process operations with quality, traceability, or regulatory requirements layered in. Against $50–70k of annual quoting error plus the staff hours currently spent rebuilding spreadsheets, the payback math is rarely the hard part of the conversation.
What fixed looks like
Fixed is an operator clocking onto a work order from a tablet, and that single action moving labor cost onto the job, updating cost-to-complete, and adjusting the schedule — with no second person, no timesheet, no Thursday.
Fixed is quoting the next job from your actual cost basis on the last forty like it. Setup times that are measured, not remembered. Scrap rates that are tracked, not guessed.
Fixed is the foreman's knowledge living in the system instead of only in the foreman. When he retires, the estimates stay.
Fixed is opening one screen Monday morning and knowing — not approximating — the margin on every job that shipped last week.
This is for you if
You run a discrete or batch manufacturing operation, 20–300 on the floor, $3M–$50M in revenue. You have an aging ERP that handles the books and almost nothing else, surrounded by spreadsheets and a couple of people who are the only ones who understand them. You cannot see per-job margin without assembling it by hand, and at least one quote in the last year was wrong because of it.
Budget: $50k for a focused costing-and-capture build, $100k+ for a full multi-site operations platform. The right number comes out of a paid scoping engagement where we map your actual job flow before anyone writes code.
This is not for you if you genuinely need a full enterprise ERP — a multi-entity, multi-currency, 300-user environment where SAP or Oracle is the correct answer and the budget is measured in millions. And it's not for you if you want a prettier spreadsheet. We build the system that ends the spreadsheets, then we leave the GL alone because it was never the problem.