Job shops don’t struggle because they lack software. They struggle because their systems assume repeatability where none exists.

In a job shop, every order brings a new routing, new material requirements, different outside processing, and a different margin risk. When ERP systems are built around fixed BOMs and stable schedules, job shops end up managing the real work outside the system—and paying for it later in missed dates and eroded margins.

This article breaks down where generic ERPs fail job shops, what operational controls actually matter, and how job-focused systems support the way custom manufacturing really works.

Common Problems When Quoting Isn’t Tied to Execution

In job shops, quoting is the first production decision—not just a sales estimate.

Example: An estimator quotes a job assuming one setup and standard material. After the order is won, the planner discovers the job requires two setups, a different alloy, and outside heat treat. The delivery date and margin are already wrong.

• Trigger: Quote accepted
• Constraint: Routing variability + material differences
• Consequence: Missed promise date, margin erosion
• Role: Estimator, planner
• Control point: Quote assumptions carried into the job

Fix:

• Capture operations, setups, outside services, and assumptions at quote time
• Carry those assumptions directly into the work order
• Treat quoting as a planning input, not a standalone document

Common Problems When Routings Are Rigid or Overwritten

Job shops need flexibility per job—not a single “correct” router.

Example: A planner modifies a routing on one job to add an inspection step. The system overwrites the standard router. The next job runs without inspection because the change wasn’t job-specific.

• Trigger: Routing adjustment for a custom job
• Constraint: Shared router definitions
• Consequence: Missed inspection, quality escape
• Role: Planner, QA
• Control point: Job-level routing control

Fix:

• Allow routings to be adjusted per job without altering standards
• Track routing changes with job-level audit trails
• Prevent one-off adjustments from becoming defaults unintentionally

Common Problems When Purchasing Isn’t Tied Directly to Job Demand

Generic ERPs often plan purchasing globally. Job shops buy per job.

Example: Purchasing orders material based on min/max. The job that actually needed the material releases later and misses its start date because the stock was consumed elsewhere.

• Trigger: Material issued to a different job
• Constraint: Job-specific demand not protected
• Consequence: Job delay, expedite
• Role: Buyer, planner
• Control point: Job-level allocation

Fix:

• Tie purchases and allocations directly to job demand
• Protect job material from being reassigned without approval
• Make shortages visible by job, not just by part

Common Problems When Job Status Doesn’t Reflect Real Progress

If execution isn’t captured reliably, planners can’t plan—and Sales can’t communicate.

Example: A supervisor reports a job as “almost done.” In reality, the final operation hasn’t been clocked and inspection hasn’t occurred. Sales commits to shipment anyway.

• Trigger: Status inquiry
• Constraint: Missing execution signals
• Consequence: Missed shipment, credibility loss
• Role: Supervisor, planner, customer service
• Control point: Status updates tied to real events

Fix:

• Define job status based on completed operations and holds
• Require reporting at operation completion and inspection
• Make holds visible so progress isn’t assumed

Common Problems When Job Costing Is Done After the Fact

Costing that arrives weeks later doesn’t help anyone improve.

Example: A job ships under margin. Post-hoc costing shows setup time doubled the estimate, but the estimator doesn’t see it until the next quarter.

• Trigger: Job close
• Constraint: Delayed cost visibility
• Consequence: Repeated under-quoting
• Role: Estimator, accounting
• Control point: Live actual vs. estimate tracking

Fix:

• Track labor, material, and outside services against the job as it runs
• Compare actuals to estimates in near-real time
• Feed variance back into quoting templates

Decisions You Need to Make

Job shop ERP only works when these decisions are explicit:

• Quote requirements: What must be defined before a quote is sent (operations, setups, outside processing)?
• Routing ownership: What can change per job vs. what stays standard?
• Material control: How are job materials allocated and protected?
• Status definition: What events define real progress?
• Cost feedback: When and how do actuals influence future quotes?

Without clarity here, the system can’t reflect reality.

If You’re Seeing X, Check Y

• If delivery dates slip after orders are won, check whether quote assumptions carry into the job. Fix by reusing quote data in routing and planning.
• If inspections are missed, check whether routing changes are job-specific. Fix by enforcing job-level routing control.
• If material shortages hit mid-job, check whether allocations are protected. Fix by tying purchases to job demand.
• If Sales can’t trust job status, check whether execution is being reported consistently. Fix by tying status to operation completion.
• If margins keep eroding, check whether costing feedback reaches estimators. Fix by comparing actuals to estimates while the job runs.

Final Thought

Job shop ERP isn’t about more features—it’s about respecting variability.

When quoting, routing, purchasing, execution, and costing are all handled at the job level, the system finally reflects how work actually happens. That’s when schedules stabilize, margins improve, and the ERP stops being something people work around.