Software for machine builders, where the ERP runs out.

Engineer-to-order work has a specific problem, and it isn't that your ERP is bad. It's that ERPs were designed around repeatable production, and you don't have any. Every machine is a one-off. The scope changes after the order. The estimate was built on engineering hours nobody could pin down at quote time, and by the time you know what it really took, the machine has shipped.

An ERP is very good at clean, finished data: purchasing, payments, accounting. Where it struggles is everything upstream of that. Budgets that are still moving. Material committed but not ordered. Change orders. Approvals that depend on context rather than a fixed rule. Your work lives almost entirely in that upstream half.

What that produces, and it has a name

It produces a shadow system. A set of spreadsheets running alongside the ERP that hold the things the ERP won't: the live project budget, the change orders that haven't been formalized, the committed-but-not-ordered material, the real status of six machines in build. Everybody has one. Nobody put it in the plan.

The shadow system isn't a failure of discipline. It exists because the work genuinely doesn't fit the tool, and somebody sensible built the missing piece out of the only thing available. The trouble is what it costs you:

• One person becomes the glue. They know which sheet is current, how the formulas work, and what the ERP is wrong about. When they're out, project status becomes an educated guess.
• The same fact gets entered more than once. Into the quote, into the ERP, into the project sheet, into the customer update. Each copy is a chance to be wrong, and they drift apart quietly.
• Nobody trusts the project number. Not because anyone is careless, but because it depends on a sheet somebody updates when they get to it.

The four places it actually bites

• Quoting engineering hours. The hardest number in your business to estimate and the one most likely to sink a job. Nobody has a good answer for it, and almost nothing written about quoting even acknowledges the problem, because most quoting content is about parts rather than projects.
• Project status across several builds at once. Where is each machine, what's it waiting on, which one is about to slip. Assembling that from the ERP plus the purchasing inbox plus somebody's head is a weekly ritual in most build shops.
• Change orders and scope creep. The customer asks for something small. Whether it gets captured, priced and billed depends on somebody remembering to write it down while a machine is being built around them.
• Job costing on a moving target. The number is only as good as what gets recorded against the project, and on a long build with shifting scope that's exactly where capture is hardest. The honest version of this problem is on why job profitability numbers get doubted, and it applies double to engineer-to-order work.

What's worth doing about it

Not replacing the ERP. It's doing the job it's good at, and an ERP migration on top of an active build schedule is a year you didn't plan to spend.

What works is reading what your systems already hold and assembling the answer outside them, on a schedule, so it arrives instead of being built by hand:

• A project status read that assembles itself. Pulled from the ERP and purchasing overnight, one page, per machine: what's committed, what's received, what's outstanding, what's late. The thing your weekly meeting currently produces by hand.
• Vendor confirmations watched rather than chased. On a long-lead build, a component that was never acknowledged is a schedule problem you find out about far too late. That's the PO acknowledgement watcher, and it fits this work better than almost any other.
• Capture that doesn't rely on remembering. Time and material reaching the right project without anybody reconstructing a week on Friday afternoon.
• Quote-to-actual, closed. What the last three machines really took in engineering hours, in front of whoever quotes the next one. This is the compounding one. Every build you don't feed back is a build you learn nothing from.

Why Michigan, briefly

Worth saying because it surprised me. Michigan has just under 3,000 industrial and special machinery companies, which is close to California's count and more than Ohio, Illinois, Wisconsin or Indiana. Most of them average around twenty people. If you build machines for a living in this state, you have a great deal of company, and almost none of the software written for manufacturing was written with you in mind.

Common questions

We're an automation integrator rather than a machine builder. Same thing?

Close enough that it usually is. Long-lead projects, engineering hours that are hard to quote, scope that moves after the order, and status spread across several jobs at once. The paperwork problem is the same shape whatever you call the finished thing.

Our projects run six months or more. Does that change anything?

It makes capture matter more, not less. On a long build, anything reconstructed from memory is reconstructed from a much longer time ago, and a component that was never confirmed has months to stay invisible before it becomes a crisis.

Can you help with the estimating itself?

Not with the judgment, which is yours. What I can do is take the reading, extracting and typing off whoever estimates, and get last job's actuals in front of them before they price the next one. That's usually where the improvement is anyway.

We already have a project spreadsheet that works. Why change it?

If it genuinely works and more than one person can run it, don't. The question worth asking is what happens the week that person is out, and whether the numbers in it agree with the ERP. If both answers are comfortable, you're fine.

Related reading. The reporting wall in whatever ERP you run: JobBOSS custom reports, M1 ERP reporting, Global Shop Solutions reports, Epicor Kinetic reports. And if the shadow system is a stack of spreadsheets rather than an ERP problem, start with running on QuickBooks and spreadsheets.