The What-If Process Simulator: Three Levers That Let You Test Change Before Committing

The what-if simulator is a side panel that opens over an existing BPMN and lets you modify the process without modifying the source. You toggle automation on individual tasks, change execution frequencies, and mark tasks for removal. Every change recomputes the cost-per-execution, the monthly burn, the critical-path time, and the total duration on every task in under 100 ms. When a scenario reads well, one button applies it to the actual process; otherwise you reset and try another scenario.

The three levers are intentionally few. Most real optimisation questions reduce to one of "what if we automated this step", "what if volume doubled", or "what if we eliminated this step entirely". The simulator covers exactly those three cases and refuses to do more: additional complexity would make the cognitive load of comparing scenarios heavier than the value of the analysis. Three levers, live deltas, two buttons.

Check the automation box on a task and the simulator treats it as if an AI agent or automated service is now handling it. The financial effect is sharp: the task's cost-per-execution goes to $0 (automation does not bill labour) and its duration collapses to 1 minute (most automation is effectively real-time from the process's point of view). The simulator does not model the tool cost of the automation itself: that is a separate line you would add in the actual optimisation. This lever answers "what is the best case if we fully automated this step", not "what does this specific automation cost".

• Tasks with duration already ≤ 1 minute are not further shortened, you cannot make a fast task faster.
• Tasks with cost already at 0 (for example, other automated service tasks) are unaffected.
• The simulator adds an isAutomated flag to the task in the scenario, visible in the canvas preview so you can see at a glance which tasks you have assumed automated.
• The cost saving shown assumes the tool-cost of the automation is captured separately: treat the simulator number as the upper bound on savings.

Override any task's frequency to model volume changes. The two common scenarios are "what if this process grows 3x" (multiply every task's frequency by 3) and "what if we cut this task's frequency in half through better triage" (change one task's frequency). The monthly burn recalculates live: every change to a task's frequency updates the cost contribution of that task to the overall burn, and the top cost drivers may reorder as a result.

The frequency override is per-task, not per-process. A sensible process-wide volume scenario multiplies the frequency of every non-loop task by the growth factor you are testing. The simulator does not auto-scale all tasks together because optimisation rarely scales every task uniformly: a process doubling in volume usually has some tasks that scale perfectly linearly and others that need a complete rearchitecture. Per-task overrides let you model both patterns.

The third lever is the bluntest: remove a task from the process. The simulator filters the task out of the node set and automatically reconnects the incoming and outgoing sequence flows so the diagram remains executable. The removed task's cost and duration contribution both go to zero. The structural assumption is that the task was not load-bearing: removing it does not break the process. The simulator does not verify this; you have to believe the task is genuinely redundant before you mark it removed.

The delta panel shows four numbers that update live with every lever change. Cost delta is the change in cost-per-execution expressed as an absolute dollar amount and a percentage (green if a saving, red if an increase, grey if no change). Time delta is the change in critical-path time: the clock-time shortening or lengthening. Total duration delta is the change in the sum of all task durations: useful for modelling labour capacity rather than cycle time. Two counters show how many tasks you have marked automated and how many removed.

The distinction between critical-path time delta and total duration delta is where beginners get confused. Removing a 30-minute task that sits on a parallel branch reduces total duration by 30 minutes but leaves critical-path time unchanged: the process does not actually finish any faster because the critical path is on another branch. The simulator shows both numbers so you always know which one you are optimising. Cycle-time improvements need critical-path reductions; labour-cost improvements only need total-duration reductions.

Scenario A: the "what would full automation save us" upper bound

Automate every task that is not explicitly human-dependent. The resulting cost-delta is the theoretical ceiling on savings from an automation programme. In practice you will never get there: tool costs, edge cases, and partial automations will reduce the real saving, but knowing the ceiling bounds the conversation. A 75% theoretical ceiling means the project is worth running; a 15% ceiling means it is not.

Scenario B: the "can we absorb 3x volume" stress test

Multiply every task's frequency by 3. Watch the monthly burn and look for which tasks become top cost drivers at the new volume. Tasks that were unremarkable at current volume often dominate the top three at 3x, which is exactly the kind of surprise the simulator is built to surface. The top three at 3x volume are the priority automation candidates if growth is real.

Scenario C: the "one change, many steps" targeted test

Pick one optimisation: say, "upstream validation eliminates the rework step", and model it as a removal of the rework task plus a frequency reduction on the validation step if it already exists. Look at both deltas. If cost-per-execution drops by 20% and critical-path time drops by 30%, the change is worth the implementation cost. If only cost-per-execution drops while critical-path time is unchanged, you are saving labour without shortening the process: a different kind of win.