What-If Process Analysis: How to Compare Alternative Designs

Most process decisions get made in a conference room, based on a mix of experience, intuition, and whoever argues most persuasively. Someone proposes adding two people to a team, someone else proposes automating a data entry step, and someone else suggests changing how work gets routed between two departments. All three might be reasonable ideas. Without testing them against something concrete, the meeting usually ends with the loudest or most senior voice winning, not necessarily the option that would actually help the most.

What-if analysis replaces that debate with a comparison. Instead of arguing about which change would work best, you build a model of the current process, establish how it actually performs, and then test each proposed change against that same baseline to see what it would actually do to the numbers that matter: cycle time, throughput, utilization, and where the bottleneck sits.

Why a baseline has to come first

A what-if comparison is only meaningful if there is something stable to compare against. Without a documented baseline, every proposed change gets compared informally against someone's memory of how the process usually goes, which is an unreliable reference point because memory tends to average out variability and forget the exceptions. A locked baseline, built from an accurate model of the process as it runs today, gives every scenario the same starting point, so that any difference in the results comes from the change being tested and not from a shifting sense of what normal looks like.

This also protects against a subtle but common problem: comparing a proposed future state, described optimistically, against a present state, described pessimistically. It is easy to underestimate how well the current process copes on an average day and overestimate how smoothly a new idea will run once it meets real variability. A shared, measured baseline removes that asymmetry from the comparison.

The kinds of scenarios worth testing

A staffing scenario tests what happens to cycle time and throughput if a team gains or loses a person at a particular step, which is useful for justifying a headcount request or for confirming that a proposed cut would not create a new bottleneck. A routing scenario tests what happens if cases are split differently between teams, or if an approval threshold is raised or lowered, changing how many cases follow the longer path. A rework scenario tests what happens if a quality step upstream reduces the rate at which cases get sent back for correction, which often reveals more available capacity than adding staff would.

An Improve scenario tests a redesign that removes or simplifies a step without introducing new technology at all, such as combining two handoffs or removing a signoff that no longer serves a purpose. An Add AI scenario tests what happens if a specific step, one that involves judgment, language, or classification, is handled with the support of an AI agent instead of manually, based on assumptions the team supplies about how much time that step would take and how it would affect quality or rework. Comparing these scenarios side by side against the same baseline is what makes it possible to prioritize: some will show a meaningful improvement in cycle time or throughput, and some will barely move the numbers.

What the comparison actually shows

A well-built what-if comparison reports the same set of measures for the baseline and for every scenario: median cycle time, a slower-case figure such as the ninetieth or ninety-fifth percentile, throughput, utilization at each step, where the bottleneck sits, and an estimate of labor and value impact based on assumptions the team has reviewed and approved. Seeing these side by side makes tradeoffs visible that a narrative description would hide. A scenario might reduce median cycle time nicely while barely touching the slower cases, which matters a great deal if those slower cases are the ones driving customer complaints or compliance risk.

It is also common for a what-if comparison to surface an option nobody had proposed. Once a team can see that a particular step is the real constraint, and can see the effect of relieving it in different ways, cheaper or more targeted ideas often emerge that were not part of the original three proposals debated in the meeting room. A modest change to a scheduling pattern, for instance, might turn out to deliver most of the benefit that a larger staffing increase was expected to provide.

The answer is not always AI

One of the most useful outcomes of a what-if comparison is a negative result. If an Add AI scenario is tested against the baseline and the resulting improvement in cycle time is marginal compared to a much simpler routing or staffing change, that is valuable information, not a disappointing one. It means the organization can pursue the cheaper, lower-risk option with confidence, rather than assuming AI was the answer because it was the most discussed option in the room.

How Processfix supports what-if analysis

Processfix is built around exactly this comparison. A locked baseline is established using a discrete-event Monte Carlo simulation across hundreds of cases, and Improve and Add AI scenarios can then be built against that same baseline using an editable swimlane editor and objective-led recommendations. Each scenario reports P50, P90, and P95 cycle time, throughput, utilization, bottlenecks, and estimated labor and value impact, so a team can approve or reject a proposed change based on a measured comparison rather than a debate, and export the resulting case as a document to Word, PDF, or Markdown.