Future-State Process Map: Turn a Diagnosed Cause Into a Change Worth Piloting

The Future-State Process Map sits in the Improve phase of RDMAICS. Its job, in the product's own words, is to design the to-be process flow incorporating automation, elimination of non-value-added steps, and improved handoffs.

That wording matters. It is a design tool, not a diagnosis tool. By the time you open it you should already know what is broken and why. Measure gave you the baseline. Analyse gave you the cause. Improve asks a different question. What does the process look like once the cause is removed?

Reach for it at the moment a team starts talking in solutions. Someone says automate it. Someone else says cut the approval. Those are fragments. The Future-State Process Map forces the fragments into a single ordered sequence with a cycle time against every step. That is the point where a hallway idea becomes something you can cost, pilot and defend.

Use it early enough that the design is still negotiable. Use it late enough that you are not designing around a cause you have not confirmed.

The tool ships with sample data for an invoice processing redesign. This case is fictional. It exists to show the mechanics of the tool, not to report a real result.

The scenario is familiar. Invoices arrive. Someone keys them into the finance system. Someone matches them against a purchase order and a receipt. Someone approves. Someone pays. Someone files. The diagnosed cause in this kind of flow is usually manual re-entry and approval queueing, and the future-state design in the sample attacks both.

The designed flow has six steps. Auto-ingest invoice via portal or OCR at two minutes. Auto-populate ERP fields at one minute. Automated three-way match at one minute. Tiered approval with auto-approval under threshold at five minutes. Payment processing at five minutes. Auto-archive at one minute.

Five of the six steps are marked as value-add. Auto-archive is marked as not value-add. Every step carries a named automation. That is the whole case, and the rest of this guide stays inside it.

The worksheet is a table. Each row is one step in the future state. You fill five columns and the order of the rows is the order of the flow.

Step number keeps the sequence explicit. Future-state step is a short description written in the active voice, describing what happens rather than who does it. Cycle time in minutes is your estimate for that single step. Value-add asks a yes or no question about whether the customer of the process would pay for that step. Automation names the specific mechanism that makes the step possible.

The automation column is the one teams under-use. In the sample each entry is concrete. OCR plus portal API. OCR-to-ERP integration. Rules engine. Auto-routing plus delegation. Batch scheduling. Document management. None of those are aspirations. Each one names a capability someone has to build, buy or configure.

Write the steps before you write the cycle times. If you estimate time while you are still arguing about sequence, the numbers drift to suit the argument.

The tool builds an improvement design flow from the worksheet. The result is labelled as built from worksheet, and the tool states plainly that the sequence is taken from the current editable worksheet order.

What you get is the six steps rendered as a linked chain. Step one to step two to step three to step four to step five to step six. No branches. No loops. No rework arrows. That visual simplicity is itself a finding. If your current state has rework loops and your future state does not, you have just made a claim about defect rates that the pilot will have to prove.

The tool also offers an AI review that explains the result back to you. Treat that as a second reader, not an auditor. It is reading the same six rows you wrote.

Read the chain against the cycle times you entered. Two, one, one, five, five, one. The two longest steps in the designed flow are tiered approval and payment processing, both at five minutes. Both are also the steps where a human decision or an external system still governs the pace. That is where the remaining time sits, and that is where a second round of design would start.

A future-state map earns its keep by making three decisions easier.

The first is scope. Six steps with six named automations is six separate build items. You can now ask which of them you pilot first. The three steps running at one minute each, auto-populate, automated match and auto-archive, all depend on integration work. The five minute steps depend on policy and scheduling. Those are different workstreams with different owners.

The second is sizing. You entered a cycle time against every step, so you can compare the designed flow against the current-state baseline you measured earlier. The tool does not do that comparison for you. You do it by holding the two numbers side by side. If the gain does not clear the cost of the six automations, the design is not worth piloting yet.

The third is sequencing the pilot. Auto-archive is marked as not value-add. It is still in the design because records have to be kept. Knowing that tells you it is a step to automate cheaply rather than a step to optimise. Value-add flags are a prioritisation signal, not a deletion list.

The most common mistake is designing a future state before Analyse has closed. The tool will happily accept a flow built on a guess. It has no way to know whether your cause is confirmed.

The second is vague automation entries. Writing automation in the automation column tells no one anything. The sample writes rules engine and batch scheduling because those point at specific decisions a specific team has to make.

The third is optimistic cycle times. The numbers in the worksheet are estimates for a process that does not exist yet. Five minutes for payment processing is a claim. Write estimates you would be willing to be measured against in the pilot.

The fourth is treating every automated step as value-add. The sample does not. Auto-archive is automated and marked no. Automation changes who does the work. It does not change whether the work is worth doing.

The map is the specification the pilot tests. Each row becomes a hypothesis. Auto-ingest will take two minutes. The automated three-way match will clear without exception handling. Tiered approval will route correctly under the threshold.

Before the pilot starts, agree how you will measure each of those. Cycle time per step is the obvious measure because it is already in the worksheet. Add exception rate, because a rules engine that passes ninety per cent of invoices behaves very differently from one that passes all of them, and the worksheet cannot show you that.

Keep the worksheet open during the pilot. When a step takes longer than designed, change the number in the worksheet and regenerate the result. The map is a living artefact through Improve and into Control.

Be clear about the limits, because the output looks more certain than it is.

It does not validate your cycle times. Two minutes for auto-ingest is a number you typed. The tool reproduces it without challenge.

It does not calculate savings, cost, headcount impact or payback. Nothing in the result converts six cycle times into money. That arithmetic happens outside the tool, with your own baseline and your own rates.

It does not model variation, exceptions or failure paths. The result is a straight chain of six steps. Real invoice flows have disputes, short receipts and duplicate submissions. None of those appear unless you write them as rows, and a single linear chain cannot show a branch.

It does not cost or schedule the automation. Naming a rules engine is not the same as having one. The feasibility of each automation entry is a separate conversation with the people who would build it.

It does not tell you whether the change is worth doing. It gives you a designed flow, a step-level time estimate and a value-add call on each step. You still have to compare that against your current state, weigh the build effort, and decide. The tool makes the decision legible. It does not make it for you.