Machine Shop Software: Fixing Quoting, Setups, and Scheduling

Why machine shop software makes or breaks a high-volume CNC operator

Your estimator has been quoting for 22 years. He opens the customer's STEP file in a viewer, eyeballs the part, remembers that the last 17-4 PH bracket like this one ran 14 minutes a side on the HAAS UMC-750 with the 40 taper, and types a number into a spreadsheet that has been forked six times since 2019. He is right about 80 percent of the time. The other 20 percent is where your margin lives. When he is wrong high, you lose the job to the shop across town. When he is wrong low, you eat 300 pieces of aluminum at 40 percent under cost and nobody finds out until the job closes three months later and the accountant flags it.

Meanwhile the schedule lives in three places that disagree with each other. There is the JobBOSS or E2 due date, which reflects a promise made to the customer. There is the whiteboard in the shop office, which reflects what the second shift lead actually plans to run. And there is the truth, which lives in the head of the guy who knows the 5-axis is down for a spindle rebuild until Thursday and that the Swiss cell is waiting on 12L14 bar stock that Fastenal short-shipped. Your dispatch list says Job 44182 starts Tuesday on machine 7. Machine 7 has a fixture for a different job bolted to the table and the setup guy has already cut the soft jaws.

Here is the scene that costs the most money and shows up in every shop we have worked in: a customer calls about a reorder of a part you ran 14 months ago. Nobody can find the setup sheet. The program is on the control, or maybe on a thumb drive in a toolbox, or maybe on the network share under a folder named by the operator who quit. The tool list exists as a photo somebody took on their phone. So you re-prove out a job you already proved out, burn 4 hours of a $95 an hour machine plus an $85 an hour setup tech, and quote the reorder at the same price as the first run because your system has no idea the second run should take 90 minutes instead of 5 hours. That is roughly $700 of pure waste per reorder, and the shops we work with at that size do 15 to 30 reorders a month.

Problem: quoting is a memory exercise, not a data exercise

The pain: in the shops we have opened the books on, quote hit rate sits between 18 and 30 percent, and nobody can tell which quotes they lose on price versus lead time, because nothing captures the outcome. Your estimator quotes 40 RFQs a week and touches each one for 25 to 60 minutes. That is a full-time job spent retyping information that already exists in the customer's PDF and STEP file.

Why the incumbents cannot fix it: JobBOSS2, E2 Shop System, and Global Shop Solutions all have a quoting module. Every one of them is a form. You type in material, you type in cycle time, you type in setup hours, and it does arithmetic. None of them look at the geometry. None of them know that your shop, specifically, runs 4140 pre-hard 30 percent slower than 6061 on the Mazaks but not on the Doosans. Paperless Parts and MachineMetrics are better in narrow slices, Paperless for quote packaging and MachineMetrics for spindle data, but neither closes the loop from geometry to your actual historical run time to a price.

What a custom build does differently: the quoting engine starts with the STEP or Parasolid file and runs feature recognition to extract hole counts, hole depth to diameter ratios, pocket volumes, thin walls, tightest tolerance callouts, and required setups. Then it queries your own job history, not a generic library, for parts with similar feature vectors, and returns the actual recorded cycle time from the machine, not the estimated one. This is where AI is worth the money: an extraction model reads the customer PDF drawing and pulls the tolerance callouts, material spec, finish spec, and quantity breaks into structured fields, so your estimator reviews rather than retypes. We have taken shops from 35 minutes per quote to 8 minutes per quote on repeat-family work. The engine also stores the quote outcome, won or lost and against what price, so within 6 months you have a hit-rate curve by customer, by part family, and by lead time, and you can stop quoting the customers who only use you as a stalking horse.

Problem: setups are tribal knowledge that walks out the door

The pain: you have a setup guy who has been there 19 years and a setup guy who has been there 8 months, and the difference in their setup times on the same part is 3 hours versus 55 minutes. When the 19-year guy retires, the shop loses a chunk of its capacity and nobody has a number for it.

Why the incumbents cannot fix it: ERP systems model a setup as a number of hours on a routing line. That is it. There is no object called a setup that has a fixture, a soft jaw program, a tool list with actual pocket assignments, a work offset, a probing routine, and a photo of the part clamped in the vise. Shops solve this with a network folder, a wiki nobody updates, or Excel. Then the folder path breaks when IT migrates to SharePoint.

