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

Published Article 6 header — From Current State to a Credible Future State

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

PathPatron Use-Case Canvas series — 6 of 7

In the previous article, Maya, the procurement coordinator, made the cost of a slow supplier-onboarding case visible: missing evidence, late checks, repeated status chasing and an unclear next owner. 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.

Maya’s case: where the next decision starts

Use-Case Canvas — Maya’s current-state supplier-onboarding case

Before: Article 5’s completed cost picture becomes the evidence base for Article 6. The orange outline marks the cost of not solving that the team must now address.

Continue the same case: the map becomes a model

Return to Maya’s supplier-onboarding request from the previous article. At 09:07, Maya 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 Maya for 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

Article 6 activity: model the future state

Use the same large working area as Article 4, but model the smallest credible future-state change. Keep the current evidence visible; add proposed steps, owners, controls and exception routes rather than drawing a tool-led fantasy process.

Keep the option colours consistent across both activities: A / Stabilise = light blue; B / Automate = coral; C / Assist = yellow; D / Bounded agentic = green. The colour follows the option—not a maturity ranking—so the team can trace that option from future process to cost-of-solving.

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 — Configure the capability already owned

This is not “a guided intake” in the abstract. Maya’s organisation first checks whether its existing procurement suite already has a supplier-onboarding request type, supplier portal or configurable case form. If it does, the Procurement systems owner configures required fields for the contract, bank details and business owner; Procurement owns the wording and exception policy. If it does not, the deliberately smaller alternative is a controlled Microsoft/SharePoint form with a workflow link—not a PDF sent by email. That choice is recorded because the licensing, configuration, identity and support cost differs.

Modelled process: 1) Procurement opens the existing system’s onboarding request and sends the supplier its authenticated form link; 2) the supplier submits what it has; 3) the form marks missing required evidence and immediately returns a specific request to the supplier, while preserving the partial submission; 4) the supplier uploads the missing item and resubmits; 5) only when the required fields are present does the system create the case and assign Maya as owner; 6) Maya manually sends the now-complete contract pack to Legal; 7) Legal records approval or a query in the case; 8) Maya asks the supplier for a non-standard item and routes the returned evidence back to Legal; 9) after Legal approval, Maya compiles the pack for Finance; 10) Finance validates bank details and creates the vendor; 11) the existing case status, not chaser emails, tells the requester what is waiting and with whom.

The improvement is not an imaginary complete first submission. It is the visible incomplete-case loop, a preserved partial record, a named owner and a system status. Cost-to-solve is primarily configuration, form ownership, access, training and support—not an AI build.

Option B — Add rules and a controlled validation integration

Option B retains the same portal/form and incomplete-case loop, but adds only stable automation. The procurement systems owner configures the required-field rules; the integration owner connects an approved bank-data validation service; Legal and Finance retain their decisions.

Modelled process: 1) the supplier opens the same authenticated portal link; 2) portal rules prevent a complete-submission status until standard mandatory fields are present, while keeping the incomplete case and automatically requesting the named gap; 3) a complete submission creates the case and routes the contract documents to the Legal queue; 4) Legal approves, rejects or returns a query in the case; 5) a Legal approval triggers the approved bank-data validation service; 6) a pass creates a Finance vendor-creation task with the validation result attached; 7) a failure creates an exception task for Finance, not a silent retry; 8) Finance creates the vendor or resolves the exception; 9) the case system sends status notifications to Maya, the supplier and requester only when the state actually changes.

The added cost is rules configuration, integration, permissions, failure recovery and monitoring. It is justified only if the organisation can name who maintains the rule and fixes a failed validation.

Option C — Add bounded document assistance to the same flow

Option C does not replace the portal or the case system. It adds a document-assistance service at one defined point: after a supplier uploads files and before Procurement decides whether they meet the intake rule. The AI service owner defines permitted document types, prompt/version control, retention and evaluation; Procurement owns the final completeness decision.

