Quoting a Job That Shares Your Bottleneck in EDGEBIC

When a quoted job routes through the same constraint machine as your committed work, the simulation queues it behind that load, so the bottleneck sets the promised date, and the date is honest about how full your constraint really is. EDGEBIC by User Solutions schedules the quoted job through the same finite capacity engine that plans production, against your live committed load, so a job sharing your bottleneck cannot start there until the existing queue clears. That is the number a lead-time rule of thumb can never give you.

A bottleneck is the machine your work waits on longest. Quoting through it is where capacity-based promising earns its keep, because it is exactly the situation a spreadsheet gets most wrong.

The bottleneck decides the date

Every job has one operation that gates the rest, and in a busy shop that operation is usually your bottleneck. When you quote a new job routed through it, the simulation does not pretend the machine is free. It rebuilds the shift allocations from your existing schedule and then tries to fit the quoted job around them. The quoted work lines up behind the committed work, and the constraint's queue length becomes the dominant driver of the promised end date.

This is why the same product can quote a two-week lead time when your bottleneck is light and a two-month lead time when it is backed up. Nothing about the routing changed. The load on the one machine everything waits for did. For the underlying idea, see production bottleneck identification.

Why a spreadsheet gets this wrong

A routing-only estimate multiplies hours by rates and adds material. It answers "what does this cost?" but it has no idea what your constraint is already committed to. A spreadsheet says the new job's bottleneck hours start Monday. Reality says they queue behind three weeks of existing work on that machine. The gap between those two answers is late deliveries and expedite fees, and it is widest precisely at the bottleneck.

The simulation closes the gap by making the quote a scheduling problem. It creates a temporary, invisible copy of the quoted job, schedules it against the live constraint load, reads the dates, and discards the copy. Nothing touches your real schedule, and the promise already accounts for every job ahead of it in the bottleneck's queue. This is the heart of quoting against real capacity.

Reading a bottleneck-driven date

When a quote comes back further out than you hoped, resist the urge to assume an error. First confirm the cause:

1. Open the work-center utilization view and find where the load piles up. If one machine is near its ceiling for weeks, that is your constraint, and it is setting the date.
2. Look at the quote's details window to see which machine received the bulk of the hours and when. A gap between an early routing step and the bottleneck step is the queue you are quoting behind.
3. Compare the simulated end against the customer's date. If it fits, price it and move. If it does not, the honest date is your starting point for a scenario, not a reason to fudge a promise.

A full shop is where this reading matters most; see quoting when the shop is already full for the wider case.

Pulling the date in: attack the constraint

The lever that moves a bottleneck-driven date is the one aimed at the bottleneck. Adding capacity or speed anywhere else barely helps, because the job was never waiting on those machines.

On the documented 200-unit Widget-A enquiry, the mill was the constraint, carrying 101 of the roughly 151 work hours. The base simulation ended August 14, six days past the customer's August 8 request. Two scenarios closed the gap:

Both scenarios moved the date because both added capacity where the job actually queued. A scenario that boosted the saw, which was never the constraint, would have moved the date almost not at all. The disciplined sequence is always the same: confirm the constraint, apply the lever there, re-simulate. You can also route the bottleneck step to an alternative work center that has open time, which is a replace-style scenario that offloads the constraint entirely.

Two jobs, one bottleneck

The clearest case is two enquiries competing for the same constraint. Quote each as its own simulation against the current live load. The first quote you commit, by converting it to an order, becomes part of the schedule the constraint carries. The second quote, simulated afterward, sees that committed work and queues behind it, so its promised date lands later. This is the honest picture your customers need: your bottleneck can only do so much per day, and capacity-based quoting makes the second customer's later date visible before you promise it, rather than promising both the same date and missing one. Note that a simulation itself never reserves capacity; the constraint's time is committed only when a real order is scheduled, so run your simulations in the order you intend to commit.

The payoff

Quoting through a bottleneck is the situation that separates capacity-based promising from guesswork. The date is set by your real constraint load, the way to improve it is to add capacity where the job actually waits, and the scenario workbench lets you test that before you commit a word to the customer. See the full workflow in the EDGEBIC quoting guide, and explore EDGEBIC to quote a real job against your own constraint and see the honest date.