06/Future-state design
Design the target process, and see exactly what changes.
Build the future state from the process you actually captured.
Redesign against the process you captured rather than an idealized one, and hand implementation an exact list of what has to change.
Where you start
Build the future state from the real process, not a blank page
The future state starts as a copy of the real baseline, so every difference is deliberate, and you can carry more than one candidate.
- Current-state capture as the baseline
- Multiple future states from one starting point
v2.3 · baseline
v2.4 · candidate
What changed
Get an exact list of every step added, removed and edited
Added, removed and edited steps are called out explicitly rather than left for a reader to spot between two diagrams.
- Side-by-side comparison of steps, roles and handoffs
- Summary figures on step count and cycle time
Handing it over
Give implementation a change list, not a document to interpret
What has to be built, retrained or retired falls out of the comparison, so implementation gets a spec instead of a narrative.
- A clear bridge from discovery into planning
- Exports and API for the teams doing the work
Redesign without a second mapping project
Evolve the map you already trust.
A change you can defend to a sponsor
Every difference is explicit and attributable.
Implementation gets a specification
A change list, not a narrative document.
Related features
All featuresGovernance
Every version attributed, reviewed and kept, so your documentation holds up when it is questioned.
Data integration
Connects to where your documents and run data already live, with exports and a REST API back out.
Common questions
Do we have to map the current state first?
It is strongly preferable. The value of the comparison comes from the future state being a branch of a real baseline. That is what makes the change list accurate rather than aspirational.
Can we keep more than one future state?
Yes. Versions branch, so alternative target states can be developed and compared against the same baseline before one is chosen.
What does the comparison actually show?
Both versions side by side with steps marked as added, removed or edited, along with summary figures such as step count and the effect on cycle time.
How does the change list reach the people who have to implement it?
Through the same routes as any other process data: document and spreadsheet exports for people, and the REST API for systems. The comparison is structured, so it does not have to be retyped to be actionable.
What if the current state is full of workarounds nobody will admit to?
That is the normal case, and it is why the baseline should come from live capture with the people doing the work rather than from the official procedure document. The workarounds are usually the most important thing on the map.