Machine Shop Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does replacing the whole ERP at once go wrong so often?

The reasoning sounds sensible in the boardroom. The shop is on JobBOSS2 or E2, everyone complains about it, so replace it. Then the requirements list grows to include purchasing, inventory, accounts receivable, accounts payable, the general ledger, payroll interfaces and shipping, because those are all things the old system did and nobody wants to run two systems. Twelve months later you have rebuilt a mediocre accounting package and have not yet touched quoting or scheduling.

The accounting half of a shop ERP is commodity work and the operational half is not. Nobody has an advantage in posting a supplier invoice. Your advantage lives in how you quote a 17-4 PH bracket, how quickly a repeat setup goes back on the machine, and whether the dispatch list matches what the shop lead will actually run.

The fix is to keep your existing ERP as the financial system of record and build the operational layer on top. In Digital Heroes delivery experience a focused first release covering one operational problem properly, usually either the quoting engine with geometry extraction and history matching, or the constraint-aware scheduler with live machine data, runs $60k to $130k and ships in 12 to 16 weeks. A full platform covering quoting, routing, setup records, scheduling, machine data collection and quality reaches $150k to $400k phased over 6 to 12 months. Pick the one where your bottleneck actually is, which for most shops past a dozen machines is the estimator.

What goes wrong when routings, cycle times and NC programs are migrated?

The migration plan says import part masters, customers, open jobs and historical routings. Part masters and customers move cleanly. Historical routings arrive and quietly poison everything downstream, because the recorded cycle times in most shop ERPs are estimator guesses that were entered once and never corrected against what the machine did. Import them as fact and your new quoting engine now returns confident prices derived from the same numbers that were losing you money before.

The NC programs and setup sheets are worse, and this is where shops underestimate the effort every time. They live on controls, on thumb drives in toolboxes, on a network share in a folder named after an operator who left in 2021, and in a SharePoint migration that broke half the paths. Nobody has an inventory of which program revision actually ran the last good job.

Two fixes. First, import historical cycle times flagged as low confidence, and let measured spindle time from the controls overwrite them as real jobs run, so within a few months your quoting history is your own data rather than inherited guesswork. Second, treat program and setup consolidation as its own workstream with a named owner, not a line item at the end. Plan 3 to 5 weeks running in parallel with the build. The shops that skip this end up with a new system that still cannot answer where the good program is, which is the exact question that costs $700 per reorder.

Why do machine control and CAM integrations break after launch?

The demo ran against three modern machines with MTConnect agents and everything worked. Then the integration met the rest of the fleet: a 2004 Fanuc control with no network port, a Swiss machine with a proprietary interface, an Okuma running OSP, and a Haas whose NGC control drops its connection whenever the shop wifi bridge reboots at night. Data goes missing in patches, the job costing numbers stop reconciling, and within a month the shop lead stops trusting the dashboard.

Your fleet was bought over twenty years from four vendors, so the protocol layer is not uniform. MTConnect, Fanuc FOCAS, Okuma THINC and Heidenhain are four different problems, and an older control may need an edge gateway per cell or, at the far end, a current sensor on the spindle to capture cycle and idle state at all. Reading tool lists and setup sheets out of Mastercam, Esprit or Fusion is each a separate effort again.

The fix is to design for gaps rather than assume a clean feed. Buffer at the edge so a dropped network link queues locally instead of losing the shift. Make every machine's connection state visible on screen, so a technician knows a machine is dark rather than idle. Attribute unmatched spindle time to an unassigned bucket rather than silently distributing it, because a job cost that quietly absorbs bad data is worse than one that shows a hole. Ask a prospective developer what they do with a control that has no network port. A team that has done this shrugs and talks about edge gateways. A team that has not will tell you the machine needs replacing.

What happens when AS9100 traceability and ITAR hosting are not covered?

The build ships, the shop is happy, and then an aerospace customer's audit asks for the material certificate, the inspection record and the program revision behind a specific serialised part from March. The system holds the job and the cycle times, but the mill certificate is a PDF in an email thread, the first article report was typed into Excel, and the balloon numbers on the drawing were never linked to anything. Reconstructing the chain takes two days per request.