Modelled process: 1) the supplier submits files through the existing portal; 2) the portal stores them in the approved case repository; 3) the assistance service reads only permitted files and drafts a checklist of likely present, missing or conflicting items; 4) Procurement verifies that draft against the actual files; 5) Procurement triggers the portal’s gap request or marks the evidence complete; 6) the normal Legal route, Legal query loop, bank validation and Finance path then continue exactly as in Option B; 7) a low-confidence draft, unsupported document type or data-boundary failure stops the service and creates a Procurement review task.

The extra cost is service licensing, permissions, document evaluation, monitoring and retained human review. It is not justified merely because documents exist; it is justified only when repeat document checking remains material after A and B.

Option D — Run a bounded agentic orchestration only where interfaces and authority are explicit

Option D is a different system design, not “Option C with more AI.” It requires a named orchestration service, approved access to the portal/case system, Legal and Finance APIs or queues, action logs, a stop policy and an operating owner. The agent may execute only pre-authorised, reversible actions; it cannot waive controls or interpret a non-standard contract.

Modelled process: 1) the supplier uploads through the controlled portal; 2) the agent checks the required-evidence policy against the permitted case data; 3) for a standard missing item it sends the approved portal request immediately, records the action and waits; 4) repeated incomplete submissions loop through that same controlled request path; 5) a complete standard pack causes the agent to open/update the case and route it to Legal; 6) Legal acts only where contract approval, a non-standard clause or an exception requires judgement; 7) after recorded Legal approval, the agent invokes the approved bank validation; 8) a pass triggers the permitted vendor-creation workflow, while a failed/suspicious result stops the workflow and assigns Finance; 9) the agent updates status and sends defined notifications; 10) an unknown document, conflicting evidence, unavailable integration, policy mismatch or any attempted authority boundary stops the agent and creates a named human recovery task.

This option carries the highest integration, assurance, logging, incident-recovery and in-house operating cost. If the organisation cannot name who owns permissions, monitors runs, diagnoses failures and safely changes the workflow, the honest recommendation is to defer it.

These are alternatives and combinations, not a maturity ladder. The model becomes useful because it makes the build choice and its operating cost visible before anyone selects a tool.

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.

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

Only once the team has modelled credible, bounded alternatives and their control boundaries should it compare what each one costs against the burden already visible in the current state. This is not a single ROI calculation. It is a practical priority decision: is there enough evidence that this particular change is worth funding, operating and governing now?

Article 6 activity: make the cost of solving visible

Use Article 5’s three-bucket activity for the other side of the decision: capture the monetary cost, non-monetary effort and operating considerations needed to build, run, recover and maintain each future-state option. Keep the same A–D colour key from the future-state activity, so every cost note remains visibly attached to its option.

Keep four kinds of value separate on both sides of the comparison:

  • Monetary cost: direct effort, licences, integration, configuration, support, monitoring and any credible financial proxy. Do not count elapsed waiting as salary cost or claim savings that cannot be released or redeployed.
  • Non-monetary cost: supplier, customer and employee friction; confidence; service quality; usability; and the burden placed on expert reviewers. These may justify action without being converted into a false euro total.
  • Avoided burden / released capacity: time, rework, repeated reviews or service friction that the model is expected to remove. Record the mechanism and evidence. Treat it as a financial saving only when capacity can genuinely be removed, redeployed or avoided; otherwise it is an operational benefit.
  • Other things to consider: control exposure, recovery from a failure, delivery dependencies, data quality, operating ownership and internal capability. A small agentic workflow is not a small change if every prompt, connector or edge-case fix must be bought externally. If the organisation cannot name who can configure, monitor, diagnose, repair and safely change the workflow, that capability gap is itself part of the cost-to-solve.

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; and
  • ongoing run capability: licences and monitoring, plus the named in-house people or retained service able to maintain the process, integrations, prompts, permissions and exception handling.

Apply the cost method to Maya’s four future-state options

The point is not to invent a universal euro figure. It is to show what each concrete model asks Maya’s organisation to fund, operate and govern—and what burden it can credibly remove.

