What Does As-Is To-Be Really Mean? The Missing Meaning Behind “Business Improvement”
“As-Is / To-Be analysis” appears in almost every business improvement and DX project. In many workplaces, it is treated as a simple time-sequence comparison: before change (As-Is) and after change (To-Be).
But this common understanding misses something important. Originally, To-Be did not mean “a future extension of the present.” It meant transformation from a blank slate that questions whether the existing process should exist at all.
This article organizes the background of the term and why it so easily becomes hollow in practice.
Why Teams End Up with “As is to As”
In the To-Be design phase, these patterns are common:
- The more carefully teams interview the field, the more “the current way” starts to feel correct
- To-Be documents become only slightly cleaned-up versions of current process flowcharts
- Teams avoid touching organization structure and evaluation systems, and unconsciously settle within “feasible” scope
- Detailed As-Is analysis done first pulls all thinking back toward As-Is
As a result, what should be “before -> desired state” becomes “before -> slightly improved before” - in short, “As is to As.”
The Origin of As-Is / To-Be
The terms became established in the 1990s through the BPR (Business Process Reengineering) movement.
The trigger was Michael Hammer’s 1990 Harvard Business Review article. Hammer argued that the managerial challenge was not to automate work, but to eliminate work that creates no value. This became known through the striking phrase: “Don’t automate, obliterate.”
Three years later, Hammer and James Champy published Reengineering the Corporation, rapidly spreading BPR. The book defined BPR as fundamentally rethinking and radically redesigning business processes to achieve dramatic improvements in key performance measures such as cost, quality, service, and speed.
The key point: BPR assumed design from a blank sheet from the beginning. Not improving existing processes, but starting with the question: “Do we even need this process?” That was the original starting point of To-Be.
The Double Meaning of “To Be”
Looking at “As Is” and “To Be” grammatically reveals an interesting structure:
- As Is = short for “as it is” -> a description of the current state
- To Be = short for “as it is to be” -> a normative ought toward the future
“To be” can indicate not only existence, but also modal meaning like “is to be done” - necessity, duty, and purpose. In other words:
| As Is | To Be | |
|---|---|---|
| What it asks | What is happening now | What should be |
| Basis | Observation and facts | Purpose, value, reason for existence |
| Nature of change | None (description only) | Backcasting from norms (discontinuous) |
So To-Be is not “a later point in time.” It is “the state that ought to be.” In philosophical terms, this is close to the contrast between being (Sein) and ought (Sollen).
Why “Business Improvement” and To-Be Clash
This reveals a contradiction: the mindset inside the term “business improvement” and the mindset required by original To-Be are fundamentally different.
- Kaizen / business improvement: continuous, incremental improvement (as in TPS). It does not question the premise that the current process continues to exist.
- BPR’s To-Be: discontinuous, normative transformation. It starts by questioning whether existing processes are needed at all.
Analyses of BPR practice show that firms choose BPR when performance gaps become too large to close with incremental improvement alone. In other words, BPR was not for “making things somewhat better,” but for reaching places incremental improvement cannot.
Yet in many Japanese projects, As-Is / To-Be is imported into initiatives labeled “business improvement.” This mismatch creates the discomfort. The word “improvement” already implies “make what exists better,” and that framing itself weakens the ability to ask Be as an ought.
Lessons from What Happened to BPR
Another important point is what happened to BPR afterward.
After the 1990s BPR boom, many firms rushed in, but early surveys reported that over 70% of reengineering efforts made situations worse. Projects caused confusion, delays, and employee backlash; in some cases, BPR became a pretext for layoffs. Hammer, Champy, and early advocate Thomas Davenport later publicly reflected on these outcomes.
The lesson is clear: discontinuous “blank-sheet redesign” requires real commitment and careful consideration of the people involved in processes. If you are serious about To-Be, it is not just redrawing flowcharts; it is transforming structures that include organization and people.
Today, with AI-driven automation rising, BPR thinking is attracting attention again. Automating a broken process only creates a faster broken process. To make AI meaningful, the argument goes, you must first understand and redesign the process itself.
Conclusion: Question the Banner Before You Ask Be
As-Is To-Be is not originally a simple before/after timeline contrast.
- As-Is is a description: what is happening now
- To-Be is a normative ought: what should be, implying discontinuous transformation
If your current project’s To-Be is only “a slightly improved As-Is,” the issue may not just be how you draw To-Be. It may be worth questioning the project’s banner itself - the premise built into the term “business improvement.”
If you truly want transformation, what is required is not a gradual initiative called a “business improvement project,” but a redesign of scope and authority as business transformation and organizational redesign.