From 22 Binders to a Box on the Workbench

Blueprint illustration of a distributed AI architecture, highlighting challenges such as slow distribution and high space usage, and benefits including localized inference and enhanced security.

How AI is following the same arc as every technology before it — and why that’s the most important thing happening in enterprise AI right now.


The 22 Binders Problem

In the 1990s I worked for Volvo Trucks, responsible for technical documentation. Every authorised dealership workshop had 22 steel binders crammed with service manuals, torque specifications, fault code references, and replacement procedures. Covering every model, every variant, every engine configuration.

Getting those binders to the right workshop, in the right language, at the right time was a logistical nightmare. Print runs. Translation cycles. Physical distribution across multiple countries. And the moment a binder left the building, you started losing control of it.

Because trucks don’t stand still. Specifications change. Procedures get revised. Safety-critical updates happen. So we’d issue interim service bulletins — printed updates mailed out to dealerships, hoping they’d find their way into the right binder, in the right place, before a technician needed them.

The knowledge was good. The people who wrote those manuals understood those trucks deeply. The content was authoritative, structured, procedural. But the distribution model was broken by design. The moment you printed something, the clock started on it becoming out of date.

I spent years managing that problem. I never solved it. The technology didn’t exist to solve it.

It does now.


The Sledgehammer Era

When generative AI arrived at scale it came in like a sledgehammer. Vast data centres. Enormous compute. Hundreds of billions of parameters. Everything centralised, everything cloud-dependent, everything expensive.

That was necessary. You needed that scale to prove the capability existed. GPT-4, Gemini, Claude — these required hyperscale infrastructure to demonstrate what large language models could actually do. The sledgehammer era wasn’t wrong. It was the only way to get here.

But it’s not the end state.

There’s a pattern in technology that repeats so reliably it’s almost boring once you’ve seen it enough times. A new capability emerges at scale, centralised, specialist, expensive. Then the algorithms get smarter. The hardware gets smaller. The economics shift. And compute escapes the specialist environment and goes where the work actually happens.

We’ve seen this cycle before. Several times.


The Transistor Moment

In the 1940s the valve computer proved the concept. ENIAC, Colossus — genuinely capable machines doing real computation. Enormous, power hungry, heat generating, fragile, requiring specialist environments and specialist people just to keep running.

Then the transistor arrived. It didn’t just miniaturise the valve. It changed what was possible. Compute escaped the air-conditioned room. It went into consumer products, industrial equipment, vehicles. Eventually into the Volvo workshop — diagnostic computers, engine management systems, electronic service tools.

Nobody staring at a room full of valves in 1955 predicted the smartphone. But it was inevitable once the transistor existed. The use cases emerged from the distribution.

We are at that moment with AI.

The evidence is already here. Models like Mistral 7B, Microsoft’s Phi-3, and Meta’s Llama 3.1 8B perform remarkably well on focused tasks. Quantisation techniques mean a model that needed 80GB of GPU memory two years ago runs comfortably in 8GB today with minimal quality loss. NVIDIA has put one petaflop of AI compute into a desktop machine — the GB10 Grace Blackwell — that sits on a workbench. Apple put a capable language model in a phone.

The sledgehammer is giving way to the scalpel. Smarter algorithms. Smaller models. Distributed inference. The transistor moment.


The Architecture That Changes Everything

So let me describe what I’d build for Volvo Trucks today.

A GB10 desktop in every dealership workshop. On it: a small language model, a local MCP server, and a local cache of the workshop knowledge base. No internet connection required. No cloud dependency. No data leaving the building.

The knowledge base lives centrally — one authoritative source, maintained by a team of technical authors with a proper authoring and approval workflow. Single version of the truth. When a torque specification changes, it changes once, in one place, approved by the right person. Overnight, a delta sync pushes only the changed content to every workshop box in every country. By morning every technician in Europe has the current procedure.

The technician doesn’t type freeform queries. They select from predefined prompt templates — fault code lookup, torque specification, replacement procedure, service interval. Each template fires a carefully engineered retrieval query behind the scenes, pulling the right content from the local knowledge base, passing it to the local model, generating a precise, grounded answer.

The model never wanders off domain. There’s no internet to reach out to. No risk of the model hallucinating — confabulating a procedure it half-remembers from training. The answer comes from the authoritative knowledge base, retrieved precisely, generated locally, watermarked with the sync timestamp so you know exactly which version of the truth informed it.

