D12 — can you see the operating model change

I have sat in a lot of AI program reviews where the dashboard was thriving and the business was not.

The slide is always reassuring. Licences provisioned, near the cap. Monthly active users, climbing. Logins per week, a healthy line that bends the right way. Someone has clearly worked hard on it. And then a quieter person at the end of the table asks the only question that matters — has anything actually changed in how we work — and the room goes carefully vague. The metrics measured that people had been given a tool and had touched it. They did not measure whether a single decision was now being made differently, or whether any of the value the program was funded to deliver had arrived.

That gap is the work of D12, Adoption and Change Instrumentation, in the framework. It is the twelfth dimension, the second and final one in the Enablement pillar, and it is where the whole framework is supposed to close its loop. You cannot govern, improve, or defend an AI portfolio you cannot see being adopted. And almost everything most organisations call adoption measurement is, on inspection, a count of seats and a count of clicks.

The turn this dimension asks for is unglamorous but decisive. Stop measuring access. Start measuring change.

Access metrics are the ones that come for free. The platform vendor ships them. They are easy to collect, easy to chart, and almost entirely uncorrelated with whether the investment thesis is holding. A provisioned licence is a cost, not an outcome. A login is an act of curiosity, not a change in the operating model. Depth of use is closer — D12.1 cares about whether people return, whether they use the capability for the work it was meant for, where they drop off, and why — but even depth of use is only a proxy. The thing the framework actually wants to see is behaviour, and behind behaviour, value.

So D12.1 is about adoption telemetry that distinguishes a tool being present from a tool being relied upon: uptake by role and use-case class, depth of use against the workflow it was funded to change, retention past the novelty window, and the friction telemetry that shows where users abandon the path and what stopped them. The maturity signal is not the size of the numbers. It is whether the numbers are tied to a specific behaviour the organisation was trying to change, and whether someone is accountable for acting when they stall.

This is the point in the essay where I have to name a discipline that is not mine and defer to it honestly. Measuring behaviour change and value realisation well is the province of change management and behavioural measurement specialists. Attributing an outcome to an intervention — separating what the AI did from what the market, the season, the reorganisation, or the new pricing did — is a question of measurement design that behavioural and analytics specialists own. The operating-model question I can speak to is narrower and prior to theirs: is the organisation capturing evidence in a form those specialists can actually use, and is that evidence connected to a decision, or is it a dashboard that exists to be admired? In doubt, I would rather defer the methodology and get the plumbing right than invent an attribution model that a competent analyst would not sign.

D12.2 is friction and change instrumentation, and it is where the surveillance trap lives. Instrumenting adoption can curdle very quickly into instrumenting people. The moment the telemetry becomes a way to rank individuals, to flag the slow adopters, to feed a performance conversation no one consented to, the program has changed character. People will route around a tool that watches them, and they are right to. So the discipline here has a hard edge: instrument the workflow, not the worker. Measure where the process snags, not who is slow. Aggregate, anonymise where the question allows it, and be explicit with the workforce about what is collected and why. This is also where Privacy Act 1988 obligations can engage if adoption telemetry captures personal information about employees, and where the right move is to bring privacy counsel in early rather than to discover the exposure later — privacy and, where it applies, workplace-relations specialists determine what monitoring is lawful and what it requires. The operating model’s job is to make the purpose legitimate and visible: instrument for learning, not for monitoring.

D12.3 is the change-management and communication discipline that turns telemetry into adjustment. A friction signal that no one is resourced to act on is just a more sophisticated complaint. Mature change instrumentation closes the short loop — a drop-off is identified, a cause is hypothesised, an enablement or design change is made, and the signal is watched to see if it moved. This connects directly to D11, the workforce literacy and human-in-the-loop dimension that publishes alongside this one: much friction is not a tooling defect but a capability gap, and the instrumentation should be able to tell the difference and route the fix to the right owner. The discipline of designing and running that change is, again, a change-management specialism. The framework’s contribution is to insist the loop exists and that someone owns its closure, not to script the change program.

