INSIGHTS / TECHNOLOGY & TRANSFORMATION
AI transformation without
decision architecture
becomes expensive activity.
Artificial intelligence creates value when it changes a
commercially important decision, operating process or
customer outcome. Without accountable ownership,
operating redesign and evidence strong enough to support
the next capital decision, a transformation programme can
remain highly visible while the enterprise itself changes
very little.
10 AUGUST 2026 14 MIN READ
![2009CBC1-A4C6-4185-8DBD-933EDE05AFAC[3]_edited.jpg](https://static.wixstatic.com/media/298155_4c16d9f43edb4885ac27c2de8f74016a~mv2.jpg/v1/fill/w_552,h_317,al_c,q_80,usm_0.66_1.00_0.01,enc_avif,quality_auto/2009CBC1-A4C6-4185-8DBD-933EDE05AFAC%5B3%5D_edited.jpg)
OBJECTIVE
Which measurable commercial or
operating result must improve?
OWNERSHIP
Who remains accountable for that
result after the technology has been
delivered?
REALISATION
What decisions, processes and
behaviors must change before value
can appear?
ON THIS PAGE
Introduction
01
Introduction
Why AI programmes
become porfolios of
activity
The technology is rarely
the whole constraint
The unit of transformation
is the operating decision
How value disappears
between pilot and
operation
An Enterprise Decision
The AI Transformation
Decision Architecture
A board portfolio comparison
Questions every board
should answer before
scaling
Closing perspective
The first AI update to the board is usually an easy meeting.
The slides are full. A growing number of use cases has been identified. Several pilots are live. Employees have completed training. Technology partners have been appointed. Adoption is moving in the right direction.
There are demonstrations, and the demonstrations normally work.
A document that took an employee an hour to prepare is produced in seconds. A service agent receives an instant summary of a customer’s history. A sales tool identifies the accounts most likely to buy. A forecasting model detects patterns that would have taken a team days to examine manually.
The room can see the capability.
That creates belief, and belief often leads quickly to a larger programme.
The harder meeting comes later. By then, the programme may have a substantial budget, a central team and visible executive sponsorship. Some tools are widely used. Functions are asking for more licences. Vendors are proposing the next phase.
Then somebody asks which enterprise result has actually changed.
Not how many people are using the tools. Not how much time the pilot suggests could be saved. What changed in revenue, margin, working capital, customer retention, service quality or operating capacity?
The answer is often less certain than the adoption report.
The sales assistant is helping employees prepare more quickly, but conversion has not moved. The customer service tool has reduced handling time, although repeat complaints remain at broadly the same level. The procurement model is identifying possible savings, but local managers are not required to act on its recommendations.
The forecasting system may produce a better view of demand. The planning meeting still happens monthly, on the same timetable, with the same authority structure and much of the same managerial override.
There may be value inside every one of those initiatives.
The organisation has not yet shown that it can realise it.
This distinction is easily lost because artificial intelligence produces activity unusually quickly. A conventional transformation programme may take months before anyone sees a working output. An AI prototype can be persuasive within days.
A technically impressive result begins to feel like an operating result. A positive pilot begins to feel like a scalable case. Employee enthusiasm begins to feel like evidence of enterprise value.
When the evidence remains incomplete, the programme rarely becomes quieter.
Another use case is added because the first has not generated enough proof. A second vendor appears because one function wants a different capability. Training expands because low adoption is assumed to be the constraint. More reporting is requested because the board wants assurance.
The enterprise becomes increasingly active around AI.
It may still be operating much as it did before.
The issue is not whether the technology works. Much of it does. The issue is whether the organisation has designed the decisions, ownership, operating changes and evidence through which technical capability can become enterprise value.
A transformation programme can remain busy for a long time before anyone is willing to say that the result is unclear.
That is what makes it expensive.
A transformation programme can remain busy for a long time before anyone is willing to say that the result is unclear.
02
Why AI programmes become portfolios of activity
Most AI portfolios begin for sensible reasons.
The organisation does not yet know which applications will prove valuable. Functions are encouraged to experiment. A central team establishes standards and approved vendors. Early investment is spread across several areas so the company can learn.
Exploration becomes a problem when nobody decides when exploration has ended.
Customer service identifies six use cases. Finance identifies eight. Human resources, procurement, legal, sales and operations add their own.
Some are large. Some are minor productivity improvements. Some are speculative. Several solve versions of the same problem without recognising it.
Soon there is a portfolio.
The portfolio has a steering committee, a prioritisation model and an expanding set of status labels. Green means the pilot is progressing. Amber means a dependency is being managed. Red is used less often than expected.
The initiatives are rarely absurd.
A meeting summary tool may genuinely save time. A contract review assistant may improve consistency. A forecasting model may improve accuracy. A customer agent may reduce the effort required to resolve ordinary enquiries.
The weakness lies in the standard used to keep the work alive.
At the beginning, the use case is justified by a commercial hypothesis. Later, it may survive because employees like it, a senior sponsor remains interested or the vendor has demonstrated an attractive next feature.
The question gradually changes from:
to:
Is this creating enough value to deserve further investment?
Is there still some possibility that this could become valuable?
That is a much lower threshold.
Every use case also develops an internal constituency. A function has spent time designing it. An executive has referred to it publicly. Employees have joined the pilot. A vendor has invested in the relationship. The transformation team has included the initiative in its progress reports.
Stopping it no longer feels like routine portfolio management. It feels like a reversal.
The scope is adjusted. The benefit is reclassified. The timetable moves. The pilot becomes an extended pilot, then an operating trial, then a capability that is technically available but not fully embedded.
Some initiatives remain in this state for a surprisingly long time.
A disciplined portfolio should become smaller as knowledge improves.
Early experimentation may create thirty credible ideas. Evidence should eliminate most of them. A mature programme may discover that five opportunities have a believable route to material value, ten are useful local tools, several need basic process or data work and the remainder should stop.
That narrowing can look like reduced ambition. It is usually the point at which ambition becomes investable.
Some pilots should end without ceremony. They performed the function of a pilot: they produced information.
The organisation does not need to turn every experiment into a programme merely to prove that the original decision to explore was sensible.
03
The technology is rarely the whole constrain
An underperforming initiative tends to send attention back towards the system.
The data needs further cleaning. The model needs greater accuracy. The interface needs improvement. Integration remains incomplete. Employees require more training.
Any of these may be true.
They may not be the reason value has failed to appear.
A sales organisation may deploy a capable system to identify which accounts deserve attention. The recommendations can be accurate and commercially sensible.
The expected benefit will still fail to materialise where account executives are rewarded for protecting established relationships, managers continue allocating opportunities manually or the recommendations arrive after the customer’s buying decision has already begun.
A predictive maintenance system may identify likely equipment failure with impressive accuracy. The organisation may still lack the spare parts, engineering capacity or authority required to interrupt production.
A procurement tool may reveal that several divisions are buying the same category separately and at different prices. Local executives may retain independent budgets, resist standardisation and believe their requirements are unique.
No technical improvement will resolve that disagreement.
A service tool may draft faster responses to customer complaints while the largest cost continues to come from an operational failure that the service team cannot correct. The customer receives a better written apology. The underlying economics remain unchanged.
These situations are often described as adoption problems, that can be misleading.
Employees may be using the technology exactly as instructed. The value chain still breaks further downstream.
The useful question is therefore not only whether the system performs. It is whether the organisation can explain the route between the system’s output and the commercial result.
Who receives the information? What decision should follow? Does that person have authority? What else changes once the decision is made? Which existing behaviour must stop? What incentive supports the new action? Where can local discretion override the intended process? How will finance distinguish realised value from an estimate?
Those questions cross several functions.
Technology may own the platform. Operations owns the workflow. Finance determines whether the benefit has been realised. Legal and risk define limits. Human resources may need to change roles or incentives.
The business executive responsible for the commercial outcome must coordinate the whole chain, yet that person is not always the person shown as the programme owner.
This creates a familiar boardroom problem.
Technology reports that delivery is on schedule. The function reports that adoption is increasing. Finance reports that no verified benefit can yet be recorded.
All three statements may be true.
The initiative can be technically successful, operationally active and commercially unresolved at the same time.
04
The unit of transformation is the operating decision
The use case is a convenient unit for organising a technology programme.
It tells the enterprise what the system will do.
That is not enough to explain how the enterprise will operate differently.
Consider customer retention.
A use case may be described as:
Use artificial intelligence to predict which customers are likely to leave.
That statement is sufficient to begin technical work. Data can be assembled. A model can be trained. Accuracy can be measured.
It does not yet define the transformation.
The operating decision is broader:
When should the company intervene, with which customer, through which channel, using what commercial authority and at what cost?
That decision raises questions the model cannot settle.
What level of churn risk warrants intervention? Which customer segments justify a retention offer? Should the company protect revenue, margin or long term relationship value? Who can approve a concession? What happens when the sales team disagrees with the recommendation? How will the company avoid discounting customers who would have remained anyway?
Until those questions are answered, the organisation has a prediction capability.
It does not yet have a retention architecture.
The same distinction appears elsewhere.
A use case describes a tool.
The operating decision describes an organisational commitment.
That commitment normally requires changes to workflow, authority, information, incentives and measurement. It may also require the organisation to remove something: an approval step, a local exception, an existing report or a role that existed because information was previously difficult to obtain.
This is where programmes often become cautious.
The technology is permitted to recommend, but not to alter the real decision process. Employees are encouraged to use the output, but no existing authority changes. Managers may ignore it without explanation. Local functions retain their own methods.
The new system sits beside the old operating model.
It creates another layer of work.
A serious transformation design should be able to describe, in ordinary language, what people and systems will do differently when the initiative is working properly.
Where that remains vague, the organisation may still have a useful experiment.
It does not yet have a transformation design.
05
How value disappears between pilot and operation
Pilots are supportive environments.
The participants are selected carefully. Senior sponsors are visible. The vendor responds quickly. Data problems receive immediate attention. Exceptions can be handled manually. Everyone knows the initiative is being watched.
Ordinary operation is less accommodating.
Teams have other priorities. Data arrives late. New employees join. Managers protect local processes. Exceptions accumulate. The vendor is no longer present in every meeting.
A capability that worked convincingly in a controlled group may struggle when it meets the organisation as it actually exists.
The first loss often occurs in the baseline.
The business case estimates that a task consumes twenty minutes, a process costs a certain amount or an error occurs at a particular rate. Nobody has measured the current position carefully enough to know.
When the initiative goes live, the programme can show improvement against its own assumption but not against a defensible operating baseline.
Finance hesitates to validate the benefit.
Sometimes this is genuinely a measurement delay. Sometimes the original value case was never solid.
The second loss occurs with time savings.
An employee saves half an hour a day. That number is multiplied across hundreds or thousands of people and presented as a substantial annual benefit.
The salary cost remains unchanged. The work is not redesigned. The released capacity is gradually absorbed by email, meetings and additional tasks.
The time saving is real.
The financial benefit may not be.
This does not mean employee productivity lacks value. It means the organisation must decide what the newly available capacity is expected to achieve.
Will headcount growth be avoided? Will customer volume increase? Will a backlog be removed? Will higher value work replace the activity?
Without an answer, the benefit remains theoretical.
Value also disappears at the edge of the improved task.
The system completes one step in seconds. The output then waits for the same approval, handover or weekly meeting as before. The local process becomes faster. The customer or financial outcome barely changes.
Ownership can weaken after launch.
During the pilot, an executive sponsor attends meetings and removes barriers. Once the system is deployed, responsibility fragments.
Technology maintains the platform. The business function assumes the transformation team is tracking benefits. The transformation team assumes the business owns adoption. Finance reviews the programme during the annual planning cycle.
The result no longer has an active owner with the authority to intervene.
The most difficult cases then begin to redefine the economics.
The system handles ordinary work. Exceptions are sent to people. The exceptional work is slower, more expensive and more consequential.
Over time, the exception rate rises because teams learn where the system is uncomfortable or because the remaining cases are inherently complex.
The programme continues reporting that automation touches most transactions.
Employees continue doing the hardest part.
A capable board should expect some pilots to be redesigned and some to stop. Where every review ends in continued investment, the review is probably not testing value very seriously.
06
An Enterprise Decision
A multi division distribution and services group had committed just over £10 million to artificial intelligence and automation across roughly two years.
The programme had become difficult to describe simply.
More than forty use cases had been identified. Close to twenty pilots were active at various stages. Several technology partners were involved. A central AI team had been established, and thousands of employees had completed some form of training.
Depending on the definition used, between six and ten tools were described as deployed.
That range became important.
Technology counted a solution as deployed once it was technically available to the intended users. Operations counted it only when it had become part of the normal workflow. Finance counted it when a benefit could be observed against an agreed baseline.
The programme had three different versions of progress.
Several initiatives were genuinely useful.
Sales teams prepared account material more quickly. Customer service agents no longer had to search several systems before understanding an ordinary case. Procurement analysts could see patterns across divisions that had previously been buried in separate reports. Finance produced forecasts more frequently.
The difficulty was not the absence of improvement.
It was the failure to connect those improvements consistently to enterprise outcomes.
The sales tool was popular. Conversion had barely moved because the company had not changed account allocation, incentives or the rhythm of sales management.
The service tool reduced preparation time. Repeat contacts remained expensive because the underlying operational failures sat in different divisions.
Procurement identified substantial theoretical savings. One division refused to share a reliable baseline because its managing director believed central procurement was using the AI programme to remove local authority.
Finance produced better forecasts. The executive planning process continued to operate monthly because senior leaders did not want to change the meeting cycle during a wider reorganisation.
These were not peripheral implementation details.
They were the organisation.
The board’s concern increased when the next investment request arrived.
The central programme wanted additional capital to scale the tools with the strongest user adoption. The most widely used product was a meeting and document assistant. Employees liked it. The efficiency benefits were obvious at an individual level.
The chief financial officer could not identify a meaningful cash or capacity outcome.
The chief technology officer argued that insisting on immediate financial proof would cause the company to underinvest in a capability that was becoming basic infrastructure.
Both positions had merit.
The board considered three broad routes.
Route A: scale the initiatives with the strongest adoption
This route had visible support.
It would show momentum, reduce average licence cost and respond to employee demand. It would also give the organisation broad experience of using AI in everyday work.
The problem was that adoption had become the most available measure rather than the most relevant one.
The tools employees enjoyed were not necessarily connected to the most valuable operating constraints.
Scaling them could be justified as a productivity decision.
It could not automatically be presented as enterprise transformation.
Route B: centralise investment and benefit control
The chief financial officer proposed a stronger central gate.
All material AI expenditure would require an approved baseline, a named benefit owner and finance validation. Vendors and licences would be consolidated. Functions would not be permitted to launch additional pilots independently.
This would reduce duplication and improve discipline.
Several division leaders resisted.
They argued that central teams did not understand local processes well enough to judge early opportunities. One pointed out that finance refused to recognise time savings unless they translated directly into headcount reduction, even where customer capacity had clearly improved.
Finance was right that theoretical hours should not be reported as cash.
The division was right that cash was not the only legitimate form of value.
That disagreement was not resolved completely.
Instead, the group agreed to classify value more explicitly and to show where conversion into financial benefit remained unproven.
Route C: rebuild the portfolio around a small number of operating outcomes
The group identified three enterprise outcomes for deeper work:
reduce avoidable attrition among the highest value customers
release working capital through better collections and purchasing decisions
shorten the quote to order cycle in two complex divisions
Existing tools would be retained where they contributed to those outcomes.
Some pilots would be reclassified as ordinary productivity utilities.
Others would stop.
This route was the most demanding politically because it required the organisation to say that some successful technology deployments were not strategic transformation.
One highly visible pilot had been sponsored personally by a member of the executive committee. Its adoption was strong. Its value case was weak.
No one was eager to recommend closure in the first portfolio meeting.
The initiative survived that meeting.
Three months later, it was retained as a limited utility with a smaller budget and removed from the transformation portfolio.
That decision established that useful and strategic were not the same classification.
The final operating model combined elements of the available routes.
The central AI team retained responsibility for technology standards, risk controls, shared infrastructure and vendor management.
Business executives became accountable for outcomes.
Finance agreed a broader value taxonomy covering cash, cost avoidance, capacity, risk and customer impact, but each initiative had to state which category it was claiming.
Every active pilot received one of four decisions:
scale
redesign
retain as a utility
stop
Not every issue was closed neatly.
One division continued disputing the procurement baseline. A customer initiative required another quarter of evidence before broader deployment. Several time saving benefits remained credible but unconverted into financial value.
The programme was still unfinished.
The principal board report no longer opened with the number of pilots, licences or trained employees. Those measures remained in the appendix.
The main discussion focused on the outcome, baseline, operating decision, accountable executive, evidence realised and next capital decision.
The portfolio became smaller.
The board could finally see what remained uncertain.
07
The AI Transformation Decision Architecture
A transformation initiative should make its route to value visible before large scale deployment.
The architecture does not remove uncertainty. It allows the uncertainty to be governed.
Six questions matter.
1. What enterprise result must change?
The objective should be stated in commercial or operating terms: revenue, margin, working capital, service quality, cycle time, risk or operating capacity.
“Improve productivity” is too broad unless the organisation can explain where capacity will be released and what will happen to it.
2. What prevents the result today?
The principal constraint may be poor information, limited capacity, inconsistent judgement, fragmented data, slow authority or an incentive that produces the wrong behaviour.
The most visible manual task is not always the true constraint.
3. Which decision or workflow will operate differently?
Who receives the output? What action follows? Which approval is removed or retained? Where can a manager override the recommendation? How are exceptions handled? What work ends?
A deployment plan explains how the system becomes available.
This part explains how the business changes.
4. Who owns the result?
The owner should possess enough authority to change the process surrounding the technology.
A programme director can coordinate delivery. A chief technology officer can remain accountable for the platform. The commercial result should sit with the executive controlling the relevant operating conditions.
5. What must be ready?
Data, integration and technical performance matter. So do employee capability, legal constraints, incentives, process discipline and stakeholder acceptance.
A pilot may be testing the technology.
It may also be testing whether the organisation is capable of using it.
6. What evidence will determine the next decision?
What must be visible after thirty, sixty or ninety days? What would justify further capital? What would require redesign? Who can narrow the scope? What would cause the initiative to stop?
The aim is not to impose rigid gates on every experiment.
It is to prevent elapsed time from becoming the main reason an investment continues.
08
A board comparison
AI opportunities can be assessed across seven dimensions.
The scoring is not intended to produce an automatic investment decision. It makes assumptions visible.
Each dimension is scored from 1 to 5.
The meeting assistant scores reasonably well because it is easy to adopt, technically scalable and capable of producing evidence quickly.
Its enterprise value score remains low.
That does not make it a bad investment. It makes it a different kind of investment.
A useful portfolio distinguishes between three categories.
Utility
A tool that improves the work of individuals or teams and can be governed through ordinary technology, security and cost controls.
Operating improvement
A capability that changes a defined process and creates measurable value within a function or business unit.
Enterprise transformation
An investment that changes a material decision, operating model or source of value across significant parts of the organisation.
These classifications should remain open to revision.
A widely adopted utility may reveal a larger operating opportunity. An initiative originally described as transformational may ultimately prove valuable only within one function.
The category should change when the evidence changes.
09
Questions every board should answer before scaling
What business result must change?
The answer should be expressed in operating or commercial terms.
A capability is not a result.
What would the organisation do differently?
Which decision, workflow, role or allocation of resources will change once the initiative is successful?
Where the answer is limited to “employees will receive better information,” the operating design is probably unfinished.
Who owns the value?
The person presenting the technology update may not own the result.
Which executive is prepared to accept an operating target connected to the initiative?
Is the baseline credible?
Can present cost, speed, quality, conversion, error or capacity be described well enough to demonstrate improvement?
Some baselines will be imperfect. The board should know where that uncertainty sits.
What is the actual constraint?
Poor information? Slow authority? Fragmented data? Limited capacity? Conflicting incentives? A process built around manual work?
The answer may reveal that AI is central to the solution.
It may reveal that it is only one component.
What work will stop?
A new tool is often added without removing an existing report, approval, meeting or responsibility.
Where productivity is claimed, what activity or capacity will actually be removed, avoided or redirected?
Can people act on the output?
A recommendation has little value where employees lack authority, managers can ignore it without explanation or local divisions retain conflicting processes.
What is being supplied manually inside the pilot?
Data preparation. Exception handling. Vendor support. Management attention. Specialist judgement.
Which of those will still exist at scale?
What evidence will justify the next capital decision?
The threshold should be defined before enthusiasm becomes the principal reason to continue.
What would make the board stop?
Which executive would still defend the initiative if adoption figures were removed from the board paper?
The answer may reveal whether the organisation is funding transformation or protecting a programme.
Would the architecture survive a change of vendor?
Technology partners and models will change.
The organisation should still understand the objective, operating decision, ownership and evidence without relying on one provider’s terminology.
10
Closing perspective
Artificial intelligence will become easier to acquire.
Most large organisations will have access to capable models, established platforms and experienced vendors. Competitors will be able to purchase similar classes of technology.
The lasting advantage will sit elsewhere.
It will sit in the organisation’s ability to identify the right constraint, connect technical capability to an important decision, redesign the surrounding work and learn from evidence without protecting weak investments indefinitely.
That is an operating capability.
The current volume of AI activity can obscure it.
A company with fifty pilots may appear more ambitious than one funding three. The second may be moving faster if those three initiatives are attached to material outcomes, owned by executives with authority and supported by operating changes the organisation is prepared to make.
Boards should continue permitting experimentation.
The technology is developing too quickly for every opportunity to be understood in advance. Some value will only become visible through practical use.
Exploration and transformation should not be reported as though they are the same thing.
Exploration asks what the technology might make possible.
Transformation decides what the enterprise intends to change and accepts the organisational consequences of doing so.
Those consequences are rarely limited to deployment.
Authority may move. A process may need to be standardised. Local discretion may narrow. An old report may disappear. A role may change. A popular pilot may be retained as a useful tool while losing its strategic status.
Another may stop.
These decisions are harder than purchasing another capability, which is why they are often deferred.
The central board question is not how many AI initiatives are active or how quickly employee usage is rising.
It is whether the organisation can identify which commercially important results are now more achievable because its decisions, processes and ownership have changed.
A credible answer will include technology.
It will also include evidence, operating discipline and accountable executives.
Without those conditions, AI transformation becomes expensive activity.
Before approving another pilot or scaling the current portfolio, answer one question:
Which enterprise result will be different, who owns it, and what evidence will determine whether the investment continues?
Many organisations already possess AI strategies, approved platforms, active pilots and growing employee adoption.
The harder question is whether those activities form a governed route to measurable commercial and operating value.
Our work is normally undertaken before material AI capital is committed, before a pilot portfolio enters large scale deployment or where significant activity has not yet produced decision grade evidence of value.
Where a wider strategic mandate is unnecessary, we will say so.
An AI Value Realisation Review examines:
The objective
Which enterprise outcomes the transformation portfolio must change and what economic, strategic or operating value is at stake.
The portfolio
Which initiatives are utilities, local operating improvements or genuine enterprise transformation, and where capital is being diluted across weakly qualified activity.
The operating decision
Which decisions and workflows must change before technical capability can produce value.
Ownership and authority
Who owns each result, whether that person controls the relevant operating conditions and where responsibility is presently fragmented.