Every process improvement project starts with the same deceptively simple question: how does this actually work today? The answer rarely lives in one place. The documented procedure describes what people are supposed to do, the person who has run the process for nine years describes what actually happens, and the exceptions live in three people's heads. Map only the documented version and your to-be design will quietly break the moment it meets reality.
AI helps with the part of this work that is genuinely mechanical: turning interview notes, screen recordings, and procedure documents into a structured step list, then cross-checking the current state against the future state so you can see exactly what changed and who it affects. What AI cannot do is tell you which exception matters, and this guide won't pretend otherwise. The six steps below cover the whole loop — from scoping the process to documenting the gap between as-is and to-be — including the validation step that most process mapping projects skip and later regret.
If you're still collecting the raw input these steps depend on, our guide to AI tools for requirements gathering covers the elicitation side in more detail.
What You'll Need
You don't need specialized process mining software to follow this. You need four things:
- A named process with clear start and end points. "Order fulfilment" is too broad; "from order received to shipment dispatched" is workable in a single mapping session.
- Access to the people who run the process, including at least one person who handles its exceptions. The official process owner is rarely the best source.
- Whatever documentation exists — procedure documents, screenshots, training material, tickets. Imperfect sources are still useful input.
- A place to keep the output. A process map is a living document, and the mapping context matters as much as the map itself.
How to Map As-Is to To-Be Business Processes with AI: 6 Steps
Step 1: Define the scope and boundaries before you map anything
Write down where the process starts, where it ends, and what sits outside it. Ambiguity here is the single most common reason a process map becomes unusable — half the participants map the order flow, the other half map the exception handling, and the resulting diagram describes neither.
State the trigger, the terminal event, and the actors you'll include. If a step belongs to a neighbouring process, say so explicitly and leave it out.
Try this with Noumi: Describe the process in a sentence and ask it to propose a scope boundary — trigger, terminal event, actors, and explicit out-of-scope list. Adjust what it returns, then keep the agreed boundary in the project so every later step stays inside it.
Step 2: Capture the as-is process from the people who run it
Interview the people doing the work, not only the people who own it. Ask what they do first, what they do when the normal path fails, and where they wait on someone else. The exceptions are where the process actually lives, and they're the reason to-be designs fail.
Record the sessions or take structured notes. What matters is that the raw material survives in a form you can revisit, because your interpretation on the day will differ from what was actually said.
Try this with Noumi: Upload your interview notes and screen recordings as project files, then ask for the steps each participant described. Because the sources stay attached to the project, you can return to the original wording later instead of working from a summary.
Step 3: Turn raw notes into a structured as-is map
Now consolidate. Take every step you captured and reduce it to a numbered sequence: who does what, in what order, using which system or document. Where two interviewees described different versions of the same step, record both versions side by side rather than silently choosing one.
Keep the layer thin. A process map that includes every possible branch becomes unreadable, and a map nobody reads cannot be validated. Put the normal path in the main sequence and list exceptions separately.
Example output: A numbered as-is sequence — "1. Sales creates the order in the CRM. 2. Credit check runs automatically against the finance system. 3. On a failed credit check, the order parks in a manual review queue owned by Finance. 4. ..." — with conflicting accounts flagged rather than merged.
Step 4: Validate the as-is map with the people who were interviewed
Send the map back. This is the step most projects skip, and it's the one that determines whether everything downstream is built on solid ground. Ask each participant two questions: is anything missing, and is anything here wrong?
Disagreement at this stage is a finding, not an inconvenience. If two people describe the same step differently, you've located either a genuine inconsistency in the process or a gap in how it's documented — both worth fixing before you design the future state.
Try this with Noumi: Ask for a validation summary that lists each step alongside the source notes it came from. Reviewers can check the specific step they own instead of reading the whole document and hoping they notice an error.
Step 5: Find where the as-is process breaks down
Go through the validated map and mark the friction points: waiting, rework, handoffs where information gets retyped, approvals that add no decision, and steps that exist only because a system can't talk to another system. Attach a rough cost to each — time per instance, frequency, or the risk it introduces.
This list is what justifies the to-be design. Without it, a redesigned process is just a different set of steps, and nobody can tell whether it's better.
Be specific about frequency. "The credit check fails" is not a finding; "the credit check fails on roughly one in twelve orders and each failure costs a day of elapsed time" is. If you can't get an exact number, a range from the person who handles the exception is far better than no estimate at all, because the relative size of the problems is what drives sequencing.
Try this with Noumi: Ask it to group the marked issues into themes — duplicate data entry, unnecessary approval, missing automation, unclear ownership — and estimate which themes appear most often across the map.
Step 6: Design the to-be process and document the gap
Build the future state from the friction list, addressing the biggest issues first rather than redrawing everything. Then produce the artifact that actually makes the mapping useful: a gap table showing what changes from as-is to to-be, why, and who is affected.
The gap table is what stakeholders review, what the change plan is built from, and what tells you whether the redesign delivered. Map each to-be step back to the as-is step it replaces or removes so no step disappears without explanation. Where a friction point is left unresolved, say so and give the reason — an explicit deferral is far easier to manage than a silent omission.
Try this with Noumi: Ask for the gap table as a structured document, then save the whole mapping routine — scope template, validation checklist, gap table format — as a reusable Skill so the next process doesn't start from a blank page.
Pro Tips
- Interview the person who handles the exceptions first. They know where the process breaks more reliably than the process owner, and they'll tell you which steps exist only on paper.
- Let the as-is map stay ugly. Accuracy beats presentation at this stage. A neat diagram produced early tends to stop being edited, and an unedited map stops being true.
- Number your steps once. Renumbering after validation invalidates every reference in your notes and interview transcripts, and it makes the validation history impossible to follow.
- Keep the map and the remedy separate. "Step 3 takes two days" is an observation; "Step 3 should be automated" is a recommendation. Mixing them makes it hard to tell what's actually happening today.
- Timebox validation. A week is usually enough to get corrections. An open-ended review round is how maps sit unfinished for a quarter.
Common Mistakes to Avoid
- Mapping what's documented instead of what happens. The written procedure reflects how the process was designed, not how anyone runs it. Interview first, read the documentation second.
- Skipping validation. An unvalidated map is a hypothesis dressed up as a fact. Everything you design from it inherits the error.
- Designing the to-be process before the as-is is settled. It's tempting to jump to the improved version while the current state is still fuzzy. You'll end up unable to explain what changed or why.
- Treating exceptions as noise. The workarounds people build are usually describing a real requirement the process failed to meet.
- Producing a diagram nobody maintains. If the map lives in a file that leaves the project folder, it's stale within a quarter.
Get Started
Pick one process — something bounded, with people you can actually interview this week. Run the six steps end to end before applying the method to anything larger, because the value shows up in step four, when the people who do the work tell you what you got wrong. That feedback loop is the whole method.
Teams that want interview notes, validation history, and gap tables to stay in one place instead of being rebuilt per project can start with Noumi and keep the mapping context attached to the work. For the wider view of how this fits into the analyst role, see our guide to AI tools for business analysts.