This isn’t a chatbot. It’s a precision workshop tool that happens to use an AI model internally. The AI is an implementation detail. The value proposition is the right answer, instantly, for a truck that needs to move.

And crucially — this couldn’t be done with a naive RAG implementation bolted onto an ungoverned file store. The intelligence isn’t in the retrieval mechanism. It’s in the governance that happened before retrieval was ever involved. The single version of truth. The approval workflow. The deprecation process that ensures superseded procedures stop being retrieved. The content discipline that technical authors like my 1990s self spent years trying to maintain manually.

The AI amplifies good knowledge management. It doesn’t replace it.


The Pendulum

I’ve watched enough technology cycles to see the pattern clearly.

The PC era distributed compute out of the data centre and into the hands of individuals. The internet centralised it again — everything running on servers you didn’t own. Mobile distributed it once more, putting capable compute in every pocket. Cloud AI is centralising again — everything phoning home to a hyperscale data centre to answer a query.

Each time, the dominant narrative says this is how it will always be now. Each time, the pendulum swings back. Not because the technology fails, but because the same forces reassert themselves: latency becomes unacceptable, data sovereignty pressure builds, cost economics shift, and capability catches up to the point where distribution becomes viable again.

We are at peak centralisation with AI right now. The distribution forces are already building. Sovereignty regulation is tightening globally. Edge hardware is catching up fast. Algorithmic efficiency is compressing capable models into deployable sizes. Enterprises are growing uncomfortable with sensitive data leaving their premises to answer a query.

The pendulum will swing. It always does.


The Control Plane

But there’s something different this time that could break the historical pattern — and it’s the idea I find most interesting in enterprise AI right now.

Every previous distribution wave eventually lost coherence. The PC era fragmented into version chaos, security nightmares, and unmanageable sprawl. Mobile created a device estate that IT departments are still trying to govern. Distribution without discipline becomes a different kind of problem — one that often ends up being worse than the centralisation it replaced.

The question is whether AI distribution can be done differently. Whether you can have local inference without local chaos.

I think you can. The architecture looks like this: local inference running in your server room, your data never leaving your premises, your domain knowledge locked in a governed local knowledge base. But the model’s values, safety alignment, and capability updates maintained centrally by the people who built it. The enterprise controls the execution environment. The model provider maintains the model itself.

Distribution without fragmentation. Sovereignty without chaos.

It’s the Volvo KB architecture applied to the model itself. Central truth. Distributed execution. The same principle that would have solved my 22-binder problem in 1993 — one authoritative source, pushed to the edge, with discipline about what changes and who approves it.

This isn’t a theoretical position. The infrastructure to do it exists today. What’s missing, in most organisations, is the governance thinking that makes it safe. And governance thinking, it turns out, is not a technology problem. It’s a knowledge management problem. Which is a very old problem indeed.


What This Means

The use cases for distributed, domain-locked AI are not going to come from hyperscale thinking. They’re going to emerge from people who understand specific domains deeply — who know where the knowledge lives, what governance it needs, and what questions actually matter in that environment.

The Volvo workshop is one example. But the same architecture applies anywhere that has a bounded domain, authoritative knowledge, and real decisions being made by people who need the right answer quickly.

Consider a hospital ward. A clinician needs the current drug interaction protocol for a specific combination — not a general answer from a model trained on the internet, but the approved formulary for this trust, this version, signed off by the chief pharmacist last Tuesday. The architecture is identical to the workshop: local inference, governed knowledge base, delta sync, no data leaving the building. The AI is an implementation detail. The value is the right answer, for this patient, right now.

Or a field engineer on an offshore platform, no reliable connectivity, needing the current maintenance procedure for a specific valve configuration. Or a legal team needing to retrieve the approved contract clause library — not a hallucinated approximation, but the version that compliance signed off.

In each case the AI isn’t the interesting part. The interesting part is the governed knowledge layer underneath it — built by people who understand the domain, maintained with discipline, versioned and approved and auditable.

The sledgehammer era gave us the capability. The transistor moment gives us the distribution. What makes it useful is the same thing that always made the difference — knowing your domain, respecting your data, and being honest about what the technology actually does.

I learned that managing 22 steel binders for Volvo Trucks in the 1990s.

Some lessons don’t change.

