From Current State to a Credible Future State: Cost, Control & Change

PathPatron Use-Case Canvas series — 6 of 7

A current-state map shows where work hurts. Future-state modelling asks a harder question: what is the smallest change that removes a specific source of friction without moving risk somewhere else?

It is not a “to be” diagram or an argument for an AI agent or agentic workflow. It is a disciplined way to turn the evidence in the map into a few credible, testable changes to how work actually moves.

Continue the same case: the map becomes a model

Return to the supplier onboarding request from the previous article. At 09:07, Procurement receives an email asking for a supplier to be active before a project milestone. The attachment set is incomplete. A line is added to a spreadsheet; Legal later finds a missing clause; Finance cannot validate the bank details; the business requester starts chasing status.

The current-state map did not merely produce one long flow. It exposed four different kinds of breakpoint:

• a missing-input breakpoint: the case begins without the information the next step needs;
• an ownership breakpoint: people can see the request but cannot see who must act next;
• a control breakpoint: a mandatory legal or finance check is discovered late rather than at the right moment;
• a visibility breakpoint: the requester receives updates only by asking people to reconstruct the case.

That distinction matters. A single large “automate supplier onboarding” answer would blur four different problems together. The model starts to form when the team gives each breakpoint its own card: what happens, why it happens, who is affected, what must remain controlled, and what a smaller intervention could change.

Turn one large problem into smaller design moves

For this case, the future state does not begin with a tool. It begins by shrinking the problem into moves that can be owned and tested.

Breakpoint seen in the map	Smallest credible change	Tooling role	What must remain human
Incomplete requests enter the process	A guided intake asks for the required supplier evidence before a case is created.	A form or portal checks completeness and creates one case ID.	Procurement decides whether an unusual case may proceed without standard evidence.
Legal receives incomplete work	A routing rule sends a case to Legal only when the required contract information is present.	Rules-based queueing and status updates.	Legal interprets contractual terms and approves exceptions.
Finance discovers invalid details late	Bank data are checked at the appropriate stage and the failed check is visible to the case owner.	Validation service or a controlled master-data integration.	Finance decides how to resolve a failed or suspicious check.
People repeatedly reconstruct the status	The case has a shared status, next owner and reason for any wait.	Case-management view; notifications triggered by a genuine state change.	The named owner explains a non-standard delay and decides escalation.

Only after those foundations are clear does bounded AI assistance have a credible place. It may read permitted documents, flag likely missing information and draft a supplier follow-up or a reviewer summary. It may not approve a supplier, interpret a contract, create a vendor record or send an external commitment without assigned authority.

The sequence is deliberate: make the input ready → make the work flow → make the case visible → assist judgement where it genuinely helps. A complicated process does not become simple because it gains one clever layer. It becomes more manageable when the next dependable step is made smaller.

Model alternatives, not a fantasy end state

The team should compare at least two and, where useful, up to four coherent future states against the same current-state evidence. One polished “to be” diagram is not a decision. It hides the fact that there are several ways to relieve a breakpoint, each with a different cost, control burden and operating consequence.

In our supplier-onboarding case, the four breakpoint cards do not automatically lead to an AI-enabled end state. They give the team a set of alternatives to model side by side.

Option A — Stabilise the work first

In our procurement case, this could mean a guided intake that will not create a case until the basic supplier evidence is present; one case ID; a named next owner; and a visible exception route for an urgent but incomplete request. Legal and Finance still receive work manually, but they receive the right work at the right point.

This future state removes the missing-input and visibility breakpoints without pretending that expert review should disappear. It is often the quickest way to make the process calmer.

Option B — Automate the stable seams

In our procurement case, this could mean the intake checks mandatory fields, rules route a complete contract pack to Legal, a permitted integration runs the bank-data validation before Finance reviews it, and a status change—not a chaser email—updates the requester. A failed check creates a visible exception task for the correct owner.

This future state reduces hand-off delay and re-entry, but only where the rule is stable, the source data are reliable and the team can recover from an incorrect route.

Option C — Add bounded AI assistance

In our procurement case, this could mean an assistant reads permitted supplier attachments, drafts a completeness summary for Procurement and suggests a follow-up for the missing clause or bank evidence. Procurement verifies the gaps before contacting the supplier; Legal still interprets contractual terms; Finance still decides how to resolve a failed or suspicious validation.

The output is a draft or recommendation, never an autonomous approval. The case records the source material, instruction version, human decision and exception so the team can review whether the assistance helped.

Option D — Run a bounded agentic workflow

