As-is or to-be is the wrong shape of question
Almost nobody has to choose between mapping the current process and designing the future one. The real decisions are resolution, meaning how much current-state detail to gather and where to concentrate it, and sequencing, meaning what gets built before the future process has been agreed. Framed as a binary, the question produces both classic failures.
As-is means the process as it runs today. To-be means the process as it is meant to run after the change. Useful words, and the ones your consultant will use. The trouble starts when they are treated as alternatives, because that framing has only two exits. One is the wall above. The other is a future state designed in a room, configured into software, and killed on contact with the exceptions nobody wrote down.
A note on the numbers usually quoted at this point. Applying the Standish Group's definition of project success to 1,211 real projects rated the organisation with the worse forecasts as more successful, 67 per cent against 35 per cent, because the definition measures estimation accuracy rather than success (Eveleens and Verhoef, IEEE Software, 2010). The companion figure, that 70 per cent of change programmes fail, was traced across its five published origins by Mark Hughes in 2011, who found "no valid and reliable empirical evidence to support such a narrative." So this article argues from mechanism rather than failure rates.
Why the current state is harder to establish than it sounds
This explains why as-is work costs what it costs, and why skipping it is tempting.
There is a well studied gap between how work is described and how work is performed. Safety science calls the two sides work-as-imagined and work-as-done, and its claim is stronger than "people forget things." Erik Hollnagel puts it this way: "It is impossible, in practice as well as in principle, precisely to prescribe how work should be done," partly because "plans and procedures are typically developed away from the actual place of work and by people who do not have up-to-date knowledge about how everyday activities take place" (HindSight 25, EUROCONTROL, 2017).
Steven Shorrock's refinement is the practically useful one. He splits the gap four ways: work-as-imagined, work-as-prescribed, work-as-disclosed, and work-as-done. Work-as-disclosed is what people say and write about their work, and it names precisely what a mapping workshop produces. That is genuinely valuable, and it is not the same artefact as a record of what happens. His framework is a practitioner one rather than peer-reviewed research, and the same finding arrives from requirements engineering: "problem domain experts often have large amounts of tacit knowledge that is not amenable to introspection; hence their answers to questions posed by requirements analysts may not match their behavior" (Nuseibeh and Easterbrook, ICSE 2000).
Process mining exists in large part because of this gap. Wil van der Aalst's framing is blunt: most approaches start from hand-made models rather than factual event data, and "these models may be of low quality and have little to do with reality" (IEEE CIDM, 2011). What the data shows when someone looks is variety. Across twelve public real-life event logs, the number of distinct paths as a percentage of recorded cases ranged from 0.2 per cent in a traffic fine process to 80.6 per cent in a sepsis log (Augusto and colleagues, IEEE Transactions on Knowledge and Data Engineering, 2019). The filtered Dutch municipal building permit logs sat between roughly 33 and 62 per cent. This is a measure of path variety, not the share of cases that followed a path nobody else followed. Both ends matter. Some processes repeat a small set of paths. Others contain far more variation. When researchers mined 14,279 invoice cases at a Dutch public works office, the mined model showed looping behaviour that "cannot be deduced from the predefined process model which, by its very nature, lacks information on actual behavior," and over 17 per cent of invoices involved at least one undesired subcontracting step (Information Systems, 2007).
Worth saying plainly: no published study I can find reports how closely as-is models drawn in a normal documentation exercise match the event data at scale. The figures circulating on that question come from vendors. The literature supports the direction, not a multiplier. A map built from a workshop is a map of what people believe happens, and the gap in cost between that and a map of what happens is most of the argument here.
What as-is work is actually for
The decision is not whether to map the current state. It is whether any of these jobs need doing. Each is a reason. If none apply, the mapping is decoration.
Diagnosis. Nobody can name the operating problem precisely. Without the current state, the redesign is a guess about which step is broken.
Divergence. Different people describe the same process differently, and that divergence is itself the finding. It cannot be recovered later, because a future-state workshop manufactures consensus about tomorrow while concealing disagreement about today.
Baseline. Somebody will eventually ask whether the work paid off. Without a before, that question has no answer and the project's value becomes a matter of opinion.
Buy-in. Showing people their own process, on a wall, is more persuasive than any argument about why it needs to change. As-is is a political instrument as much as an analytical one, and that is a legitimate reason to do it.
Load-bearing workarounds. This is the expensive one to skip. Informal fixes accumulate around any process, and the research is clear they are not all noise. Ferneley and Sobreperez separated the hindrance workaround, taken to dodge a step people find onerous, from the essential workaround, without which the task cannot be completed at all (European Journal of Information Systems, 2006). Alter's synthesis notes that some become institutionalised in routines that endure for years (2014). David Woods states the consequence exactly: organisations "can inadvertently undermine their own sources of resilience as they miss how people step into the breach to make up for adaptive shortfalls" (Reliability Engineering & System Safety, 2015). Design a future state without knowing which inefficiencies are compensating controls, and some get removed, and the process gets worse in a way nobody predicted and everybody feels. A review of 58 studies of nurses' workarounds found the balanced version: they "enable, yet potentially compromise" the work (Debono and colleagues, 2013).
Compliance, audit and risk. Some work requires a record of what is actually done rather than what is supposed to be done. Where that applies, the current state is a deliverable in its own right and not a means to a redesign.
Migration. When a system is replaced, the undocumented edge cases the old one quietly handles are what breaks the cutover. The canonical statement is more than twenty-five years old and has not aged: in legacy systems "documentation and understanding of system details is often lacking," and cutting over in a single step "puts the organization's whole information flow in an untried and thus untrusted system" (Bisbal and colleagues, IEEE Software, 1999). Business rules are the worst of it, poorly documented and incompletely understood even by the people who own the system (Earls, Embury and Turner, 2002). Current-state work here is a risk register wearing a different name.
When to compress the current state, or skip it
An article that lists reasons to do as-is work and no reasons to skip it is a sales document for as-is work. So, plainly.
The process does not exist yet. A new service line, a new function, a new team. Documenting what we do now for something done ad hoc three times is documenting noise, and giving noise the authority of a diagram makes it harder to change later.
It is being replaced wholesale, and that decision is made and irreversible. Detailed current-state work here is archaeology. It compresses to one question: what does the current process handle that the new one must also handle. That is a risk scan, not a map.
For a simple, low-risk process, a consistent account checked against the work may be enough. Writing it up formally can add a document rather than knowledge. Agreement in a workshop alone is not proof that nothing has been missed.
The mapping costs more than the process is worth. Low volume, low risk, low cost. Three weeks on something that runs twice a month is a bad trade and deserves to be named as one.
The change is cheap to reverse. For a low-risk process, designing something reasonable, running it and learning from what breaks beats analysing it first. Analysis earns its place when reversal is expensive.
And the one worth saying out loud: it is being used to avoid deciding. Organisations commission current-state mapping because it looks like progress and defers a decision nobody wants to own. Feldman and March put the general case in 1981: organisations "systematically gather more information than they use, yet continue to ask for more," because information carries symbolic weight beyond its value to any decision. The map becomes the deliverable and the decision never arrives.
The counterweight belongs here too. Kathleen Eisenhardt's study of eight firms in fast-moving markets found that the executives who decided fastest used more real-time information and considered more alternatives at once, not fewer (Academy of Management Journal, 1989). Analysis is not inherently what slows a decision down. Analysis commissioned in place of a decision is.
How much current-state detail is enough
Current-state work is not one thing, and this is the idea worth keeping.
It runs from a single-page sketch validated in one workshop, through a walkthrough with the people who do the work, to a full map carrying exceptions, data, systems, controls and volumes. Those are different products at different prices, and the price of the last one is not only the mapping. It is the maintenance. Published model collections run to 6,000 models at a single insurer, and managing collections at that size is a recognised research problem in its own right (Dijkman, La Rosa and Reijers, Computers in Industry, 2012). Detail nobody can maintain becomes wrong detail, which is worse than no detail, because people trust a diagram. Most of the common obstacles with BPMN documentation start there.
The right answer is almost always uneven. Deep where the problem is suspected, thin everywhere else, absent where the process is about to be replaced. Most plans map at a uniform depth across the whole scope, which is simultaneously too much detail where nothing is wrong and too little where everything is.
So the question worth asking of any plan is not whether it includes current-state mapping. It is where the detail is concentrated, and why there.
A concession is owed here. When academics, practitioners and vendors were asked in a Delphi study to name the field's critical unresolved issues, identifying the value proposition of business process modelling came top three (Indulska, Recker, Rosemann and Green, CAiSE 2009). The evidence cited here does not establish that projects investing heavily in current-state analysis outperform projects that do not. A percentage claiming otherwise needs its own evidence, not just a vendor assertion. The argument above rests on mechanism and on the cost of specific failures, which is the honest place to rest it.
The same decision, applied to what gets built
Documentation and implementation are the same decision made twice, and the second time it is more expensive to get wrong.
When a system is configured, it is configured to a process. Either the one that happens today or the one that should happen tomorrow. Very few projects make that choice explicitly, and the default is whichever the person doing the configuration assumed. That is not a decision, it is a side effect.
Configuring to the current state buys adoption, because people recognise the work. It also encodes the dysfunction, and an encoded process is markedly harder to change than an informal one. The company has paid to make its problem permanent.
Configuring to the future state buys the improvement and risks rejection. Misfit is not the mark of a bad project, it is structural: packaged software is "designed to support generic rather than specific requirements, and hence [is] likely to be an imperfect fit in any particular instance" (Strong and Volkoff, MIS Quarterly, 2010). Their distinction is the useful one for a buyer. A deficiency is the system not doing something the work needs. An imposition is the system requiring something the organisation did not previously do. Impositions are where the change and training cost lives, and it is almost never in the budget.
There is a diagnosis problem underneath this. In four SME implementations studied in the Information Systems Journal, firms preferred to adjust the system to their processes and "often unnecessarily change the system to solve perceived misfits" that were not actual misfits (van Beijsterveld and van Groenendaal, 2016). The customisation instinct fires before anyone has checked whether the gap is real, a current-state question arriving too late.
The sequencing rule is the load-bearing point, and it is short. A future state cannot be implemented before it has been agreed. Software bought or configured ahead of that agreement produces the familiar outcome: a system nobody uses, because there was no process behind it. A client of mine had bought a CRM and barely anyone used it. We designed the workflow first, then built the automations behind it, covering assignments, status triggers, escalations and reporting views. Then we documented it and trained the team so it held after handover. The software had never been the problem. It was the document without the system, in reverse.
The honest middle path is to build the future state where it has been agreed and has an owner, and where it has not, to build the current state deliberately, record it as a known compromise, and give it a date. That is different from drifting into it by accident, and the difference is whether anyone ever revisits it.
Two trade-offs are worth naming. The correct implementation is sometimes seventy per cent of the ideal future state, because the last thirty per cent would break adoption, and a perfect process people route around delivers nothing. And not every process needs redesigning. When the process is sound and the only problem is that it is done by hand, automating it as it stands is the right answer and redesign is scope creep.
The trap on the other side is the one everybody half-remembers as a quotation from a famous technology executive. I went looking for the primary source and could not find one, so here it is without the borrowed authority. Automating a process that does not work produces bad outputs faster, more consistently, and with less visibility than before. And it is now encoded, so changing it has become a project rather than a conversation.
When neither map helps
Neither a current-state map nor a future-state design fixes a process that has no owner.
Michael Hammer's version has not been improved on: "There has to be an owner, a senior executive who has the responsibility and authority to ensure that the process delivers results; otherwise, it will fall between the cracks" (Harvard Business Review, 2007). That is expert consensus from a consortium-built framework rather than an outcome study, and the counterweight is real: a systematic review of business process maturity models found only 7 of 61 studies offering empirical evidence on the maturity to performance link, with several leading models never empirically validated at all (Tarhan, Türetken and Reijers, 2016). Survey evidence suggests ownership alone is not enough either. In Austrian manufacturing firms, process ownership without process performance measurement was not associated with the same performance benefits (Kohlbacher and Gruenwald, 2011).
The evidence cited here does not establish whether documentation with an accountable owner stays current longer than documentation without one. What is documented is the mechanism that would make it decay: organisations largely lack any way to detect that a process has changed, so models go out of date without anyone noticing (Avila and colleagues, Business Process Management Journal, 2025). Both maps can become outdated after delivery. Keeping them current needs an accountable person and a way to notice changes, not just an artefact. That is also why documentation alone does not create consistency. Where ownership is the real problem, mapping is an expensive way to discover it.
The idea
The plan on the table probably allocates weeks to the current state and weeks to the future state, and the split was probably arrived at by habit. It is worth treating as a decision, because both defaults are expensive in different directions and neither announces itself.
The current state earns its budget where it answers a question somebody actually has: which step is broken, where accounts diverge, what the baseline was, which inefficiencies are holding the thing up, what the new system must still handle. Where it answers none of those, it is a beautifully rendered description of a Tuesday.
The future state earns its budget only once somebody has agreed to it. Everything built before that agreement is a bet that the room was right about work it had only heard described.