Do AI Projects Fail — Or Do We Fail AI?

Blueprint illustration featuring a bird labeled 'DIStraction VECTOR,' and a tower structure with three layered sections labeled 'PROCESS ALIGNMENT,' 'SKILLS & PEOPLE,' and 'DATA FOUNDATIONS.'

If you look back over the last 30 years, our technology history is riddled with failed projects, projects that never got off the ground, and projects that went massively over budget. And then there are the scandals.

The UK Post Office Horizon scandal stands as one of the most serious technology failures in modern British history. Between 1999 and 2015, around 1,000 sub-postmasters were wrongfully prosecuted after the Fujitsu-supplied Horizon accounting software recorded losses that did not exist. The total cost of redress now stands at around £2 billion. More than 13 people took their own lives. The technology did not just fail — it was trusted when it should have been questioned, and the consequences were devastating.

AI is just another technology. That is worth saying plainly. Although many of the possibilities being talked about are genuinely achievable, reality always kicks in. Every project — AI or otherwise — is a complicated combination of people, software, hardware, and process. That has been true for 30 years. It remains true now.

But we can always learn from the past. The question is whether we choose to.

AI is no different. And right now, the data on AI project failure should give everyone pause. The numbers are in. And they are not improving.

RAND Corporation, in one of the most rigorous independent analyses of AI project failure to date, interviewed 65 experienced data scientists and engineers across industries and company sizes. Their finding: more than 80% of AI projects fail to reach meaningful production deployment. That is twice the failure rate of IT projects without an AI component.

S&P Global’s 2025 survey of over 1,000 organisations across North America and Europe found that 42% of companies abandoned most of their AI initiatives that year. In 2024, that figure was 17%. The abandonment rate more than doubled in a single year. MIT’s Project NANDA, published in July 2025, found that 95% of organisations deploying generative AI saw zero measurable return. Not low return. Zero.

With global AI spending projected to reach $630 billion by 2028, these failure rates are not a statistic. They represent hundreds of billions of dollars in wasted investment, stalled initiatives, and businesses no closer to the outcomes they were promised.

What makes this harder to ignore is that the failure rate is moving in the wrong direction. The technology is more capable than it has ever been. The investment is larger than it has ever been. And yet more organisations are abandoning AI initiatives today than they were twelve months ago.

So what is actually going wrong?


The Research Points to Three Things

Across RAND, McKinsey, Gartner, MIT, and Informatica’s CDO Insights survey, the diagnosis is remarkably consistent. AI projects fail for three reasons, and they repeat themselves across industries, geographies, and organisation sizes.

The wrong use case. The process targeted for AI is not the right one, the problem definition is vague, or the initiative is chasing a technology rather than solving a business problem.

Data that is not ready. The data that would be needed to make AI work in production does not exist in the form required — it is fragmented, inconsistent, ungoverned, or simply not there.

A skills gap. The people needed to build, deploy, and sustain AI in a business context are not in place — and the organisation has not yet found a way to close that gap.

None of these are surprises. But the uncomfortable truth is that most organisations are still walking into all three of them, often simultaneously.


The Wrong Use Case: The Magpie Effect at Work

The first failure mode — choosing the wrong process to target — is something I have written about in depth. The Magpie Effect describes what happens when AI strategy is driven by possibility rather than process: the endless pivot towards the latest model, the newest capability, the most impressive vendor demo. Every pivot consumes time, burns budget, and erodes the momentum that comes from doing one thing properly and scaling it.

The RAND report is direct on this point. Stakeholders often misunderstand or miscommunicate what problem needs to be solved. Models get built and deployed optimised for the wrong metrics, or ones that simply do not fit into the real business workflow.

The antidote is starting with the Golden Process — the one business process that everything else hinges on — and asking what AI can do to remove the constraints within it. That conversation has to happen before any vendor is in the room, before any use case is evaluated, and certainly before any infrastructure is selected.

If you have not read the Magpie Effect post, the practical AI test at the end of it is a useful filter for any use case that lands on your desk.


Data That Is Not Ready: The Silent Failure

The second failure mode is the one that catches organisations by surprise — because it tends not to surface until a project is already in trouble.

The pattern is familiar. A proof of concept is built on a carefully selected, cleaned-up sample dataset. The demo runs well. Leadership approves production. And then everything stalls.