In our procurement case, this could mean an agentic workflow coordinates a defined, low-risk sequence: it checks whether the permitted intake evidence is present, opens a case, asks the requester for a missing standard document, routes a complete pack to the named queue, updates the shared status and returns a failed validation to the right owner. It works across those assigned steps, rather than merely drafting one summary.

That is not delegated authority. The workflow may not approve a supplier, decide that a missing control can be waived, interpret contractual terms, create a vendor record, release a payment or make an external commitment. Every action has a named trigger, permitted system/data boundary, visible log, stop condition and human exception route. A person remains responsible for the decision at every control boundary.

These are not four maturity stages every team must climb. They are alternatives and combinations. In this case, Option A plus the stable parts of B may resolve most of the delay; C is justified only if repeated document-reading remains material after that; D is justified only if the end-to-end coordination steps are genuinely stable, observable and safely recoverable. Choosing the smaller option is a successful model, not a lack of ambition.

Compare the cost to solve, not only the cost of waiting

The previous article established the cost of leaving the mapped pattern alone. This article must add the other side of the decision: what would it cost to change it responsibly? Do not compare a visible monthly pain estimate with an imaginary “AI solution.” Compare the same case against each specific option.

For every future-state option, make the cost-to-solve visible in six parts:

• design and configuration: the intake, rules, case states, prompts or operating instructions that have to be designed and tested;
• data and integration: source-data clean-up, permissions, APIs, validation services and identity/access work;
• controls and assurance: legal, security, risk, logging, evaluation, review and exception design proportionate to the option;
• change and adoption: training, updated responsibilities, supplier communication and support for the first normal cases;
• recovery and operations: who fixes a failed route, wrong validation, bad draft or unavailable service—and how quickly;
• ongoing run cost: licences, monitoring, maintenance, model usage where relevant and the retained human review that does not disappear.

In our procurement case, Option A may require a short configuration effort, a clarified owner model and a few weeks of adoption support. Option B adds integration and recovery work around routing and validation. Option C adds all of that plus permissioning for documents, quality checks for the assistant, retained review time, monitoring and an escalation route when its draft is wrong. Option D adds the hardest operating question: cross-step orchestration, action permissions, durable state, traceable hand-offs, stop conditions and recovery when a step fails or a case becomes non-standard. The point is not to invent a universal euro figure. It is to expose what each choice genuinely asks the organisation to fund, operate and govern.

Future-state option	What it changes in our procurement case	Cost-to-solve profile	Decision test
A — Stabilise	Complete intake, case ID, owner and exception route	Lower change load; mainly process design, configuration and adoption	Does it eliminate enough chasing and rework before adding technology?
B — Automate stable seams	Rules, validation timing, routing and status updates	Medium change load; integration, testing, recovery and operating ownership	Are the rules stable enough and are the source systems reliable enough?
C — Bounded AI assist	Permitted-document summary and drafted follow-up	Higher control and operating load; data permissions, evaluation, review and monitoring in addition to integration	Does repeated document work remain material after A and B, and can a reviewer safely check the output?
D — Bounded agentic workflow	Coordinates permitted intake, request-for-information, routing and status steps across the case	Highest operating and assurance load; action permissions, orchestration state, logs, stop conditions, exception recovery and retained decision control	Are the steps sufficiently stable and reversible—and is there a named human owner for every boundary and failed action?

Use ranges, named assumptions and a validator where numbers are available. If the organisation cannot yet estimate a cost, record the uncertainty rather than making Option C or D look inexpensive by omitting its control, recovery or run cost. A credible choice may be: stabilise now, measure the result for six weeks, then decide whether automation is worth its additional cost.

The future-state model must show the control boundary

An attractive diagram is still magical thinking if it skips the operating reality. For every proposed move, put six named cards on the model:

1. Trigger: What starts this step, and what evidence must be present?
2. Action: What does the person, rule or tool actually do?
3. Decision owner: Who can approve, override or stop it?
4. System and data boundary: What may be read or written, from where and under whose identity?
5. Exception route: What happens when the case is incomplete, unusual or wrong?
6. Proof of improvement: Which measure will show that the change helped rather than displaced the pain?

For example, “AI checks the documents” is not a model. “An assistant summarises permitted attachments for Procurement; Procurement verifies the gaps before contacting the supplier; Legal and Finance retain their approval decisions; a missing source is visible rather than inferred” is one.

A practical 45-minute modelling session

This is deliberately short. The goal is not a finished enterprise architecture. It is two to four credible future-state options, their different boundaries and cost-to-solve profiles, and the evidence needed to choose what to test first.

Prepare before people enter the room

