As-Is vs To-Be: Why Skipping the Ugly Current-State Map Costs You Later

Skipping the as-is process map costs you later because the exceptions, workarounds, and manual patches nobody documents are exactly what breaks automation after launch. A to-be design built on a wishful current-state picture inherits every hidden dependency it never accounted for, and those surface as production incidents, not planning risks.

Quick Answer: The as-is map is not a formality before the "real" work of designing the to-be state — it's the risk inventory. Skip it and you're automating the process people wish they had, not the one that actually runs, exceptions included.

Why Teams Skip the As-Is Map (and Why That's Backwards)

Teams skip the as-is map because it's slow, political, and unglamorous compared to whiteboarding an exciting future state. The instinct is understandable: stakeholders want to talk about the destination, not catalog today's mess, so workshops jump straight to "how should this work."

That instinct inverts the actual risk profile of the project. The to-be state is where everyone already agrees — nobody objects to "approvals happen in one system" or "handoffs are automatic." Disagreement, ambiguity, and cost hide in the current state, in the parts of the process that don't match the org chart or the documented SOP.

A few reasons the as-is map gets shortchanged in practice:

• It's uncomfortable. Mapping the real process exposes shadow spreadsheets, unofficial approvals, and workarounds that make people who built them look bad.
• It feels like it doesn't move the project forward. Stakeholders want to see progress toward the solution, not documentation of the problem.
• Nobody owns the full picture. Each participant knows their slice; the end-to-end view requires stitching together perspectives nobody has combined before.
• It's assumed to be "already documented." Existing SOPs and org charts get treated as ground truth when they usually describe an idealized or outdated version of the work.

This is the same failure mode /blog/bpmn-primer-map-before-automate addresses from a notation angle: BPMN gives you the symbols, but symbols only capture reality if someone insisted on observing it first. Mapping before automating only works if the map is honest.

What the As-Is Map Actually Needs to Capture

The as-is map needs to capture the process as it is actually executed, including every exception, workaround, and informal handoff — not the version described in the SOP or org chart. If it only reflects the documented happy path, it isn't an as-is map; it's a restatement of the to-be intent with a different label.

A usable as-is map includes:

1. The literal sequence of steps, including ones nobody would put in a training deck (a manager eyeballing a spreadsheet before "approving" in the system, a second unofficial check someone added after a past incident).
2. Volume and frequency by path, not just the existence of a path — a rare exception handled twice a year matters less than one hit on 30% of cases.
3. Who actually does the work, as opposed to who is nominally responsible — the RACI chart and the real doer frequently diverge.
4. The systems and artifacts actually touched, including the shadow spreadsheet, the personal email thread, the sticky note.
5. The triggers for deviation — what specifically causes someone to leave the documented path, and how often that trigger fires.

Michael Hammer's process-reengineering work (the source of much modern BPM practice) made a related point decades ago: organizations routinely automate a broken process and end up with a faster broken process. The as-is map is the only defense against that outcome, because it's where "broken" gets named before it gets paved over.

The Documented Process vs. the Lived Process

The documented process and the lived process diverge wherever real-world variability wasn't designed for — new customer types, system outages, edge-case volumes, or simply time pressure. That gap is not noise to average out; it's the primary input to a credible to-be design.

Gartner's research on process mining (a discipline built entirely around extracting the as-is state from system logs rather than trusting stakeholder narration) has repeatedly found that the process people describe in interviews and the process reconstructed from actual event data differ substantially, often in the sequencing and frequency of exception paths. If a rigorous, log-based discipline exists specifically because self-reported process descriptions are unreliable, that should recalibrate how much confidence any team puts in a single workshop's account of "how it works."

A Technique for Eliciting Undocumented Exceptions

The technique for eliciting undocumented exceptions is to interview for the last time the process broke, not for the general steps — specific, recent failure recall surfaces workarounds that generic "walk me through it" questions never do. People underreport exceptions when asked abstractly but recall them vividly when asked concretely.

Run it as a structured pass, not a single question:

• Ask for the last three exceptions, by name. "Tell me about the last time this process didn't go as planned" produces a specific, checkable story. "What are the exceptions to this process?" produces a shrug or a sanitized list.
• Ask who they call when it breaks. The informal escalation path — the person everyone quietly Slacks — is usually undocumented and usually load-bearing.
• Ask what they'd never let an intern do without supervision. This surfaces judgment calls that resist codification, which matters directly for deciding where automation is safe.
• Ask for the workaround they're slightly embarrassed by. Framing it as normal, not as a confession, gets people to volunteer detail they'd otherwise omit.
• Cross-check against system logs or timestamps where available. Even partial system data (ticket timestamps, approval logs) can confirm or contradict a stakeholder's account of frequency.
• Repeat with at least two people per role. A single interviewee describes their own adaptations; a second person in the same role often reveals a different set, which tells you the process isn't standardized even informally.

This maps closely onto the "critical incident technique" used in qualitative research and onto Jobs-to-be-Done interviewing, where researchers anchor on a specific past purchase or usage moment rather than general preferences — a full treatment of that interviewing discipline lives in /blog/jobs-to-be-done-complete-guide. The underlying principle is identical: specificity defeats the tendency to describe an idealized version of events.

Prodinja's Journals are built around this same idea — they capture the real exceptions people mention in passing, in their own words, so a truthful as-is map gets built from what people actually say happened rather than a cleaned-up retelling assembled after the fact in a workshop.

Gap Analysis: Linking As-Is Pains to To-Be Moves

A gap-analysis table links each as-is pain directly to a specific to-be design move, so nothing in the future state exists just because it looked good on a whiteboard. Every to-be decision should be traceable back to a pain it resolves, and every documented pain should have a corresponding decision, even if that decision is "accept the risk."

The table's real value is what it prevents: a to-be state that quietly drops the second approval or the senior-analyst escalation because nobody wrote it down as a requirement. /blog/human-handoff-step-design goes deeper on deciding, case by case, whether a step like that stays human, gets automated, or becomes a hybrid checkpoint — a decision this table is what makes visible in the first place.

Turning the Gap Table Into Sequencing Decisions

Turning the gap table into sequencing decisions means ranking each row by frequency times impact, then designing the to-be move for the highest-value rows first rather than the easiest ones to build. Effort estimates without a frequency-weighted pain score routinely lead teams to automate the rare edge case because it's technically interesting, while the frequent, boring reconciliation step stays manual.

A workable sequencing pass looks like this:

1. Score each row on frequency (how often it happens) and impact (cost, risk, or delay when it does).
2. Flag any row where the root cause is unclear — those need more discovery, not a design decision yet.
3. Group rows by whether the fix is a rule, a role, or a system change — this determines whether /blog/rules-rpa-or-agent-per-step applies, since a fixed rule, an RPA bot, and an agentic step suit different kinds of gaps.
4. Sequence the to-be rollout so the highest frequency-times-impact rows land in an early release, not the last one.

Common Failure Modes When Teams Skip This Step

The common failure modes when teams skip as-is mapping all share one trait: the automation works perfectly for the documented happy path and fails, often visibly, on the volume of cases that were never the happy path to begin with. These failures tend to surface weeks after launch, not during testing, because test scripts are usually written against the same idealized process description that skipped the as-is step.

• Exception volume gets discovered in production. The team assumed exceptions were rare; the automated system chokes because they were 20% of cases all along.
• The workaround nobody documented becomes a silent gap. The step someone quietly added after a past incident vanishes in the redesign, and the incident it prevented recurs.
• Stakeholders disagree after go-live, not before. Skipping the honest as-is conversation just moves the disagreement later, where it's more expensive to resolve.
• The rollout requires an emergency "phase 1.5." A patch release addressing exceptions that a thorough as-is map would have caught during design.

This is a specific instance of a broader pattern covered in /blog/workflow-automation-complete-guide: automation projects fail less often from bad tooling choices and more often from bad process understanding going in. The map is the cheapest place to catch that.

How Prodinja Supports an Honest As-Is Map

Prodinja supports an honest as-is map primarily through Journals, which are designed to capture the informal, in-passing mentions of exceptions and workarounds as people naturally describe them, rather than requiring a formal documentation exercise that tends to produce the sanitized version. A Journal entry logged in the moment — "had to loop in finance manually again because the system flagged it wrong" — is closer to raw as-is signal than a retrospective workshop answer.

That's a deliberate design choice, not a claim about outcomes: Prodinja is currently an interactive prototype, and Journals are a real, working feature built to make this kind of capture lower-friction, not a promise about what any specific team will uncover. The gap-analysis and sequencing work above still requires a PM to actually run it — Prodinja's role is making the raw material easier to collect and easier to keep honest.

Key Takeaways

• The as-is map is a risk inventory, not a formality — the future state is where everyone already agrees; the current state is where the real disagreement and cost hide.
• A usable as-is map includes exceptions, real doers, and shadow systems, not just the documented happy path from an SOP or org chart.
• Interview for the last specific failure, not the general process — concrete recall surfaces workarounds that abstract questions miss.
• Cross-check stakeholder accounts against system data where possible — process mining research consistently finds gaps between the narrated process and the logged one.
• A gap-analysis table should link every to-be design move to a specific as-is pain, so nothing gets included or dropped without a traceable reason.
• Sequence the to-be rollout by frequency times impact, not by which fix is most interesting to build first.
• Automating a broken process just produces a faster broken process — a lesson from classic process-reengineering work that still applies to modern workflow automation.

Frequently Asked Questions

What is the difference between as-is and to-be process mapping?

As-is mapping documents the process exactly as it currently runs, including exceptions and workarounds; to-be mapping designs the intended future process. The as-is map is diagnostic — it identifies what's actually happening and why — while the to-be map is prescriptive, describing the target state the redesign aims for.

How long should as-is process mapping take?

As-is mapping typically takes one to three weeks for a moderately complex process, depending on how many roles and systems are involved and how much stakeholder disagreement surfaces. Rushing it below that window is the most common reason exceptions get missed, since specific-failure interviewing (per role, with cross-checks) takes real calendar time to schedule and synthesize.

Why do stakeholders resist detailed current-state mapping?

Stakeholders resist detailed as-is mapping because it can expose workarounds, shadow systems, or informal escalations that make their team's process look less controlled than the official documentation suggests. Framing the exercise around finding risk to design around, rather than finding fault, reduces this resistance considerably.

Can you skip the as-is map for a simple process?

A simple process with low variability and no history of manual exceptions can sometimes move to a lighter as-is pass, but "simple" should be verified through the specific-failure interview technique before being assumed. Many processes that look simple on paper carry undocumented exception volume that only surfaces once someone asks the right question.

How does process mining relate to as-is mapping?

Process mining reconstructs the as-is state from system event logs and timestamps rather than relying solely on stakeholder interviews, which is why research in that field consistently finds gaps between the narrated process and the logged one. It's a strong complement to interviews where system data exists, though it can't capture exceptions that never touch a logged system.