Production data is fragmented across systems that were never designed to talk to each other. Basic business terms — “customer”, “order”, “revenue” — are defined differently across departments. Historical records have gaps. Formatting is inconsistent. The clean sample that powered the demo bears almost no resemblance to the messy reality of how the business actually runs.

Informatica’s 2025 CDO Insights survey found that data quality and readiness was the top obstacle to AI success, cited by 43% of organisations. McKinsey found that organisations reporting significant AI returns are twice as likely to have invested in data infrastructure before selecting modelling techniques. Gartner predicts that 60% of AI projects lacking AI-ready data will be abandoned entirely.

This is not a new problem. It is the same problem that has existed since organisations first tried to build anything useful on top of their data. The difference is that AI amplifies it. A flawed report can be corrected. A model trained on broken foundations will confidently produce broken outputs at scale — and the damage compounds before anyone notices.

I have covered the data readiness problem in detail in Garbage In, Expensive Garbage Out and A Million Rows of Nothing. The short version: AI does not fix bad data. It scales it.


The Skills Gap: The Barrier Nobody Budgets For

The third failure mode is the one that receives the least attention — and may be the hardest to solve quickly.

The last 30 years of enterprise IT have built deep, hard-won expertise in infrastructure. Server architecture. Storage design. Networking and virtualisation. Security and compliance. That expertise is not obsolete — it remains essential. The physical and virtual foundations that AI runs on still need people who understand them properly.

But AI demands a different and additional skill set that most organisations are still building.

Traditional IT Skills (Still Relevant)New Skills Now Required
Server architecture and managementData engineering
Storage design and optimisationAI/ML engineering
Networking and virtualisationData science
Security and complianceBusiness domain knowledge

McKinsey’s 2024 State of AI survey found that 58% of businesses are hampered by internal AI skill shortages. Informatica’s CDO Insights survey placed skills and data literacy third in the list of top AI obstacles. PwC found that almost 65% of executives acknowledge their AI initiatives are not succeeding because of a lack of executive sponsorship — a leadership gap that is itself a symptom of not having people in the room who can translate between business outcomes and AI capability.

The skills gap is not a technology problem. It is a people and partnership problem. And it is the reason most AI pilots never leave the room they were born in.

Picture a typical scenario. An organisation identifies a strong AI use case, aligned to a real business process. The data is in reasonable shape. Leadership is supportive. A vendor is engaged. And then the questions start: who is going to build the data pipeline? Who owns the model in production? Who bridges the gap between what the model does and what the business actually needs it to do? The room goes quiet. Not because the will isn’t there — but because the people aren’t.

The honest message is that organisations do not need to replace their existing IT teams — they need to extend them. The people who understand the infrastructure are still essential. But they need colleagues who understand data pipelines, model behaviour, and the business processes those models need to serve. That combination is rare. It takes time to build. And in its absence, even the right use case with clean data will stall.

This is why Partner selection matters as much as use case selection. The right Partner does not just bring technical capability — they bring the scars of what does not work. An AI and data practice built over years has already made the mistakes most organisations have not made yet. That is not a credential. That is insurance.

AI is not a product, it’s an eco-system built on partnership


Three Causes. One Pattern.

What the research is describing — even when it does not use these words — is organisations that jumped to the model before they had solved the three problems that sit upstream of it.

They chased the possibility rather than the process. They skipped the data foundations. And they underestimated how different the skills requirement would be.

McKinsey’s summary of what separates the 6% of genuine AI high performers from everyone else is as sharp as it gets: AI is 20% algorithms, 80% organisational rewiring.

The organisations building durable AI capability are not necessarily the ones with the most sophisticated models. They are the ones that got the process right, made the data ready, and put the right people in place — before they wrote a single line of model code.

The failure statistics look alarming until you understand the causes. Then they look entirely predictable.

The good news: all three are solvable. None of them require waiting for the next frontier model. They just require doing the less glamorous work first.

I have written about what that looks like in practice. Getting AI Right First Time sets out a five-step path from honest awareness through to durable, enterprise-wide capability — the journey from AI as a science project to AI as part of how the business actually runs. And In Praise of Boring, Everyday AI makes the case for what success actually looks like in production: not the demo, not the headline, but the quiet system that runs on a Tuesday afternoon without anyone noticing — because it has simply become part of how the business works.

That is the goal. Not AI that impresses. AI that endures.