Option Concrete cost to solve Avoided burden / benefit to test What must be true
A — existing procurement capability or controlled SharePoint form Configure fields, partial-submission record, gap prompts, case status and ownership; test access; train Procurement; maintain the form and wording. Fewer chaser emails; no lost partial submission; less manual reconstruction of case status; faster return of named missing evidence. A systems owner can configure and support the existing capability; Procurement owns the intake rule.
B — rules plus validation integration All of A, plus rules configuration, Legal/Finance queue setup, bank-validation service/API, permissions, monitoring and failure recovery. Removes manual routing and repeated hand-offs for stable cases; avoids late bank-data checks; makes failed validation a visible task. Stable data and rules; an integration owner can diagnose and repair failures.
C — bounded document assistance All of B where used, plus AI-service licence, permitted-document access, prompt/version management, evaluation, monitoring and retained Procurement verification time. Reduces repeated file reading and drafting of standard follow-ups; may shorten the incomplete-evidence loop. Document work is frequent enough to matter; Procurement still verifies every material output.
D — bounded agentic orchestration Portal/case, Legal/Finance and validation interfaces; action permissions; logs; stop policy; incident recovery; security/assurance; an internal operating capability for integrations and workflow change. Removes manual chasing, standard gap requests, routine routing and status updates across the defined standard path. Every action is authorised and reversible; humans own Legal judgement, Finance exceptions and all stop conditions.

Put a monetary range beside each option

Use the organisation’s own loaded internal rate and supplier quotes. The following is an illustrative calculation, not a price list: Maya validates the hours with the named owners, Finance validates the rate and Procurement validates any external quote.

Option One-off calculation Recurring run cost Illustrative total to validate
A Procurement + systems owner: 24–40 hours × €55–€75/hour = €1,320–€3,000 for form/case configuration, test and training. If an existing platform lacks the feature, add a controlled forms/workflow setup quote. Form ownership and support: 2–4 hours/month. €1,320–€3,000 before any new platform licence.
B A, plus rules/queue configuration and validation integration: 50–90 internal/external hours × €70–€120/hour = €3,500–€10,800; add a bank-validation setup/connector quote. Validation transactions, monitoring and recovery: 4–8 hours/month, plus service fee. €4,000–€15,000+, dependent on integration and service quote.
C B where retained, plus document-assistance setup/evaluation: 30–60 hours × €70–€120/hour = €2,100–€7,200; add AI/service onboarding. AI licence/usage, evaluation and Procurement review: 4–10 hours/month plus usage fee. €6,000–€25,000+, depending on the retained B components and document volume.
D Interfaces, orchestration, permissions, logs, stop/recovery design and assurance: 120–250 hours × €90–€150/hour = €10,800–€37,500; add platform, security review and external implementation quote. Platform/usage, monitoring, incident response and internal workflow owner: 12–25 hours/month plus licence. €20,000–€60,000+ before major new-system procurement.

The range is deliberately bounded, not falsely precise. If Maya cannot obtain a supplier quote, confirm an internal rate or name the ongoing owner, that uncertainty remains a cost/risk and can support a decision to defer the option.

For Maya, the expected benefit is not simply “time saved.” For example, if Option B prevents the late bank-data recheck and removes repeated status reconstruction, record the observed number of rechecks and chase minutes, the affected cases and who validates the change. Count a cash saving only if that capacity can actually be removed, avoided or redeployed; otherwise record it as released operational capacity or service improvement.

Option B adds integration and recovery work around routing and validation. Option C adds permissioning for documents, quality checks for the assistant, retained review time, monitoring and an escalation route when its draft is wrong. Option D adds cross-step orchestration, action permissions, durable state, traceable hand-offs, stop conditions and recovery when 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 Cost and capability test Proportionate recommendation
A — Stabilise Can the process owner own a guided intake, case ID and exception route with normal change support? Start here if it removes material rework and chasing.
B — Automate stable seams Are data, rules, recovery and an internal system owner reliable enough? Proceed only for stable, observable steps.
C — Bounded AI assist Can a reviewer validate the output, and can the organisation monitor and tune it? Use only when document work remains material after A and B.
D — Bounded agentic workflow Can named people operate permissions, integrations, logs, exceptions and bug fixes without unsafe dependence on an external supplier? Defer unless the sequence is stable, reversible and genuinely supportable.

