There is a familiar moment in large transformation programmes when the organisation begins to celebrate. The platform is live, the migration is complete, the training has been delivered, and the steering committee can finally move another milestone to green. After months or years of effort, everyone is entitled to feel some relief.
The difficulty is that none of those things prove the business has changed. Six months later, people may still be keeping side spreadsheets, managers may still ask for the old reports, frontline teams may still work around the new process, and the expected commercial impact may remain stubbornly difficult to find.
That gap between implementation and impact is where many technology investments quietly lose value. Companies are generally disciplined about delivering capability and much less disciplined about changing the behaviour, incentives and operating routines required to use it well. The technology may be functioning exactly as designed while the organisation continues to operate much as it did before.
For executives, that distinction matters because transformation is not the installation of a new system. It is the point at which the system changes how work gets done, how decisions get made and, eventually, how the economics of the business improve.
Go-live is the beginning of value creation
Large technology programmes are naturally managed around delivery. Scope, build, test, migration and launch all need clear ownership because complex programmes fall apart without it. The danger comes when delivery discipline becomes confused with business success.
A new CRM can provide richer customer histories, better recommendations and a more complete view of behaviour across channels. None of that matters much if sales teams are still measured in ways that encourage them to ignore the information, or if managers continue to run the same routines they used before the system existed. The organisation has acquired capability, but not necessarily changed the way it operates.
The same pattern appears with analytics. A company can build a sophisticated dashboard and still find that senior teams request manual summaries before every meeting because they do not trust the underlying data or have not changed the decision process around it. The dashboard becomes one more source rather than the operating view of the business.
ERP programmes expose the problem even more clearly. Standardised processes go live, but local exceptions return through spreadsheets, side systems and informal approvals because the organisation has never resolved the underlying disagreement about how the work should actually be done. Technically, the implementation is complete; operationally, the old company is rebuilding itself around the new technology.
None of this means the technology team failed. In many cases, it means the organisation defined success too narrowly. If implementation is the objective, go-live is an endpoint; if business value is the objective, go-live is when the real transformation starts.
Adoption is designed into the operating model
When a new system struggles to gain traction, the easiest explanation is that people resist change. That can be true, but it is often a lazy diagnosis. Employees are usually very good at reading the incentives, trade-offs and operational reality around them.
A store associate can be trained perfectly on a clienteling tool and still avoid it during a busy period if the workflow slows the interaction and the store is measured primarily on throughput. A merchant can understand an AI recommendation and continue overriding it if accountability remains entirely with the human decision. A service agent can have a complete customer view and still prioritise call duration if that is what the performance system rewards.
Those behaviours are rational responses to the environment the organisation has created. People pay attention to what leaders reward, what managers inspect and what makes their job easier or harder, often far more closely than they pay attention to the language of the transformation programme.
This is why I have never found training alone to be a convincing adoption strategy. Training explains how a tool works; adoption depends on whether the process, incentives, management routines and accountability make the new behaviour sensible. If those surrounding conditions still reward the old way of working, most people will eventually return to it.
Technology therefore has to be introduced with an operating-model question attached. The decisions that should change, routines that should disappear, measures that should be replaced and leaders who need to behave differently are all part of implementation. Treating them as post-launch change management is usually how they end up becoming somebody else’s problem.
Every business case contains behavioural assumptions
Most investment cases are explicit about technology cost, implementation time, productivity, revenue and expected return. The more fragile assumptions are often behavioural and receive much less scrutiny.
A planning platform assumes planners will trust its recommendations. A customer-data investment assumes employees will capture information consistently. An omnichannel capability assumes store teams will support journeys whose economics may land elsewhere. An AI tool assumes that time saved will be redeployed into more valuable work rather than absorbed by the same volume of meetings and administration.
Those assumptions frequently determine whether the financial case is real, yet they rarely receive the same challenge as implementation cost or expected revenue.
Consider a productivity model that says a new capability saves two hours per employee each week. Multiplied across a large workforce, the number can look compelling. Yet two hours saved does not automatically become two hours of economic value; unless workloads, staffing, priorities or output expectations change, the benefit can remain trapped inside the spreadsheet that justified the investment.
Revenue assumptions are vulnerable in the same way. A personalisation engine may identify better opportunities, but value only appears if campaign planning, offer selection, content, measurement and decision rights change enough to use those insights properly. Better recommendations inserted into an unchanged commercial process may produce improvement, but rarely the full transformation the business case originally implied.
This is why I increasingly think technology ROI should be tested through behaviour as much as finance. Leaders need to identify the actions that must change for each benefit to materialise, who owns that change and what evidence will demonstrate that it actually happened.
The exercise makes some business cases less comfortable. That is useful. It is better to discover before spending the money that the return depends on changing a deeply embedded commercial behaviour than to discover it eighteen months after the technology has gone live.
The old operating model will try to survive
Large organisations have a remarkable ability to absorb new technology without fundamentally changing themselves. Processes, governance and incentives are built over years, and they develop a kind of organisational memory that is much harder to replace than software.
The result is often a horizontal technology capability inserted into a vertical operating model. Customer data connects across channels while channel P&Ls remain separate. AI optimises across the enterprise while individual teams are rewarded for local outcomes. A workflow removes the practical need for an approval, but the approval survives because changing governance feels more difficult than changing the system.
Omnichannel transformation provides a useful example. It is technically possible to let a customer discover online, interact with a store, buy through another touchpoint and fulfil from whichever inventory location makes the most sense. The more difficult conversations are usually about credit, ownership, cost and accountability.
If a store associate spends time helping a customer complete a transaction that is recognised in an e-commerce P&L, the system may be connected while the incentives are not. If inventory is shared but every function is still measured on protecting its own pool, the technology creates visibility without changing behaviour. The customer experiences one brand while the organisation continues negotiating internally about whose sale it was.
Many programmes reach their ceiling at precisely this point. The technology has made a better operating model possible, but leadership has not removed the structures that keep the old one economically rational.
Adoption accelerates when the new model becomes the normal way to operate rather than an additional option. That may mean retiring old reports, removing duplicate workflows, changing attribution rules or stopping the production of shadow data. Running the old and new worlds indefinitely feels safer, but it gives the organisation permission not to choose.
There is a practical lesson here for executives. Some of the most important transformation decisions happen after the technology has been delivered, because that is when leaders have to decide which parts of the old organisation are no longer allowed to survive around it.
AI makes this problem harder to ignore
AI is making capability easier to distribute. A recommendation can appear inside an existing workflow, a copilot can reduce administrative effort without a major interface change, and an agent can perform work that previously required several manual steps. On the surface, that makes adoption look simpler.
The deeper challenge is that AI changes judgment as well as process. A model can recommend a price, but the merchant has to decide when to trust it. An agent can resolve a customer issue, but someone has to define the authority within which it can act. A system can identify the next best action, but the business still has to decide whether its governance, incentives and risk appetite allow that action to happen.
This creates a more subtle adoption gap. Employees may use AI every day and the organisation may still capture only a fraction of the potential value because decision rights, workflows and management routines remain unchanged. High utilisation can therefore become a misleading measure of success.
The useful measures sit further downstream. Decision speed, conversion, service resolution, inventory productivity, margin, cycle time or revenue per employee tell us whether the capability has changed the business. The right metric depends on the investment, but it should be connected to the economic outcome the technology was intended to improve.
AI also sharpens the productivity problem. If a system makes an old process faster, leaders still need to examine whether that process deserves to survive. There is limited strategic value in using advanced automation to produce a report nobody should need or to reconcile two systems whose disagreement should have been resolved years ago.
As capability becomes cheaper and faster, organisational complexity becomes more visible. Technology teams can automate around that complexity for a while, but eventually the business has to decide which work, approvals and handoffs no longer create enough value to justify their existence.
That is an important distinction in the current AI investment cycle. Automating existing work can produce benefits quickly, but the larger prize often appears when the organisation redesigns the work itself.
Transformation needs an owner after launch
One reason value leakage persists is that responsibility becomes fragmented once implementation finishes. Technology owns delivery, the business owns operations, finance owns the business case, and change teams own training. After launch, everyone has contributed and nobody is clearly accountable for whether the promised economics are actually appearing.
A transformation therefore needs an explicit value owner beyond go-live. That person does not need to own every operational lever, but they do need enough authority to bring together adoption data, process performance and financial outcomes, then force action where the expected value is not materialising.
Sometimes the problem will be training. Sometimes the workflow is poor, the feature is unnecessary, the incentive is wrong or the original business case was optimistic. Mature transformation leadership has to be willing to discover any of those things without treating the finding as an embarrassment.
The discipline is to keep following the causal chain from capability to behaviour to operating model to business outcome. When that chain breaks, the programme needs to identify where and address that layer rather than taking comfort from the fact that the software itself is stable.
Six months after launch, I am less interested in the number of users trained or licences activated than in whether people are making different decisions, whether customers are experiencing something meaningfully better, and whether work or cost has actually disappeared. Those measures are harder because they can reveal that a technically successful programme has not yet become a commercially successful one.
The enterprise technology market will continue producing more capable systems, and AI will make those capabilities easier to deploy. That does not reduce the importance of adoption; it raises it, because organisations will increasingly be able to buy possibility faster than they can absorb change.
Technology matters enormously, but it does not create value simply by arriving. Value appears when the organisation learns to operate differently because the capability exists, and when that difference finally shows up in the economics of the business.