AI success has to be built on the right foundations — not retrofitted onto broken ones.

The Magpie Effect: AI Possibilities vs Practical AI Solutions

An infographic titled 'The Magpie Effect' illustrating a magpie flying alongside various concepts related to AI strategies, constraints, and distractions. Includes labeled arrows pointing to elements like 'Distraction Vector', 'Shiny Object Response', and 'Golden Process - Critical Path'. Features a flowchart at the bottom indicating practical AI strategy.

Yesterday, I was sitting in a room listening to colleagues talk about the latest AI developments. New models. New capabilities. New promises about what AI will be able to do. It was energetic, enthusiastic, and genuinely well-informed.

And somewhere in the middle of it, a quiet thought surfaced: does any of this actually matter right here and right now?

It took me back to a book I read years ago when studying Business and Finance. The Goal by Eliyahu Goldratt. If you haven’t read it, it’s a business novel — a plant manager called Alex Rogo, a factory on the verge of closure, and a series of deceptively simple questions from an old professor that eventually save the business. The central insight is the Theory of Constraints: every system has a bottleneck. Find it, fix it, and the whole system improves. Ignore it, and no amount of optimisation elsewhere will save you.

It took me back to a book I read years ago when studying Business and Finance. The Goal by Eliyahu Goldratt. If you haven’t read it, it’s a business novel — a plant manager called Alex Rogo, a factory on the verge of closure, and a series of deceptively simple questions from an old professor that eventually save the business. The central insight is the Theory of Constraints: every system has a bottleneck. Find it, fix it, and the whole system improves. Ignore it, and no amount of optimisation elsewhere will save you.

Sitting in that room, I realised the AI industry has a Goldratt problem. It is endlessly fascinated by what is possible at the frontier, and not nearly interested enough in the bottlenecks that are quietly strangling real businesses today.

That is when the idea of the Magpie Effect crystallised for me.

There is a bird famously distracted by shiny things. It spots something glittering, drops whatever it was doing, and goes to investigate. Every few weeks, a new AI headline lands. A new model. A new capability. A new promise that this is the breakthrough that changes everything. Autonomous agents. Artificial General Intelligence. AI that writes code, runs your supply chain, manages your workforce. The glittering object rotates. The industry pivots. And somewhere in a conference room, a leadership team starts asking whether they should be doing that instead.

The Magpie Effect is quietly one of the biggest obstacles to real AI progress in business today. And Goldratt, I think, would have had little patience for it.

Goldratt was writing about factory floors. Machines, production lines, throughput, inventory. But swap the factory for a financial services firm, a retailer, or a healthcare provider, and the principle holds perfectly. The production lines just look different now. They are the workflows, the approval chains, the data pipelines, the customer journeys that run your business every single day. Constraints in those processes cost just as much as a jammed machine on a shop floor. They are just harder to see.


The Cost of the Chase

Chasing possibilities isn’t free. It has a price, and businesses are paying it in three currencies.

Time. Every pivot towards the next shiny object means restarting conversations, rewriting roadmaps, and pulling teams off work that was already delivering. The opportunity cost is real even when it’s invisible.

Money. Proof of concepts that never graduate. Vendor relationships built on promises. Platforms bought for futures that haven’t arrived. Science projects with no measurable return dressed up as innovation investment.

Momentum. Perhaps most damaging of all. Teams that are perpetually chasing the new never build the deep competency that comes from doing one thing properly, learning from it, and scaling it. They become generalists in hype rather than specialists in value.

The AI industry is not entirely to blame. Vendors need differentiation. Analysts need narratives. Media needs clicks. But the businesses that get swept up in it are making a choice — and there is a different choice available.


Practical AI Is Already Here. It’s Just Less Exciting.

Here is the uncomfortable truth: the AI that will genuinely move the needle for most organisations is not frontier. It is not exotic. And it is definitely not on the cover of a technology magazine.

It is the model that reduces manual data entry by 70%. The system that flags anomalies in financial transactions before a human would spot them. The tool that summarises a week of customer feedback into ten actionable themes in minutes. The scheduler that optimises field service routes and saves 15% on fuel costs.

None of those are science fiction. All of them are in production somewhere today. All of them have a measurable ROI. And none of them required waiting for the next frontier model to drop.

Practical AI solves a real business problem with available technology, accessible data, and a return you can put on a spreadsheet. That is not a consolation prize. That is the goal.


