I recently took part in a project involving a major transformation in the way we work, and, as is often the case, the first meeting was full of energy: vision, ambitious goals, big words, and a nice diagram of the “future state” on the whiteboard. They had sketched out how certain processes would look in the future (thanks to a tool that was going to be implemented) without taking into account how those processes actually worked today. And this isn’t the first time I’ve seen this: the temptation to jump straight to the to-be is enormous, because designing the future is much more exciting than documenting the present. It was even mentioned during the meeting that there was no need to know how we worked today, because, after all, we weren’t going to keep working that way anyway.
The problem is that a to-be without a solid as-is is almost an act of faith.
Why We Skip the “As-Is”
Understanding how processes actually work (not how the manual says they work, but how people actually carry them out every day) is a thankless task. It requires interviewing, observing, cross-checking different versions of the same story, and, often, making someone uncomfortable by pointing out an inefficiency that’s been there for years. In contrast, mapping out the desired future is easy, rewarding, and doesn’t create friction with anyone. On paper, almost anything is possible. That’s why many organizations, pressured by deadlines and the need to show progress, rush to define the to-be state without having finalized the as-is state.
The result is predictable: an elegant solution is designed for a problem that isn’t exactly the one that exists. Exceptions that were actually the rule get automated. An “unnecessary” step is eliminated—one that, though undocumented, was the very step that handled all the extraordinary cases. The new process works perfectly in the demo but breaks down in the first week of actual production, causing frustration and tension among the people who have to carry it out.
The human factor—the part that almost never appears in the diagram
This is where I’ve most often seen transformations fail: the as-is isn’t just the flow of activities; it’s also who carries it out, why they do it that way, and what it would cost them to stop doing it.
Every real-world process is full of informal adjustments that people have gradually incorporated to make things work: the parallel Excel spreadsheet that no one officially acknowledges, the phone call that prevents a bottleneck in the system, the unwritten rule applied by the most experienced person on the team. That tacit knowledge is rarely found in any procedures manual, and yet it underpins a large part of the operation. If we don’t capture it when mapping the as-is state, we lose it when designing the to-be state—and with it, we lose resilience.
Furthermore, the people executing the process today are, almost always, the same ones who will have to adopt tomorrow’s process. If they haven’t participated in describing how they actually work, it’s difficult for them to feel ownership of the future state that others have designed for them. The resistance to change that is so often attributed to “culture” or a “lack of commitment” has, in many cases, a much simpler origin: no one asked them what their day-to-day work was like before deciding to change it.
What happens when one of the two extremes is missing
- Without a clear “as-is” picture: solutions are designed for a misunderstood problem, the migration effort is underestimated, “surprises” arise midway through the project that were actually predictable, and shadow processes emerge because the new system doesn’t account for cases that were common in practice.
- Without a clear “to-be” state: the current-state assessment becomes an endless exercise in pointless documentation; the focus on what to improve and why is lost; and the organization ends up investing effort in describing in detail processes that aren’t even worth keeping.
Both extremes are equally dangerous. An aimless as-is analysis is archaeology; a to-be vision without a foundation is science fiction.
Is it really necessary?
Can we drive to a destination without knowing where we’re starting from? Having the as-is processes provides us with an undeniable advantage—both for managing the implementation plan and its execution, and for change management. Some advantages include:
- Realistic diagnosis: Without understanding the current state, you cannot accurately identify pain points, bottlenecks, inefficiencies, redundancies, risks, or waste. Designing a “To-Be” state without this knowledge often results in solutions that look good on paper but fail in implementation.
- Measurement baseline: The “As-Is” provides the baseline (starting point) for defining clear KPIs and measuring the actual impact of the transformation. How will you know if you’ve improved if you don’t know where you started?
- Leveraging what already works: Often, there are processes, controls, or practices that are indeed effective. A good “To Be” state builds on what’s good and eliminates or redesigns what’s bad. Ignoring the “As Is” state creates the risk of “throwing the baby out with the bathwater.”
- Change management and buy-in: The people who operate the current processes know the day-to-day realities better than anyone. Involving them in the “As Is” analysis builds trust and reduces resistance to change.
- B Identifying constraintsB : Technological, regulatory, cultural, resource-related, or contractual constraints that limit the options for the “To Be” state.
While it’s true that in some cases, it can be said to be less necessary (though never indispensable). Some of these exceptions might include:
- Radical transformations or greenfield projects: When a new business, product line, or entirely new operating model is created. For example, a digital-native startup or a business spin-off.
- Disruptive reinvention: In cases where the as-is state is so obsolete or broken that continuing to analyze it leads to “analysis paralysis.”
- Very aggressive high-level mandate: When senior management decides on a drastic change—such as the mandatory adoption of a new ERP platform—and prioritizes speed over fine-tuning.
But even in these cases, having some level of as-is analysis (even if it’s light) will give us an advantage.
Being pragmatic, the level of depth of the as-is analysis should be proportional to the scope of the project:
- Small or highly focused projects → Light analysis (key interviews + high-level mapping).
- Large or complex transformations → In-depth analysis (detailed mapping, time/cost measurement, variability analysis, voice of the customer, etc.).
As a rule of thumb, we can say that the more ambitious the to-be state is (digitization, automation, change in operating model), the more critical a deep understanding of the as-is state becomes.
How I’ve Seen It Work Well
The transformations I’ve seen progress most successfully share a common pattern: they devote real time (not just a couple of quick workshops) to understanding the current state, and they involve those who actually execute the process in that exercise—not just those who oversee it. The goal isn’t to produce a perfect 200-page document, but to generate a shared, sufficiently honest understanding of what works, what doesn’t, and why things are the way they are today.
Only with that foundation does it make sense to ask where we want to go and how to get there. And when the time comes to design the to-be state, it’s best to continue relying on those same people—not as validators of a design that’s already set in stone, but as part of the team helping to build it. Change is embraced much more readily when those who will experience it have had a say in how it was conceived.
Have the Map Before Plotting the Route
Ultimately, thinking about the to-be without knowing the as-is is like planning a mountain route without knowing where you’re starting from. You may have a crystal-clear picture of the destination, but if you don’t know where you are, any path you plot will be, at best, a lucky guess. Knowing the terrain—with its informal shortcuts, its swampy areas, and the people who already know which paths to avoid—is what turns a good intention into a plan that can actually be executed.
Understanding the as-is situation isn’t a bureaucratic step—it’s the foundation of a successful transformation. Skipping this step is one of the most common causes of failure in process redesign and business transformation projects.