What-If Scenarios in EDGEBIC: Testing the Answer Before You Give It

What if analysis in production scheduling stops being theoretical the moment it uses your real capacity. In EDGEBIC by User Solutions, a scenario is a named variant of a quote's simulation: same product, same quantity, one deliberate change. Each scenario stores its own dates, hours, and costs, and none of them touch the production schedule.

This post covers what a scenario is in EDGEBIC, why the module exists next to quoting, and when to reach for one. For the discipline in general terms independent of any product, the existing what-if analysis in production scheduling post covers the concept. For the quote a scenario belongs to, see the quoting pillar.

The Question Scenarios Answer

A customer calls back on a quote. The simulation says the job finishes August 14. They need it by August 8.

At that moment there are three real options: run overtime on the constrained machine, work a weekend, or move a step outside. Each one costs something and buys something, and the honest answer to the customer depends on which trade you are willing to make.

Without a way to test them, that conversation runs on instinct. Somebody says the mill could probably take an evening shift, somebody else says the weekend would cover it, and the shop finds out in three weeks which one was right.

A scenario turns each of those sentences into a simulated schedule with a date and a cost attached.

What a Scenario Is

A scenario is a child of a quote. It inherits the quoted product and quantity, and it carries its own set of altered conditions.

Four kinds of change are available.

Production settings. Allow weekend production. Set a priority level from 1 to 10, which biases how aggressively the simulated job competes for capacity against existing load. Enable parallel processing and cap how many machines may run concurrently. Use a custom start date instead of the quote's, which is how you model a job that cannot begin until material lands.

Work center capacity overrides. Set a percentage against a specific work center for this scenario only. A value of 150 models a second-shift equivalent or overtime; 50 models a machine running at half strength.

Step overrides. Alter one routing step: skip it, replace its work center, change its setup or process times, or move it to a different position in the sequence.

Nothing else. That boundary is important enough that it has its own post: what a scenario can and cannot change.

Each scenario stores its own estimated start and end dates, lead time, total hours, and cost roll-up, plus a flag showing whether it has been simulated since it was last edited.

The Levers at a Glance

Because the list is short, it is worth seeing what each lever actually models on the shop floor.

Two of these are worth pairing in your head. Capacity percentage answers "what if this machine had more hours", and Replace answers "what if this work happened somewhere else". Most date problems on a constrained shop are solved by one or the other, and the comparison between them is usually the real commercial decision.

Scenarios Run on Your Real Shop

The most common misconception about what-if tools is that they simulate against an idealised calendar. This one does not.

A scenario run loads the same per-work-center, per-shift, per-date capacity override records that the production scheduler consumes. Your maintenance windows are there. Your holiday capacity cuts are there. The daily capacity adjustments somebody made last week are there.

The scenario's own overrides are applied on top of that picture. So a scenario is today's real shop plus one experiment, which is the only version of what-if analysis worth acting on.

What a scenario does not do is write anything back. Scenario simulations are in-memory runs. Nothing is written to the schedule, resource, or production schedule records, and no capacity is held. Real jobs never move. That is what lets a planner run the same scenario eight times while tuning a percentage.

The Worked Case: Six Days Late, Three Ways Out

Take the documented quote: 200 units, base simulation running July 20 to August 14, estimated cost $9,230, quoted at $85 per unit for $17,000. The customer needs August 8.

Scenario A, Standard. No overrides. Run it. End August 14, cost $9,230. Six days late. This is the baseline, and it exists so the other two mean something.

Scenario B, Second Shift on Mill. The constraint is the mill's 101 hours. Add a work center capacity override on that mill at 150%, which is 12 hours a day instead of 8. Run it. End August 5, lead time 16 days, cost $9,830. It meets the date with three days to spare.

Scenario C, Weekend Push. Instead of overtime, tick weekend production. Run it. End August 8, cost $9,590. It meets the date exactly, with zero slack.

