Document a current state process from the people who actually run it

An as-is process map exists to give you a truthful baseline: what you measure change against, and what tells you which eight steps out of forty are why month end takes nine days.

One thing reliably makes an as-is map worthless, and it is not notation. It is documenting the process as it is written down rather than as it is actually performed. Every organization has a procedure document, and almost none describe what happens on a Tuesday. If your map matches the procedure document, you retyped something.

Wavelength is a voice to diagram tool that builds the process map while the walkthrough is happening, so you leave with a picture the participants have already seen rather than notes you redraw on Thursday.

The demo needs no account. The free plan needs no card.

As-is versus to-be, briefly

The as-is is the baseline. The to-be is the argument. The usual failure is letting the second leak into the first. Someone says "well, it should go to approvals next", it gets drawn, and your baseline now contains a step that has never happened.

Listen for the tell: should, normally we would, the policy says, in theory. Park them. Keep a visible list labelled future state and add them out loud, so the person who raised it sees it was not binned.

Who to get it from

Get it from the person who performs the step, not the person who owns it. Managers describe the documented process, because that is the version they are accountable for. Operators describe the real one, because they make it work when the documented version does not.

The gap between those two descriptions is usually the most valuable thing in the exercise. It is where the shadow spreadsheets live, and where somebody has held the process together with a recurring calendar reminder for three years. Sit down with managers only and you get a clean map of a process nobody follows, then find out at user acceptance testing. See also how to run a process mapping workshop.

The method

1. Define the boundaries first. One trigger, one end state. Without this the walkthrough spreads across three departments and finishes none.
2. Get the happy path end to end without interrupting. Ask for a normal case, then stay quiet. Interrupting at step three means you never hear step eleven.
3. Go back for exceptions, rework loops and handoffs. Second pass, same path: what happens when this fails, how often, who fixes it. Delay accumulates in the gaps between steps.
4. Name the system for every step. ERP, shared mailbox, portal, spreadsheet on a desktop. A step with no system named is usually a workaround nobody has admitted to yet.
5. Capture who owns each step. Role, not department. Where two roles could do it, record both. Ambiguous ownership is why things sit for four days.
6. Mark the pain points while people are complaining about them, in their words. Collected later they arrive sanitized and useless.
7. Validate with the room, not by email. Covered below.

A worked example: supplier invoice approval at a mid-size manufacturer

Constructed illustration, not a client case, but the shape will be familiar. Boundaries: starts when a supplier invoice lands in the AP mailbox, ends when it is posted for payment. Three passes.

Pass one: the happy path

What the AP clerk says when you ask her for a normal one:

Invoices come into the AP inbox, mostly PDFs. I check it against the PO in the ERP, and if the numbers line up I code it and route it to the budget holder. They approve it, it comes back to me, I post it, and it goes in Thursday's payment run.

Six steps, nineteen seconds. The spine: invoice received, matched to PO, coded to cost center, routed for approval, approval returned, posted into Thursday's run. Stop here and you will report that supplier invoices take two days. They do not.

Pass two: the exceptions

Second pass, one question per step: what happens when this does not work.

Step two, the invoice that does not match the purchase order. Roughly one in five. Variances under fifty dollars she releases herself, a tolerance nobody has written down. Anything larger goes back to the buyer by email, and that loop has no owner and no clock on it. Invoices disappear there for a two weeks.

Step four, the approver on leave. ERP delegation exists and nobody configures it, so she emails the approver's manager, gets a verbal yes, and posts it with a note. Undocumented control bypass, most weeks.

Then the one you only get by asking twice. Invoices with no purchase order, mostly utilities and professional services, skip this process entirely. They sit on a spreadsheet she maintains, get approved over email, and are keyed as manual journals at month end. Fifteen percent of volume, and the largest source of month end adjustments.

Pass three: systems and owners

Third pass, one question per step. Matching and coding in the ERP. Routing in Outlook, because the workflow module was never switched on. No-PO invoices in Excel on a shared drive. The buyer owns the dispute loop in theory and nobody owns it in practice. The finished map:

The official process has six steps. The real one has eight, two of which appear in no procedure document, and those two are where the time goes. Neither surfaces if you ask the finance manager. The pattern repeats in ERP implementations: the requirement that breaks go live is the one nobody documented because it was awkward.

The failure modes

• Documenting the documented process. If your map could have been produced without leaving your desk, it was.
• Mapping at the wrong altitude. Either one box called "process the order", or two hundred boxes of keystrokes nobody will read.
• Letting the to-be leak in. Your baseline stops being a baseline and the benefits case stops being defensible.
• Never validating. The map gets attached to a document and acquires authority by surviving. Six months later a design decision rests on a guess.
• Building it in a tool nobody else can open. If review needs a licence, it gets reviewed by everyone except the people who do the work.

How to validate it so it actually gets signed off

Read it back aloud. Step by step, in order, in the room. It catches what silent review does not, because people hear a wrong order faster than they see it.

Walk it in reverse. Start at the end state and work backwards, asking what had to happen for this step to be possible. Reverse traversal finds missing prerequisites. Forward traversal follows the story people tell themselves.

Ask what happens when this goes wrong. Not "does this look right", which gets you a yes from somebody who stopped reading at step four. "What happens when the approver is on leave" gets a real answer, because it is a question about their world, not your artefact.

Where Wavelength fits

The value here is timing, not intelligence. The map builds while the walkthrough happens, so validation is same-session rather than same-two weeks.

Unlike Lucidchart, Miro, and Visio, which require you to draw the process map after the workshop, Wavelength builds it live during the session, so the client validates the as-is process in the room instead of two weeks later in a review cycle.

Audience specific versions: for technical project managers and for IT transformation consultants.

Where this does not fit

Wavelength does process and data flow. Not BPMN 2.0 with correct symbology, not UML, not ERDs, not C4, not value stream mapping with cycle-time and takt calculations, and not precise visual layout for a formal deliverable.

If you need a conformant BPMN artefact, capture the shape live while the people who run the process are in front of you, then formalize it in a modelling tool after. The hard part was never the notation.

It will not rescue bad audio. A noisy room or three people talking over each other degrades the output, and that is a real limitation rather than a disclaimer. Record it and paste the transcript.

Common questions

How detailed should an as-is map be?

One person, one thing, one system per step. Test: if a step could be handed to someone else without further explanation, it is a step. Most processes land between fifteen and forty steps. Past sixty you are in keystrokes and nobody will read it.

How long does documenting a current state process take?

For one process with clear boundaries, about ninety minutes with the people who perform it, plus a shorter follow-up for exceptions they remember later. Elapsed time is dominated by scheduling and validation cycles, which is why same-session validation saves the most.

What if two people describe the process differently?

A finding, not something to resolve on the spot. Either the process genuinely varies by region or product line, or one is describing the documented version and the other what they do. Capture both as branches, note who said which, confirm which is more common.

Should I map the exceptions or just the happy path?

Both, in that order. The happy path gives you structure. The exceptions give you the reason the process is slow, because that is where the manual work and rework live. A happy path only map says two days when the average case takes nine.

Do I need BPMN for an as-is map?

Not for discovery. Correct symbology is a formal notation for a formal deliverable, and enforcing it during a walkthrough slows the conversation to the speed of the notation. Capture the shape in boxes and arrows with the participants present, formalize it after.