Two of the most commonly used concepts in process transformation are As-Is and To-Be.
As-Is refers to how the process runs today.
To-Be defines how we want it to work in the future.
The definition is simple. Designing a good To-Be process requires more than just drawing a new process diagram.
Why is As-Is necessary?
Designing a target process without understanding the current state increases the risk of solving the wrong problem.
The purpose of As-Is work is not to defend the current process.
The purpose is to understand:
- how the work is actually performed,
- why each control exists,
- where waiting occurs,
- which exceptions exist,
- which manual work is performed,
- how systems interact.
Interviews, workshops, process models, KPIs and reports, process mining and task mining can all be used together for this.
A To-Be process designed without understanding the As-Is may solve an assumed problem rather than the real one.
Is documenting the As-Is as it stands enough?
No.
As-Is work should look for answers not only to “what do we do today?” but also to “why do we do it this way?”
Some steps may be mandatory because of regulation.
Others may have been added as a solution to a past problem that is no longer relevant today.
This distinction determines the quality of the To-Be design.
How should To-Be be designed?
The first question should not be “which technology should we use?”
First, evaluate:
- Which steps can be removed?
- Which controls are necessary?
- Which decision points can be simplified?
- Which work can run in parallel?
- Are responsibilities in the right place?
- Which handoffs are unnecessary?
- Which manual work can be reduced?
- Which areas are suitable for automation?
- How will exceptions be managed?
Technology should support this design.
Should To-Be be as different as possible?
No.
There may be parts of the current process that already work well.
The goal is not to design the most radical process possible, but to design a process that solves the identified problem in a way that is workable and measurable.
To-Be design is not about moving the current process into a digital system; it is about keeping what is necessary and rethinking what is not.
How should controls and risk be treated?
Simplifying a process is not the same as removing controls.
If a control genuinely reduces risk, it should be preserved.
The real question is:
- is the control in the right place,
- is the same control being performed more than once,
- can it be automated,
- can it be applied on a risk basis?
How can Simulation / What-if help?
Before a To-Be design is implemented, the effect of different scenarios can be modeled.
For example, how might waiting time and total process duration be affected if an approval is removed, resource count is increased, activities are run in parallel or automation is introduced?
Simulation is not a precise forecast of the future; it helps compare alternatives before a decision is made.
Success criteria should be defined up front
Target indicators should be defined at the same time the To-Be process is designed.
Measures such as end-to-end time, waiting, errors, rework, manual effort, SLA, customer outcome and conformance can be defined from the start.
Only after implementation, when the new process is evaluated against these measures, can we understand whether it is genuinely better.
← All articles