The International Traffic in Arms Regulations version of this failure is worse, because it is not a reporting gap, it is a hosting decision. If controlled technical data ends up in a cloud region or under an access model that does not meet the requirement, the remedy is a migration and a retro-fitted access control layer, and the customer who asked the question may not wait for it.

The fix is to decide both in the first conversation rather than the fifth. Model traceability as one object graph: heat lot on the raw material receipt with the mill certificate attached, flowing to the job, to the piece, to the inspection record, to the shipping document. Land coordinate measuring machine output from your Zeiss or Mitutoyo by file drop and map it to the balloon numbers already parsed from the drawing, so AS9102 first article reports generate rather than get typed. Set hosting jurisdiction, role-based access on drawings and audit log retention as constraints on the architecture from day one. Expect the compliance surface to add roughly 15 to 25 percent on top of the base build, and treat any developer who offers to add it later with suspicion, because later is where these projects stall.

Should you build custom or configure what you already own?

Configure and stay put if you run under about 8 machines, your work is mostly prismatic parts in aluminium and mild steel, your job mix repeats and your estimator is not the bottleneck. JobBOSS2 and E2 are competent at quoting arithmetic, work orders and job costing. ProShop ERP is a genuinely strong product and it is properly AS9100-aware, so if your process fits it, use it and spend the difference on a probe and a pallet system. Paperless Parts is worth its subscription if quoting throughput is your only problem and you can live inside its model.

Build when three or more of these hold. Your estimator is the constraint on revenue and you cannot hire another good one. You run 12-plus machines with meaningfully different capabilities and the packaged scheduler is overridden every single day. Your reorder rate is above 40 percent and you are re-proving jobs you already ran. You have a process that is your competitive advantage, high-mix work in exotics or lights-out running on a pallet pool, and the software forces you to operate like a generic shop. Or you have two buildings that share work and the ERP treats them as one site or two disconnected ones.

The tell that decides it: if you are paying three people to keep spreadsheets in sync with the ERP, you are already building software, without version control, and paying salaries to maintain it.

How do hidden costs get into the quote?

Five places, in rough order of impact.

• Machine connectivity. A quote written against an all-MTConnect fleet is a different number from one covering mixed vintages. Ask for connectivity to be priced per machine group with the protocol named, and expect 4 to 6 weeks of integration work on a genuinely mixed fleet against about 2 on a modern one.
• CAM integration. Mastercam, Esprit and Fusion are each their own effort. A line saying CAM integration without naming the package is hiding a choice.
• The ERP boundary. If you keep JobBOSS or Global Shop for financials, the sync layer needs an explicit ownership rule for every shared field: which system owns the due date, the routing, the part master. Get that wrong and you have two systems arguing, which is worse than one bad system.
• Compliance surface. AS9100 and ITAR add hosting constraints, audit logging and validation work, commonly 15 to 25 percent on top.
• Multi-site. Two buildings that share work is a different data model from one building, and it is expensive to discover late.

What separates a shop software build that works from one that fails?

Four things.

Setup is modelled as an object, not a number of hours on a routing line. It carries the NC program with revision history, the tool list with pocket numbers and holder types, the fixture identifier with its physical rack location, the work offsets, the first article results and photographs taken at the machine. Ask a developer to explain why setup time and run time need separate data models, and what happens to a repeat order when you conflate them. If they cannot answer without prompting, they have not built this.

The scheduler solves against your real constraints. Machine capability tags, fixture and critical tooling as finite resources that can only be in one place, and operator certifications with expiry. A scheduler that models a work centre as a capacity number will be overridden by the shop lead within a fortnight, exactly like the one you already have.

Machine data lands before opinions do. Spindle-on time from the control, cycle counts from the machine, and a job confirmed on a tablet at setup. The first month of accurate data usually reveals two or three part families the shop has been quietly losing money on, and fixing those prices frequently covers a meaningful share of the build.

You own the code, the schema and every byte of job history, written into the contract before work starts. Digital Heroes assigns that from the first commit. Your run-time history is the asset the quoting engine is built on, and a vendor holding it is holding the thing that makes your next quote accurate.