As-Is vs To-Be Process Mapping

Two maps get produced in most serious process improvement work: one describing how the process runs today, and one describing how it is meant to run after changes are made. They are usually called as-is and to-be. The distinction sounds obvious until you watch a project where someone skips straight to the to-be map, sketches an ideal-looking flow, and presents it as if it were grounded in fact. It rarely survives contact with the people who actually do the work.

What each map is for

The as-is map exists to establish a shared, evidence-based account of current reality. Its job is accuracy, not elegance. If the current vendor onboarding process really does involve three separate spreadsheets, a manual credit check, and an email chain to chase missing tax documents, the as-is map should show all of that, including the parts that look inefficient or embarrassing. Sanding down the rough edges at this stage defeats the purpose, because those rough edges are usually exactly what the improvement effort needs to target.

The to-be map exists to describe a proposed change and make its consequences visible before anyone commits resources to building it. For vendor onboarding, a to-be map might show the credit check moved earlier in the sequence, or two approval steps merged into one, or an AI-assisted step drafting the onboarding checklist for a human to confirm. The to-be map is explicitly a proposal. It should read differently from the as-is map, not just as a cleaner version of the same picture, and everyone looking at it should understand that its accuracy depends on assumptions that have not yet been tested in production.

Why the as-is has to be locked first

If the as-is map is still being argued over while the to-be map is being drafted, the project loses its ability to say what actually changed. A locked as-is baseline gives everyone a fixed point to measure from. Locking does not mean the as-is is perfect. It means the team has agreed this is the version they will treat as ground truth for the duration of the comparison, even if minor details later turn out to be slightly off. Without that discipline, every disagreement about the future state turns into a disagreement about the present state, and the two get impossible to untangle.

Jumping straight to to-be is tempting because it feels more productive. Mapping the current mess of vendor onboarding is tedious; sketching a cleaner version is satisfying. But a to-be map built without a documented as-is is really just an opinion about how the process should work, dressed up as an analysis. It tends to omit the exceptions and workarounds that made the current process complicated in the first place, which means the proposed future state quietly reintroduces the same problems once it meets real cases.

Comparing as-is and to-be

Presenting the delta to stakeholders

The most useful artifact in this whole exercise is often not either map alone but the difference between them. When you present a change to a sponsor or a steering group, showing the as-is and to-be maps side by side, with the specific steps that were added, removed, merged, or reassigned called out explicitly, does more to build confidence than either map on its own. It also forces the team proposing the change to be precise about what is actually different, rather than gesturing vaguely at improvement.

For vendor onboarding, a delta view might show that the credit check step moved from position six to position two, that two manual approval steps were merged into one with a clearer escalation rule, and that everything else in the process stayed the same. That level of specificity lets a stakeholder ask a sharp question, such as whether moving the credit check earlier creates a new dependency on data that is not always available at that point in the process. Vague to-be maps invite vague approval. Specific ones invite specific, useful scrutiny.

Common mistakes when building an as-is map

The most frequent mistake is letting the process owner describe the process from memory instead of walking through real cases. Memory tends to describe the happy path, the version of the process that exists in policy documents, not the version that actually runs when a document is missing or a system is down. A second common mistake is stopping the interview once the map looks tidy. A tidy-looking as-is map is a warning sign, not a sign of good work, because real processes accumulate workarounds and exceptions that rarely draw a straight line. A third mistake is mapping only the steps a single department controls and leaving the rest as a black box, which quietly hides the handoffs where most delay and rework actually occurs.

A subtler mistake is confusing consensus with accuracy. If three people in a workshop agree on how a step works, it is tempting to write it down and move on. But agreement in a room does not always match what happens at a desk. Cross-checking the workshop account against a handful of real cases, whether that means pulling actual tickets, invoices, or applications and tracing them through the steps, catches gaps that a group discussion alone will miss.

A worked example: vendor onboarding

Say the stated process is: procurement receives a request, checks the vendor is not a duplicate, sends a document request to the vendor, legal reviews the contract, finance runs a credit check, and the vendor is activated. That is the version most people describe from memory. Tracing ten real onboarding cases usually turns up more: some vendors submit incomplete documents and the request bounces back twice before legal will even look at the contract, some credit checks stall for a week because finance only runs them in a weekly batch, and a handful of vendors get activated without a credit check at all because someone in procurement flagged them as low risk and skipped the step informally.

None of that appears in the tidy five-step description, but all of it belongs on the as-is map, including the informal skip, because it is genuinely happening and it changes how the process performs. Once that fuller picture is locked as the baseline, a to-be map proposing to run the credit check earlier, or to auto-validate documents before they reach legal, can be evaluated against what the process actually does today, not against a simplified story about it.

When a lighter as-is is defensible

Locking a full as-is baseline is not always worth the effort. For a low-volume, low-risk process, or a brand-new process that has never run before, spending days documenting current-state reality can cost more than it returns. In those cases a lighter pass, a quick walkthrough with the process owner and a short list of known pain points, is usually enough to move to a to-be discussion. The key is to make that choice deliberately and say so, rather than skipping the as-is step by default and discovering later that nobody actually agrees on what changed.

Processfix and baseline comparisons

Processfix is built around exactly this separation. A process gets mapped into a swimlane editor and locked as the baseline, and any improvement or AI-assisted scenario is modeled as a separate version compared against that baseline using discrete-event simulation across a set of representative cases. That comparison covers things like cycle time percentiles, throughput, and utilization, so the delta between as-is and to-be is expressed in terms the team can debate. All of it remains an estimate based on the process model and the assumptions entered, not a verification of what will actually happen once implemented.