Enabling Parallel Processing in a Quote Scenario in EDGEBIC

Enabling parallel processing in a quote scenario tells the EDGEBIC simulation to run parallel-capable steps at the same time, up to a cap you set, which shortens the simulated finish date when the routing supports it. In EDGEBIC by User Solutions, a scenario is a named what-if variant of a quote, and parallel processing is one of the levers it exposes, paired with a maximum on how many work centers may run at once. Turned on, it lets concurrent work overlap in the simulation rather than queue. But it only helps if the routing was actually built with steps that can run in parallel, which is the caveat that decides whether the date moves at all.

What the switch does

A finite capacity simulation, by default, runs a routing's steps in the order the routing defines. Step two waits for step one, step three waits for step two, and so on. That sequential placement is correct for work that truly must happen in order.

Some work does not have to. Two sub-parts of an assembly made on separate machines can run at the same time, then meet at a later join step. Parallel processing is the setting that lets the simulation model that overlap. When you enable it on a scenario, parallel-capable steps run concurrently instead of one after another, and the estimated finish shortens by the time the overlap saves.

Alongside the switch sits a cap: the maximum number of work centers the scenario may run simultaneously. The default is 2. It is a ceiling on concurrency, not a target. The simulation runs as many parallel steps as the routing supports, up to that number.

Because all of this lives on a scenario, it changes the simulation only. Nothing writes to the live schedule and no real job moves. The boundary is the same one described in what a scenario can and cannot change in EDGEBIC.

The caveat that decides everything

Parallel processing cannot invent concurrency the routing does not describe. If every step feeds the next, the routing is a single sequential chain, and there is nothing to overlap. Enable the switch on a strictly sequential routing and the simulated date does not move, because the engine still has to run the steps in order.

So before you expect the setting to help, ask whether the routing was built with parallel-capable steps on separate work centers. When it was, the switch pays off. When it was not, the honest conclusion is that concurrency is not your constraint, and you should look at capacity on the long sequential chain, an outside vendor, or an earlier start instead.

A worked example

A customer wants an assembly built from two machined sub-parts that are welded together at the end. The routing is: machine part A on the mill, machine part B on the lathe, then weld the two. Part A takes three days, part B takes two, and the weld takes one.

Your base simulation runs them in order: three days for A, then two for B, then one to weld, finishing in six days. But A and B are made on completely separate machines and do not depend on each other. They are parallel-capable.

You build a scenario, enable parallel processing, and leave the cap at the default 2. On the re-run, A and B run at the same time. The pair now takes three days, the longer of the two, instead of five, and the weld adds one, for a four-day finish. You have pulled two days out of the promise using machines you already own.

Raising the cap to 4 would change nothing here, because only two steps are parallel-capable. The cap is a ceiling, and this routing tops out at two.

Read it against the customer date, forward only

As with every scenario knob, the parallel result is a forward simulation. It starts at the scenario's start date and reports when the work finishes. A backward, finish-by promise does not carry into a scenario, so you compare the parallel scenario's estimated end date against the customer's date yourself.

Use parallel processing the same way you use the other levers: as a test of one specific idea, in this case "what if this work overlapped." When it closes the date, you have a defensible way to hit the customer's requirement with existing machines. When it does not, you have learned the routing is a sequential chain, and you move on to a capacity or vendor option, the kind covered in comparing routing options for a quote.

The takeaway

Parallel processing is the scenario switch that lets concurrent work overlap in the simulation, with a cap on how many work centers run at once. It shortens the quoted date when, and only when, the routing has steps that can genuinely run in parallel on separate machines. The default cap of 2 handles most real cases, and raising it helps only if the routing has more than two things to run together. Test it as a what-if, read the finish against the customer date, and reach for capacity or a vendor when the routing is a sequential chain instead. See the full flow in the EDGEBIC quoting guide, the fundamentals in what is production scheduling, and the platform in full on the EDGEBIC overview.