What-If Scheduling and Capable-to-Promise (CTP)

Two questions come up constantly in production planning, and they sound similar enough that they’re often conflated: “what would happen to my schedule if I made this change?” and “what date can I honestly promise a customer for an order I haven’t taken yet?” Both are forward-looking, both require re-running the schedule against a hypothetical, and both are useless if the answer isn’t grounded in the shop’s real, current capacity. But they’re different questions with different answers, and understanding each on its own terms is what separates a genuine what-if capability from a guess dressed up as one.

What-if scenario analysis

A what-if scenario takes the current schedule, applies one hypothetical change, re-solves, and compares the result against the plan as it stands today. Common scenarios follow a small, recognizable set of patterns:

• Add a shift. What happens to this week’s tardiness and changeover totals if the bottleneck work center picks up a Saturday shift?
• Expedite an order. What does pulling one customer’s due date forward do to everything scheduled around it — does it ripple, and how far?
• Add machine capacity. If a fourth press came online next month, how much would that actually move the needle on the metrics that matter, versus how much would it just sit under-utilized?

Each of these is answerable, precisely, by the same mechanism: take the real, current set of orders and constraints, apply exactly one change, and let the same solver that produces the live schedule produce the hypothetical one too. The scenario isn’t a separate, simplified model — it’s the real model, asked a different question.

Why the comparison has to be apples-to-apples

Here’s the detail that separates a trustworthy what-if from a misleading one: the baseline and the scenario have to be evaluated against the exact same starting conditions, solved at the same moment. If a planner compares this morning’s live schedule against a “what if we added a shift” scenario computed that afternoon, the two are no longer directly comparable — the order book may have shifted in between, some jobs may have progressed, and any difference in the metrics is now a mix of the hypothetical change and ordinary drift, tangled together in a way nobody can untangle after the fact.

An honest comparison solves both the baseline and the scenario from the identical starting snapshot, side by side, so every difference in the resulting KPIs is attributable to the one change that was actually tested — nothing else moved. This is a stricter requirement than it might sound: it means a real what-if capability effectively pays for two full solves every time it answers one question, one for the baseline and one for the scenario, precisely because that’s the only way to make the comparison mean anything.

It’s also worth being explicit about what a scenario is not: a scenario plan is a hypothetical, not a committed change. Running “what if we added a Saturday shift” doesn’t add a Saturday shift — it answers the question of what would happen if someone did. Turning a favored scenario into reality means making the underlying change for real (actually scheduling the shift, actually pulling the machine online) and then re-running the ordinary schedule against that new reality, not treating the scenario run itself as an standing plan.

ATP vs CTP: two different kinds of promise

When a sales order comes in for a delivery date that hasn’t been produced yet, there are two structurally different ways to answer “when can we ship this”:

Available-to-promise (ATP) answers from the supply side: given on-hand inventory and any already-planned receipts, when will enough stock exist to cover this order? ATP is fast and simple, and it has a real blind spot — it doesn’t know or care whether the plant has the capacity to actually produce that stock on the timeline the inventory math implies. An ATP answer can be honest about materials and silently wrong about the factory floor.

Capable-to-promise (CTP) answers from the capacity side: given the shop’s real, current schedule — every order already in the plan, every machine’s real availability — where would this new order’s operations actually land if it were slotted in today, right now, against everything already committed? A CTP date isn’t a lookup against a stock projection; it’s the output of a real scheduling run that treats the hypothetical new order exactly the way it would treat a real one, subject to the same capacity limits every other order respects.

The practical difference shows up constantly in capacity-tight shops: ATP might say “material will be available Tuesday,” while CTP says “the earliest this can actually finish, given everything else already on the machines, is the following Monday” — and the honest answer to give a customer is the later of the two, because a promise that ignores capacity isn’t a promise, it’s a hope.

A worked example

A sales rep is on the phone with a prospective customer asking for 500 units, and wants an honest ship date before hanging up. The item has zero on-hand stock, so this isn’t an inventory lookup — it’s a production question.

An ATP-only answer might check the bill of materials, confirm raw material can be purchased and received by Thursday, and quote a ship date of the following Tuesday — five working days of production after material arrives, computed from the routing’s book times with no reference to what else is already on the machines. A CTP answer starts from the same material-availability date but then asks a harder question: given the plant’s real, current schedule — the fourteen other orders already occupying the bottleneck work center this week — where would these 500 units’ operations actually land? If that work center is running near capacity, the honest answer might be a ship date the following Friday, three days later than the ATP number, because the ATP calculation never asked whether the floor had room.

Quoting the ATP date here would be a promise the shop can’t keep without bumping someone else’s already-scheduled work. Quoting the CTP date is a promise grounded in what the plant can actually do on top of everything it’s already committed to — later, but real.

What a CTP quote is — and is not

A CTP quote is a projection from the plant’s real load at the moment it was calculated. That grounding is exactly what makes it trustworthy, and it’s also exactly what makes it temporary: the quote assumes the schedule it was calculated against holds. If three more orders land between the quote and the customer actually committing, the honest date can move — the same way any snapshot of a moving system starts to go stale the moment something else changes.

This means a CTP quote is not a reservation. Quoting a date doesn’t remove capacity from the plan the way an actual order would; it’s a read of what the plan currently supports, not a hold placed against it. Treating a quote as if it were an ironclad commitment — without re-confirming it once the order is actually real — is the single most common way a CTP-capable system’s honesty gets undermined by how it’s used downstream, rather than by anything wrong with the quote itself.

It’s also worth naming the honest limit of a CTP quote at the edge of what’s been modeled: a quote can only be as good as the capacity model it’s checked against — real calendars, real changeover costs, real material constraints where those apply. A quote calculated against an incomplete model will be precise and wrong in exactly the way an ATP-only answer is, just with more confidence attached to it.

The honesty cost of what-if

Both capabilities described on this page share a quiet cost that’s easy to overlook: every scenario answered, and every quote issued, is a real solve — not a lookup, not an approximation, but the same class of computation that produces the live schedule. That’s precisely what makes the answers trustworthy (they’re not guesses; they’re the real model, asked a real question), and it’s also why neither capability is something to run reflexively for every passing question. A shop that treats “just run a what-if” as free will eventually find the honest cost of that thoroughness showing up somewhere — solver time, review time, or both. The discipline that makes what-if analysis and CTP quoting valuable is the same discipline that keeps them used deliberately: ask the question when the answer will actually change a decision, not as a reflex.

Related reading

• Plan Stability: Frozen Horizons and Schedule Nervousness — why a scenario has to be disposable and review-only, never silently merged into the live, published plan.
• Measuring a Schedule: OTIF, Tardiness, and Utilization — the metrics a baseline-versus-scenario comparison is actually comparing.
• Modeling Real Capacity: Shifts, Calendars, Efficiency, and Parallel Machines — the capacity model any honest CTP quote depends on.
• In the product: Snapshots and Undo Checkpoints — SmartFlow’s saved per-order baselines.