Now compare:

The second shift costs $240 more than the weekend push and buys three days of protection against anything going wrong. At the quoted $85 per unit, the margin on Scenario B is ($17,000 minus $9,830) divided by $17,000, or 42.2%, still comfortably green.

That is a decision, made with numbers, in the time it takes to build two scenarios.

Comparing Scenarios

Tick the scenarios you want on the comparison tab. Only simulated scenarios can join a comparison, which prevents an unrun variant from appearing as a zero.

Three charts, one per dimension:

• Lead time, in days, one bar per scenario.
• Cost, one bar per scenario.
• Utilization, one bar per scenario.

The third chart is the one planners skip and should not. A scenario that wins on lead time by running a machine at full stretch for three weeks is a plan with no absorption for a breakdown. Winning by two days and losing all your slack is not always the right trade.

Applying the Winner, and What That Means

When one scenario wins, apply it to the quote. Its estimated dates, hours, and costs are written onto the parent quote, which is then marked simulated.

Read that sentence carefully, because it has a hard edge. Applying a scenario copies results. It does not change the product's routing, it does not change any work center, and it does not change the real schedule.

If the customer accepts a scenario that moved a step to an outside vendor, somebody has to make that routing change for real before the quote converts. If they accept a second-shift scenario, somebody has to arrange the second shift or add the real capacity override. Otherwise the production run reproduces the standard case and the promise fails on the exact day you promised it.

That follow-through is not a software limitation; it is what a scenario is. A scenario is a proposal with arithmetic behind it. Turning it into a commitment is a management action. The work centers guide covers where real capacity overrides live, and the graphical routing designer is where a real routing change gets made.

When to Use a Scenario, and When Not To

Use a scenario when you are exploring an alternative you might not adopt. A second shift. A vendor step. A weekend. A later start because material is delayed. Anything you would describe with the word "what if".

Edit the quote when the truth changed. A new quantity, a new date, a new price. Those are not experiments, they are facts, and they belong on the quote itself.

Change the real data when the decision is made. A scenario that has been accepted by a customer is no longer a what-if.

The signal that you should be using scenarios is duplicating a quote to test a condition. That duplication is exactly what the scenario object replaces, and it also keeps the alternatives attached to the enquiry they belong to.

Three Places a Change Can Live

Planners get more from scenarios once they can name which of three places a given change belongs in. The three are easy to confuse because they all involve typing a number into a screen.

The quote. Facts about the enquiry: quantity, target date, price, customer. When one of these changes, the quote changes. There is nothing to compare, because the old version is no longer true.

A scenario. Conditions you are testing and may not adopt. Extra capacity, a weekend, a vendor step, a later start. The whole point is that several can exist at once and be compared.

The real data. Work center capacity, shift calendars, routings, per-day capacity overrides. These describe the shop as it actually is, and changing one changes what every future schedule and every future quote will do.

The failure mode is doing the third when you meant the second, or the second when you meant the third. Editing a real work center's capacity to test an idea distorts every schedule until somebody puts it back. Applying a scenario and expecting the routing to have changed leaves a promise nothing can reproduce. Ask which of the three you are in before you type.

Two Honest Limits Up Front

Scenarios always simulate forward. They start at the scenario's start date and report when the work finishes. A backward quote's finish-by framing does not carry into its scenarios, so compare a scenario's end date against the customer's wanted date yourself.

Scenarios compare siblings only. A scenario belongs to one parent quote, and the comparison charts compare scenarios within that quote. Comparing across two different quotes means reading two screens.

Both of these, and several more, are covered in what a scenario can and cannot change.

Where to Go Next

• How to build and compare scenarios walks the fields and the comparison tab.
• What a scenario can and cannot change documents every boundary.
• Scenario planning mistakes covers the ways a scenario produces a confident wrong answer.
• The EDGEBIC complete guide maps every module, and production bottleneck identification helps you pick which machine to test first.