D12.4 is where this dimension stops being about enablement and becomes about the whole framework. It is value-realisation feedback, and it connects deliberately back to D2.3, the value-realisation tracking inside the AI-to-value dimension, and to D1.3, the profit-and-loss hypothesis that the strategy and leadership dimension asked every material initiative to state. The logic of the framework is a loop. D1 and D2 made a claim: this initiative will change this part of the operating model and produce this value. D12 is the dimension that goes and checks. Did the behaviour change the strategy predicted actually occur? Did the value the P&L hypothesis promised actually land, or land partially, or not at all?

That feedback only matters if it is allowed to be bad news. A value-realisation loop that can only confirm success is a marketing function wearing a measurement badge. The maturity signal in D12.4 is whether the loop has ever changed a portfolio decision — whether a use case that adopted well but delivered no measurable value was paused, whether a thesis that the evidence contradicted was rewritten, whether money moved because the instrumentation said it should. An honest feedback loop occasionally embarrasses the program that built it. That is not a failure of the loop. It is the only proof that it is real.

D12.5 is continuous improvement and iteration discipline, the habit that keeps the other four from decaying into a one-off measurement exercise. AI capabilities drift, models change underneath SaaS features, the workflow the tool was funded to change keeps moving, and an adoption picture that was true two quarters ago is now decoration. Mature iteration discipline has a cadence: the telemetry is reviewed on a rhythm, the friction backlog is groomed and resourced, value-realisation evidence is reconciled against the original hypotheses, and the conclusions feed the next round of portfolio prioritisation. The signal is not how often the team meets. It is whether the meeting ever changes what the organisation does next.

And this is exactly where “integrate adoption into the existing change forum” becomes too soft to trust. It is true that this work should live in committees the organisation already runs — a transformation or operations forum, a portfolio or investment committee, the existing executive review where the AI program reports. Standing up a fresh adoption bureaucracy would read, rightly, as naive. But integration on its own is not a control. The accountability has to be explicit: who owns the adoption and value signal, what decision right do they hold when value is not landing, and which gate does the evidence actually feed — the funding gate at the portfolio review, the continue-or-stop gate for a stalled initiative, the reprioritisation gate when the thesis is wrong. The accountable path could run through a COO who owns operational change, a CHRO who owns workforce adoption, a product or transformation executive, an extended CIO/CDO/CTO mandate, a chief AI officer where one exists, or CEO-direct sponsorship for the portfolio. The framework requires the named accountability and the gate it feeds, not a particular title above the door.

The L4 buyer question for D12 is deliberately uncomfortable. Take one material AI initiative that has been live for at least two quarters. Show the original value hypothesis from its D1.3 and D2.3 records. Then show same-period adoption depth, friction telemetry, the value-realisation evidence, and the portfolio decision that evidence drove — a continuation, a redirection, a pause, or a defunding — with the forum and the named owner who made it. The point of asking for the same period and the same initiative is to stop a confident answer assembled from a flattering dashboard over here and an unrelated success story over there. It asks whether the organisation can watch its own operating model change, tell the truth about whether the value arrived, and act on the answer.

This is the dimension that lets the framework close. The Enablement pillar is the human side — whether people can use the capability, in D11, and whether they actually do, here in D12. But D12 reaches further than the pillar. Its feedback wire runs all the way back to D1 and D2, the strategy and value dimensions where the whole thing started, because a portfolio that cannot see its own adoption and cannot measure its own value cannot honestly decide what to fund next. Twelve dimensions of governance, capability, and control mean very little if the organisation never checks whether any of it changed the work.

So the small test I would actually apply is this. Find the most confident adoption dashboard in the building. Ask it one question it was probably not built to answer: which decision did you change. If it can name a use case that adopted beautifully and was paused because the value never came, the instrumentation is real and the loop is closed. If every line bends up and nothing was ever stopped, the dashboard is not measuring adoption. It is measuring relief.