What a custom build does differently: a setup becomes a first-class record tied to a part revision and a specific machine, not a number in a routing. It carries the NC program with its Git-style revision history, the tool list with pocket numbers and holder types, the fixture ID pulled from your fixture inventory with its physical rack location, the work offset values, the first-article dimensional results, and photos or short videos the setup tech captures on a tablet at the machine. When the same part number comes back 14 months later, the system knows it, surfaces the setup, tells you the fixture is in rack B slot 12, and the reorder gets quoted at 90 minutes of setup because that is what your own data says a repeat setup costs. Track this for a year and you have a real number for what tribal knowledge is worth, and a real onboarding path for the new tech.

Problem: the schedule is a fiction that nobody trusts

The pain: your ERP finite scheduler produces a Gantt chart. Your shop lead prints it, looks at it, and runs the whiteboard anyway. Every shop we have walked into with a scheduling module in the ERP has a whiteboard or a magnet board next to the machine that is the real plan. Ask why and the answer is always some version of: the scheduler does not know about tooling, does not know about the operator who can run the Swiss, and thinks all four VMCs are the same machine.

Why the incumbents cannot fix it: off-the-shelf finite capacity scheduling models a work center with a capacity number. Your reality is that machine 7 and machine 9 are both HAAS VF-4s but only machine 7 has the 4th axis and the through-spindle coolant, only two operators are cleared to run the Swiss cell, and the boring bar for the 2.375 bore exists in exactly one holder that is currently sitting in the Mazak. The constraint is not machine hours. The constraint is the intersection of machine capability, fixture availability, tooling availability, and operator certification. No packaged scheduler models all four because the data model does not have places to put them.

What a custom build does differently: the scheduler solves against your actual constraint set. Machines carry capability tags (4th axis, live tooling, bar feeder, max Z, spindle taper). Jobs carry capability requirements derived from the setup record. Fixtures and critical tooling are modeled as finite resources that can only be in one place. Operators carry certifications with expiry. The solver runs against all of it and produces a dispatch list per machine that the shop lead will actually follow, because it accounts for the things he was overriding it for. Machine state comes in live via MTConnect or FOCAS from the controls, so when the spindle goes down at 2 am the schedule reflows before first shift walks in instead of after. AI earns its keep on the forecasting side here: a model trained on your own cycle time variance predicts which jobs are likely to run long based on material, feature complexity, and which operator is on the machine, and you buffer those specifically instead of padding everything by 15 percent.

Problem: you find out you lost money on a job three months late

The pain: job costing in every off-the-shelf shop ERP is retrospective accounting. The job closes, someone posts labor and material, and a variance report appears. By then you have quoted the reorder at the same wrong price and taken three more jobs from the same customer at the same wrong margin.

Why the incumbents cannot fix it: the labor data is garbage in, and everyone knows it. Operators clock into jobs on a terminal at shift start and clock out at shift end. If a guy runs three jobs across two machines during a shift, the time gets attributed however he remembers it at 3:15 pm. The ERP faithfully computes wrong numbers from wrong inputs.

What a custom build does differently: stop asking humans to report time. Pull machine state directly from the control (MTConnect on the Haas and Mazak, FOCAS on the Fanuc, direct on the Okuma) and attribute spindle-on time to the job the operator confirmed on a tablet at setup. Cycle counts come from the machine, not from a tally sheet. Now you get a live margin number per job that updates every cycle, and a variance alert that fires at 40 percent through the run, not at close. In our delivery experience the first month of accurate data almost always reveals two or three part families the shop has been losing money on for years while believing they were the bread and butter. That single finding usually covers a meaningful share of the build cost.

Problem: quality and traceability records are a separate universe

The pain: you are AS9100 or ISO 9001 registered, or you want to be, and your quality records live in a folder tree plus a stack of paper FAIR packets plus an inspector's Excel workbook. An audit finding, or worse, a customer escape, means someone spends two days reconstructing what happened on a job from March.

Why the incumbents cannot fix it: the ERP owns the job and the quality software owns the inspection, and they talk to each other through a spreadsheet export at best. AS9102 first article reports get built by hand. The material cert for the heat lot lives as a PDF in an email thread.