Choose one recent, consequential case—not an average process. Invite the people who perform the work, one decision owner, and where relevant a control or system owner. Bring the current-state map, a blank model canvas and any existing policy, data-classification, service-level or process material. Do not invent a new governance universe if the organisation already has one.

AI may prepare a draft only: cluster de-identified workshop notes, turn the current map into a first list of hand-offs, suggest questions for each breakpoint and format the canvas. It must not decide which pain is real, invent policy, identify an owner or validate a future state. Stakeholders do that in the session.

Run it in person

Print the canvas large enough for people to stand around it. Use one colour of cards for current-state evidence, one for breakpoints, one for potential interventions and one for controls or open questions. Begin with the actual case and add cards from left to right. When a tool is proposed, ask: which breakpoint does this change; what becomes smaller; who owns the exception; what would make us stop?

Run it online in Mural or Miro

Use the same canvas as a locked background. Create one card per observation rather than asking people to perfect a diagram. A facilitator groups the cards live; the system owner marks data or integration constraints; the decision owner names the control boundary. Model at least two alternatives for the same consequential breakpoint, then end with one option to test, one owner and no more than three measures.

Use this as a locked Mural or Miro background. The cards placed on it are the team’s evidence; the canvas is a facilitation surface, not a finished solution.

Time	Facilitation move	Tangible output
0–5 min	Restate the actual case, outcome and non-negotiable controls.	Shared scope; no tool choice assumed.
5–13 min	Place the current-state evidence in sequence.	One short path through the real work.
13–21 min	Name and sort the breakpoints: input, ownership, control or visibility.	Prioritised breakpoint cards.
21–31 min	Model at least two smaller moves for the most consequential one or two breakpoints. Include an agentic workflow only where the sequence, authority and recovery conditions can be named.	A stabilise / automate / assist / bounded-agentic option set.
31–39 min	Add decision owner, data boundary, exception route, recovery and cost-to-solve components for each option.	Comparable bounded future-state options.
39–45 min	Choose the proportionate option to test, its measures, owner and date of review.	A next step that can be operated and justified.

Make modelling a leadership practice, not a lucky workshop

Leaders do not need to make a future-state canvas a grand transformation ceremony. They need to make it the normal entry point for a consequential change request.

Set up once:

• a single stored canvas and a standard intake card for “what work is changing?”;
• a small cross-functional review group with named Process, decision and system/control owners;
• a rule that no automation or AI proposal moves to selection without a mapped case, a control boundary and an exception route;
• a short evidence register: baseline, option assumptions, cost-to-solve range, measures, decision and date to review.

Use repeatedly:

• run one 45-minute session when a new candidate crosses a value or risk threshold;
• review a live model after the first normal cases and after the first meaningful exception;
• update the reusable playbook when the team learns that a rule, hand-off or control does not hold;
• retire a proposed tool or route when the evidence says it is not the smallest credible move.

This is PathPatron’s distinctive contribution: not a promise that every process needs AI, but a reusable evidence-to-operating-decision practice. The Process lens makes the hand-offs visible; the People lens keeps ownership and judgement named; the Power/Techniques lens makes tools and controls concrete. The output is a decision a leader can govern, not a decorative future-state picture.

What this method does not solve

Future-state modelling cannot settle a contested strategy, repair a broken source system, eliminate a regulatory duty or make a vague business outcome measurable by itself. It also cannot prove that a tool will be adopted. If the work crosses enterprise architecture, procurement, collective-agreement, safety or high-risk regulatory boundaries, the 45-minute session is discovery—not approval.

That limit keeps the practice useful. The canvas remains stable because it teaches teams how to inspect work, surface authority and test smaller changes. The examples can evolve—supplier onboarding, HR access, invoice discrepancies, customer operations—when the operating pattern changes. The central decision stays timely: what should change in the work, who owns the risk, and what evidence would justify the next step?

The next decision

Once a future-state option is credible, turn it into requirements. The next article, Requirements Engineering for AI-Enabled Work, shows how to convert the rules, constraints, integrations, acceptance criteria and operating ownership discovered here into a usable delivery pack.

Continue the PathPatron Use-Case Canvas

• 1/7: People, Stakeholders and Targets
• 2/7: The Stakeholder-Pain Map
• 3/7: From Pain Point to a Real Use Case
• 4/7: Map the Work Before You Automate It
• 5/7: The Cost of Not Solving: Making Process Pain Visible
• 6/7: From Current State to a Credible Future State: Cost, Control & Change — you are here.
• 7/7: Requirements Engineering for AI-Enabled Work