Start With Your Golden Process

Before you evaluate a single AI use case, ask one question: what is the one business process that, if it stopped tomorrow, the business would stop with it?

Not the most complex process. Not the most talked-about. The one that everything else depends on. The process that runs quietly in the background, holding the whole operation together. That is your Golden Process.

It might be order management. It might be claims processing. It might be production scheduling, customer onboarding, or logistics coordination. Every business has one. Most businesses have never explicitly named it.

Name it. Then look at it seriously.

Where does it slow down? Where does it depend on human heroics to keep running? Where does data get re-entered, reformatted, or chased across systems? Where do errors creep in? Those friction points are not just operational annoyances — they are your AI use case shortlist.

This is the starting point of a genuinely business-aligned AI strategy. Not a vendor briefing. Not a technology roadmap. Not a list of capabilities from the latest model release. The Golden Process and the friction within it.

The achievable business outcome — faster, cheaper, more reliable execution of the thing the business depends on most — is worth more than any amount of AI possibility. And it is almost always more achievable than it looks, because the process is already understood, the data already exists, and the ROI is not hypothetical.

Start there. Everything else follows.


How to Tell the Difference: The Practical AI Test

When an AI use case lands on your desk — from a vendor, from a consultant, from an enthusiastic team member who just watched a keynote — run it through these five questions.

1. What specific business problem does this solve? If the answer starts with “it could potentially…” or “imagine if we…” that is a possibility, not a solution. A practical use case has a named problem with a named owner.

2. Do we have the data to support it? AI without good data is not AI. It is noise with a marketing budget. Before you evaluate any use case, ask whether the relevant data exists, whether it is clean, and whether it is accessible. If the answer to any of those is no, the use case is not ready — regardless of how impressive the demo looked.

3. Do we have the skilled resources to support it? Good intentions and good data are not enough. Someone has to build it, maintain it, and own it when something goes wrong. That might be internal talent, a partner, or a combination — but the answer needs to be honest. An AI use case with no clear resource plan is not a use case. It is a wish list item.

4. Can we measure success? Define the KPI before you build anything. Handling time. Error rate. Cost per transaction. Customer satisfaction score. If you cannot articulate what winning looks like in a number, you are not running a business initiative. You are running an experiment with an open-ended budget.

5. Can this be in production within 90 days? Not perfect. Not scaled. But in the hands of real users, generating real outputs, against real data. If the answer is no, the scope is wrong or the foundations are not ready. Either problem needs solving before you proceed.

6. Would this still matter if nobody wrote about it? Strip away the hype. Imagine the use case is completely unglamorous — no AI branding, no press release, just a quiet improvement to a business process. Does it still make the list? If yes, it is probably worth doing. If the answer depends on how it sounds in a strategy presentation, be careful.


Make AI Boring. That Is the Win.

The organisations that are getting the most from AI right now are not the ones chasing the frontier. They are the ones that picked three or four use cases, proved the value, scaled what worked, and moved on to the next problem on the list. Quietly. Methodically. Without waiting for permission from the hype cycle.

They have made AI boring. And boring, in this context, is the highest compliment.

Boring means repeatable. Boring means trusted. Boring means it runs on a Tuesday afternoon without anyone noticing, because it has just become part of how the business works.

The magpies are still circling. The glittering objects will keep appearing. The organisations building durable capability are the ones that have learned to look away — and get back to the work that actually pays.


One Final Thought on Foundations

None of this works without getting data right. Practical AI is only as good as the data that feeds it. The organisations that move fastest are not necessarily the ones with the most advanced models — they are the ones whose data is clean, governed, and ready to use.

That is a less exciting conversation than whatever was announced at the last major AI conference. But it is the conversation that separates progress from theatre.

Data first. Practical use cases second. Everything else can wait.

At the end of The Goal, Alex Rogo doesn’t walk away with a new machine or a bigger budget. He walks away with a better question. Not “how do I optimise everything?” but “what is the goal — and what is stopping us from reaching it?” That shift in thinking is what saved the factory. It is the same shift that separates businesses building real AI capability from those still circling the next shiny object. Find your Golden Process. Name the constraints within it. Ask the right questions about where AI can remove them. The rest follows.


If you found this useful, the Getting AI Right First Time post covers the five steps to moving from AI experiments to durable enterprise capability.