What a custom build does differently: the traceability chain is one object graph. Heat lot number attaches to the raw material receipt with the mill cert PDF, flows to the job, flows to the piece, flows to the inspection record and the shipping document. CMM output from your Zeiss or Mitutoyo lands in the system by file drop and maps to the balloon numbers on the drawing, which the extraction model has already parsed. First article reports generate rather than get typed. When a customer calls about a suspect part, you pull the full chain in 30 seconds instead of 2 days. If you run ITAR-controlled work, this also means the data can live where it has to live: US-hosted, access-controlled by role, with an audit log that shows who opened which drawing and when. That requirement alone disqualifies several of the cloud shop ERPs.

What this actually costs and how long it takes

Across 2,000-plus projects, this is where the money lands for shop software specifically. A focused first release runs $60k to $130k and ships in 12 to 16 weeks. Focused means one thing done properly: usually the quoting engine with geometry extraction and history matching, or the constraint-aware scheduler with live machine data, not both. A full platform covering quoting, routing, setup records, scheduling, machine data collection, quality, and ERP integration runs $150k to $400k phased over 6 to 12 months.

What pushes the number up in this category, in rough order of impact. First, machine connectivity: if your fleet is a mix of 2004 Fanuc controls, newer Haas NGC, Okuma OSP, and a couple of Swiss machines with proprietary interfaces, the integration layer alone is 4 to 6 weeks of work and may need an edge box per cell. A modern all-MTConnect fleet is 2 weeks. Second, CAM integration: reading tool lists and setup sheets out of Mastercam or Esprit or Fusion is doable but each one is its own effort. Third, the ERP boundary: if you are keeping JobBOSS or Global Shop for AR, AP, and GL and building on top, the sync layer is real work and needs a clear ownership rule for every field. Fourth, AS9100 and ITAR: the compliance surface adds hosting constraints, audit logging, and validation work worth 15 to 25 percent on top. Fifth, multi-site: two buildings that share work is a different data model than one building, and you find this out late if nobody says it early.

What keeps the number down: a clean scope on release one, a named person at the shop who can make decisions in an afternoon, and a willingness to run the new system alongside the old one for a cycle instead of demanding a hard cutover.

Build versus buy: take the position

Buy off the shelf if you run under about 8 machines, your work is mostly prismatic parts in aluminum and mild steel, your job mix repeats, and your estimator is not the bottleneck. ProShop ERP is a strong product and it is properly AS9100-aware, so if it fits, use it. JobBOSS2 and E2 are fine at what they do. Paperless Parts is worth its subscription if quoting throughput is your only problem and you are willing to live inside its model. Buying is the right call more often than vendors like us admit, and a subscription that fits beats a $200k build that fits slightly better.

Build when three or more of these are true. Your estimator is the constraint on revenue and you cannot hire another one who is any good. You are running 12-plus machines with meaningfully different capabilities and the packaged scheduler is being overridden every day. You have a specific process that is your competitive advantage, high-mix low-volume in exotics, or lights-out on pallet pools, or a proving-out method nobody else has, and the software forces you to work like a generic shop. Your reorder rate is above 40 percent and you are re-proving jobs you already ran. Or you have two or more buildings and the ERP treats them as one site or two disconnected sites, with no way to model the reality of shared work.

The honest tell: if you are paying three people to keep spreadsheets in sync with your ERP, you are already building software. You are just building it badly, in Excel, with no version control, and paying $180k a year in salary to maintain it.

How to choose a developer for machine shop software

Ask them to explain, without prompting, why setup time and run time need separate data models and what happens to a repeat order if you conflate them. If they cannot, they have not built this. The follow-up: ask how they would model a fixture that can only be in one place at a time. The right answer is a finite resource in the scheduler, not a text field on the routing.

Ask what they have connected to. You want specific control names and protocols out of their mouth: MTConnect agents, Fanuc FOCAS, Okuma THINC, Heidenhain. Ask what they do about a 2004 control with no network port, because you probably have one. A team that has done this will tell you about edge gateways and shrug. A team that has not will say the machine needs to be replaced.

Ask who owns the code and the data, and get the answer in the contract. You should own the repository, the schema, and every byte of your job history, and you should be able to hire a different team next year without a migration project. Any developer who hedges on this is building themselves an annuity out of your operation.

If you are AS9100 or ITAR, ask about hosting jurisdiction, role-based access on drawings, and audit log retention in the first conversation, not the fifth. A developer who has been through an aerospace customer audit will bring it up before you do. One who has not will treat it as a checkbox to add later, and later is where AS9100 projects go to die.