Use ranges, named assumptions and a validator where numbers are available. If the organisation cannot yet estimate a cost or name the people who can run the solution, record the uncertainty. That may lead to a responsible conclusion: stabilise now, build capability or measure for six weeks, then revisit automation.

A 90–120 minute future-state co-design workshop

This is the core decision-making activity, not a quick diagramming exercise. Plan 90–120 minutes, preferably in person or online with the people who perform the work, the decision owner and the relevant system/control owners. The goal is two to four credible future-state models, their different boundaries and cost-to-solve profiles, and shared ownership of the route to test. The future-state swim-lane activity and the cost-of-solving three-bucket activity are both part of this one workshop: record a cost, dependency or capability constraint as soon as it surfaces while modelling the relevant step; do not wait to reconstruct it afterwards.

That participation matters. The people asked to work in a changed process are more likely to accept, improve and sustain it when their practical concerns, edge cases and constraints were heard during its design. A model made for people is not yet a model they will operate.

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, system and supplier-facing owner. Bring the current-state map, the pre-modelled options, the 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.

Maya may pre-model the options, and AI may prepare a draft only: cluster de-identified notes, turn the current map into a first list of hand-offs, suggest questions and format the canvas. Neither decides which pain is real, invents policy, identifies an owner or validates a future state. The people affected do that together in the session.

Run it in person

Print the canvas large enough for people to stand around it. Keep the current-state evidence in a neutral card colour, then have light-blue, coral, yellow and green sticky notes ready for the four future-state options: A / Stabilise, B / Automate, C / Assist and D / Bounded agentic. Use the same option colour for that route’s future-process steps and its monetary, non-monetary and operating cost notes; this lets people follow a choice across both activities without confusing the colours with a ranking. Keep a separate neutral colour 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–10 min Restate the real case, current evidence, outcome and non-negotiable controls. Shared scope; no tool choice assumed.
10–25 min Confirm the breakpoints and the normal incomplete/exception loop from the current-state map. Agreed evidence base and constraints.
25–60 min Build and challenge the future-state swim lanes: system/artefact, owner, data, trigger, hand-off, exception and stop point for each viable option. Two to four concrete future-state models.
60–90 min Use the cost-of-solving buckets alongside each model. Capture build, integration, change, assurance, operating capability and avoided burden as each detail emerges. Bounded cost-to-solve and benefit assumptions per option.
90–120 min Compare options, surface unresolved dependencies, choose the proportionate route to validate and assign owners. A proposed decision, evidence gaps, owners and review date.

When a full workshop is not possible

If time only permits a pre-model, Maya must not treat it as agreement. She validates the proposed route in focused 1:1 conversations—in person or online—with each affected role, decision owner and system/control owner. She records objections, missing exceptions and changed assumptions, updates the model, and confirms what each person is prepared to own. This is slower than a shared workshop, but it protects the design from false consensus.

Make a priority decision the organisation can actually carry

The outcome of this article is a recommendation, not a technology preference. Maya places the same evidence side by side: the current burden, the cost and consequence of each future-state option, and the organisation’s capability to carry it after launch.

For the supplier case, the first recommendation may be: choose Option A now; take the stable validation and routing elements of Option B only where the system owner confirms they can operate and recover them; do not add AI assistance or an agentic workflow until repeated document work remains material and named people can support it. That is not a less ambitious answer. It is the lowest-risk, evidence-led route to a result the company can sustain.

If the cost to solve exceeds the evidenced burden, if the capability gap is material, or if no one can own the exception and recovery path, the recommendation can be defer or stop. The team then records what would change that decision: a stronger baseline, a shared service capability, a stable interface, a trained owner or a clearer control boundary. Article 7 turns the chosen, proportionate route into delivery requirements; it does not rescue an option that this comparison has shown the organisation cannot yet carry.

Use-Case Canvas — Maya’s credible future state

After: the selected future state makes the case smaller and more visible, with named owners, explicit control boundaries and a clear exception route.

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 workshop 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