Ask How It Works, Then Ask How It Should

Current state versus future state process mapping is two passes over the same work: one map of how the process runs today, one map of how it should run, recorded side by side so the distance between them is visible instead of argued about. Most sessions collect a blend of the two, because only one of the questions ever gets asked out loud. The move that separates them is a single word, swapping "does" for "should," and it works even on the operator who opens with "I don't know how this company is set up." Ask both on purpose and the gap between the two maps names your next change.

What is current state versus future state process mapping?

Current state is what actually happens, including the workarounds. Future state, which we call the ideal state because that is how operators talk about it, is what the person who owns the work says should happen if nothing was in the way. In older process language these are the as-is and to-be maps, and the vocabulary matters less than the discipline of keeping them apart on the page.

Notice the bottom row. Both failures look identical in a transcript, a vague answer you cannot map, so knowing which one you just hit tells you which question to ask next.

Why do teams answer the wrong one?

Because in most companies nobody has ever asked the two questions separately, so people answer with a blend. A frustrated operator describes the process she wishes existed and calls it the process. A careful one describes only today and never mentions the fix she has been sitting on for a year.

That blend is what turns a clean diagram into fiction. If you are mapping your own processes without a consultant, this is the trap: you write a sentence that is half description and half aspiration, and six months later nobody can tell which half was real.

Ask both on purpose and the contradiction stops being a contradiction. It becomes a gap with two endpoints.

Switch tense when the answer is "I'm new here"

When someone says they do not know how the company is set up, you have not hit ignorance. You have hit the wrong tense.

In one engagement, a subject matter expert answered "how does that work here?" with "I don't know how this company is set up." The interviewer reframed on the spot: "Or maybe a better question is, how should that work here?" That one word change unlocked forty minutes of the richest domain content in the account.

The person knew the work cold. He just did not yet know this building.

A person who is new to your company is not new to the work.

When an answer stalls on company specifics, keep the topic and change the tense. The same move works on anyone who inherited a system from someone who left. Ideal state questions do not require tenure. They require judgment, which is exactly what you are there to capture.

Ask the two part question about the role boundary

Build the tense switch into the question itself and you stop having to guess which one to ask. The form is deliberately two part: "Is your team doing any resume review, or should they be doing any?" The answer that came back was "I would, yes. Let's just say yes."

The two part form separates current practice from intended practice, and it lets the expert answer both without contradicting himself. Nobody has to defend a gap they did not create. This is the same reason a mapping session your team does not dread leans on questions that attribute the problem to the system rather than the person.

Use it anywhere a boundary is unclear: who reviews, who approves, who is notified, who signs. Ask "or should they be" out loud, every time, instead of deciding for them.

Record both, then name the smallest change

Both states go in the notes, in the operator's words, and then you name the change that closes the distance. In the budget adherence work on one asset management engagement, that looked like this. Current state: the asset manager chases the field director weekly, and most of the time the field director does not know. Ideal state: the field director reports monthly with on track, off track, or not started, and the chasing stops.

The gap had a cause nobody had said out loud. The construction manager who actually executes the capital items was not in her meetings at all.

So the change was not a new reporting system. It was adding one person to a meeting that already existed, once a month, for ten minutes.

The gap is not the deliverable. The smallest change that closes it is.

Three rules make this repeatable in a live session:

1. Write current in their words. "Most of the time she doesn't know" is more useful than "reporting is inconsistent." Verbatim survives review; your paraphrase does not.
2. Write ideal as a behavior. Not "better visibility." A named person, a named cadence, a named set of statuses. If you cannot picture someone doing it on a Tuesday, it is not an ideal state yet.
3. Size the change down until it is boring. Ten minutes in an existing meeting beats a new process, because the existing meeting already survives everyone's calendar.

The third rule is where most gap analysis dies. The gap gets documented beautifully, the fix gets scoped as a project, and it waits. Sizing down is what makes it happen this month, and it is a large part of what to do with the map once it exists.

---

Do not let the map's tidiness override the truth

A gap on the diagram is not automatically a gap in the business. On one map a follow-up branch was obviously missing, and the tidy fix was obvious too. It turned out to be a deliberate volume tradeoff the operator had made years earlier and never explained, because nobody had asked.

Draw that branch in and you have documented a process the team consciously decided not to run, then wondered why the SOP got ignored.

Ask whether there should be one before you add one. The question costs eight seconds and it protects the only thing a map has going for it, which is that people believe it. It is the same discipline behind the review that catches a map going stale: absence is evidence of something, and you have to ask which something.

When the ideal belongs to somebody else's job

Sometimes the ideal state you just captured is not the interviewee's to build. One asset manager stopped a line of questions with "I don't do standard maintenance," and she was right. Half of what looked like her process belonged to a different function, and mapping it into her lane would have made the document wrong on the day it shipped.

Keep the answer, move the owner. Note the step, note who actually holds it, and put that person on the calendar. That is how one interview becomes a real map instead of one person's view of the company, and it separates a private document from the kind of step by step record of how business processes actually run that another department will accept.

At The Systems Effect we spend most of our week in rooms like this, interviewing the people who hold the work and asking both versions of the same question until the two maps stop disagreeing, which is how a messy workflow becomes a documented system rather than a tidier diagram of the mess.

Pick one process this week. Ask the person who runs it how it works, write that down, then ask how it should work and write that underneath. The change that closes the gap is usually ten minutes long, and you will see it before the call ends.

Frequently Asked Questions

What is the difference between current state and future state process mapping?

Current state maps what actually happens today, including the workarounds and the steps nobody admits to. Future state, or ideal state, maps what the person accountable for the result says should happen. You record both because the distance between them is the actual finding, and because a blended answer cannot be validated by anyone later.

How do you map a process when nobody knows how it works today?

Change the tense of the question. When someone answers "I don't know how this company is set up," they are telling you they cannot speak to current state, not that they lack expertise. Ask how it should work here instead, capture the ideal in full, then find the person who runs the steps day to day for the current state pass.

Should a process map show how work should happen or how it does?

Both, in separate layers, clearly labeled. A map showing only the ideal gets ignored in week one because nobody recognizes their job in it. A map showing only current state locks in workarounds as policy. Keeping them apart gives you an accurate document now and a target to move toward next.

What is the smallest change that closes a process gap?

Usually something that fits inside a meeting you already hold. In one engagement, weekly chasing was replaced by adding the person who does the work to an existing weekly meeting, once a month, for ten minutes. Size the fix down until it sounds too small to write up, because that is the version that survives everyone's calendar.