Your as-is workshop took three weeks. Your to-be deck is still 'in review.' The gap between the two states is not an analysis problem. It is a translation problem.
Someone captured the current state. A deck was produced. It entered a review cycle. Stakeholders disagreed on the future state. The gap analysis — the actual deliverable — never materialised. The to-be map died in the same meeting it was supposed to come out of.
Bad processes cost organisations around 30% of annual revenue. Most of that cost sits unaddressed in the space between what currently happens and what should happen. The gap report is not a milestone on the way to improvement. It is the improvement. And most teams never produce one.
What As-Is and To-Be Process Mapping Actually Mean
As-is process mapping documents what actually happens. Not what the procedure manual says. Not the ideal flow. The full sequence of steps, decisions, and handoffs that occur today — including the workarounds, the informal approvals, and the waiting.
To-be process mapping defines the approved future state: what should happen once waste is removed, steps are consolidated, and the process is designed for its actual purpose.
The gap between them is a structured list of changes. Steps to eliminate. Steps to merge. Decisions to formalise. Handoffs to redirect. That list is the gap analysis. Producing it is where most process improvement efforts stall — sometimes indefinitely.
Why the Gap Analysis Never Arrives
The as-is map survives every meeting. The to-be map dies in them. The reason is structural, not political.
As-is mapping is descriptive. Stakeholders agree because they are confirming what already exists. To-be mapping is prescriptive. Every proposed change has an owner who must accept it. Every eliminated step belongs to a team that currently performs it.
A workshop can produce an as-is in a day. The to-be requires consensus, sign-off, and a model clear enough for every owner to commit to. That takes weeks. Usually because the model lives in someone's head, not in a shared, auditable document.
The fix is not a faster workshop. It is a different model of capture: one where the gap analysis emerges from the session, not after it.
How ESSAM Produces Both Views in One Session
ESSAM captures processes conversationally. No notation software. No pre-formatted templates. No export queue.
A process owner describes the current state in plain language. ESSAM maps it, auto-tags waste against eight MUDA types, and produces a baseline model. That is the as-is view — captured in minutes, not weeks.
From that baseline, ESSAM applies the E-S-S-A-M sequence:
- Eliminate — steps that should not exist in the to-be at all.
- Simplify & Standardise — steps that should be consolidated, clarified, or rewritten.
- Automate — what remains after Eliminate and Simplify. Automate is the fourth action in the E-S-S-A-M framework, not the first.
- Migrate — steps redirected to a different team, system, or channel.
The result is a to-be model produced in the same session, with a clear, auditable before/after view. The gap is not a separate deliverable produced later. It emerges from the session itself.
The Change-Log Template: Your Gap Analysis in Table Form
The output of a well-run as-is/to-be session is a structured change-log. Each row represents one process step. The table shows where it is today, the approved future state, the E-S-S-A-M action applied, and who owns the change.
Use this template as a starting point:
| Step | As-Is State | To-Be State | E-S-S-A-M Action | Owner | Status |
|---|---|---|---|---|---|
| Document request received | Email to operations inbox | Automated intake form | Simplify | Ops team | Approved |
| Eligibility check | Two-approver manual review | Single approver with criteria table | Simplify | Senior ops | Pending |
| Physical signature required | Wet signature on paper form | Digital approval via WhatsApp | Migrate | Compliance | In review |
| Data entry to system | Re-keyed from email | Auto-populated from intake | Eliminate | IT | Approved |
| Supervisor review | Required for every case | Required for exceptions only | Automate | Team lead | Approved |
ESSAM's 7-step AI Lean cycle — Baseline, Map, Analyse waste, Optimise, Document, Deploy, Improve — is what produces this table. Steps 1 and 2 produce the as-is. Steps 3 through 5 produce the to-be and the change-log. Steps 6 and 7 deploy the new standard and verify the improvement holds.
The Kuwait procurement analogy is instructive here. A Kuwait bank applied this sequence to its procurement process. The cycle dropped from 139 days to 57 — 82 days of work retired, same headcount. That gain came almost entirely from the Eliminate and Simplify phases, before a single automation was introduced. That was a procurement engagement. The same logic applies wherever as-is and to-be sit unreconciled on opposite sides of a review cycle.
The Gap Report Is the Deliverable
"Most teams treat the as-is as the starting point and the to-be as the destination," says Abdulla Al-Awadi, ESSAM's founder and former Chief Strategy Officer at a Kuwait bank. "Both maps matter less than the gap analysis between them. If you cannot produce that in a single session, you are doing documentation work — not process engineering."
That distinction has a practical consequence. Most organisations already hold some version of an as-is. What they lack is an approved, change-logged to-be that every process owner has committed to.
ESSAM generates SOPs, SLAs, RACI matrices, and policy documents directly from the live model. Once the to-be is approved, standards are ready to deploy. In Singapore and Malaysia, ESSAM deploys over WhatsApp — near-universal adoption, no training required, no new application for staff to learn.
The question is not whether your organisation has an as-is. It is whether you have the gap analysis that bridges it to a better state — with owners, actions, and a deployment plan attached.
Frequently Asked Questions
What is the difference between as-is and to-be process mapping?
As-is process mapping records the current state of a process — every step, decision, and handoff as it actually occurs today. To-be process mapping defines the approved future state after waste has been identified and removed. The gap analysis is the structured list of changes that connects the two maps and makes improvement actionable. Without the gap analysis, both maps are documentation. With it, they are a plan.
How long should a process gap analysis take?
A structured gap analysis should produce an auditable change-log in one session. If the session ends without a list of changes and named owners, the analysis has been deferred, not completed. Multiple workshops conducted over weeks are a sign of a capture problem. The complexity of the process is rarely the limiting factor — the model for capturing it is.
What should a to-be process map include?
A to-be map should show the approved future-state sequence, the E-S-S-A-M action applied to each step, the named owner of each change, and the current transition status. Without owners and status, the to-be is aspirational documentation. It is not a deployment plan, and it will not survive the next meeting.
Ready to close the gap in one session? Book a demo on your process. Your actual workflow. No hypothetical use case required.
Related reading: What is an AI Process Engineer? · What is Business Process Analysis? · ESSAM Features