The models are getting better at astonishing speed. The companies trying to use them are not changing nearly as fast, and that is where most AI transformations will fail.
One is a process nobody redesigned. The other is an enterprise that cannot agree what its own numbers mean.
Michael Hammer, an MIT computer science professor and the originator of business process reengineering, cited an insurer in 1990 where an application spent 22 days in process while being actively worked on for just 17 minutes. A benchmark called Spider 2.0, meanwhile, measured what happens when a model is asked business questions about a company's own databases. Against the tidy databases used in textbooks, it gets around nine out of ten right. Against real enterprise ones, the same model manages roughly one in five.
Those numbers describe two different problems. The first is what happens when AI is added to a process nobody redesigned. The second appears when the redesigned process asks the enterprise for an answer and discovers that the underlying systems do not agree on what the answer means.
In late 2024, the UK Department for Business and Trade provided another useful data point. It gave 1,000 employees Microsoft 365 Copilot licences for three months and then published what actually happened.
The result is a good snapshot of where enterprise AI stands today. People generally liked Copilot. 72% of respondents said they were satisfied or very satisfied, and the tool produced small time savings across a number of tasks. Yet usage averaged only 1.14 actions per employee per working day and, more importantly, the evaluation found no evidence that the time savings had translated into higher productivity for the organisation.
At first sight, that seems contradictory. If a tool saves time and people like using it, surely the organisation employing those people should become more productive. Much of the excitement around generative AI rests on exactly that assumption: take thousands of knowledge workers, make each of them 10%, 20% or perhaps 30% more productive and watch the gains compound across the enterprise.
Except an enterprise does not work like an Excel spreadsheet in which individual productivity gains can simply be multiplied by the number of employees.
Before LazyFox, our team spent more than fifteen years advising large companies on digital transformation and running transformation programmes inside them. That work ranged across organisations including Audi, Bertelsmann, BNP Paribas, Coca-Cola, Daimler, Deutsche Bank, Deutsche Post, ERGO, Gruner+Jahr, Sanofi and SWISS. We built that business and eventually sold it. Since then, members of the team have spent years building AI systems in regulated and sensitive environments, particularly financial services, where a number that is merely plausible rather than correct can have rather more serious consequences than a disappointing chatbot response.
The technology changes, sometimes dramatically. The organisational reflex changes much less. A new technology arrives, executives recognise its potential, budgets are assigned, vendors are selected, and then the technology gets inserted into the way the company already works.
Vas, CEO of Varick Agents, recently described the AI version of this problem in an essay titled Applied AI Doesn't Work. His argument is that much of today's enterprise AI spend is being poured on top of processes that should have been redesigned first. The result is often a faster version of a process that was not particularly good to begin with.
We think that is right. It also explains only part of what goes wrong.
Once you redesign a process and start allowing AI to do real work inside it, the model eventually has to answer questions that look deceptively simple: What counts as revenue? When is a customer active? Which date determines the performance period? If two systems disagree, which one wins?
This is where a second problem appears. The organisation itself often does not have one consistent answer.
For years that was manageable because people compensated for it. Someone knew which report to trust, which exception mattered, which number Finance used and which field in Salesforce had stopped meaning what its label suggested three years ago.
AI makes that arrangement visible.
AI did not create the need for meaning. It removed our ability to keep ignoring it.
Hammer's complaint from 1990 sounds remarkably current, and the number attached to it still holds.
The argument that technology creates little value when it is merely added to an existing process is not new. In 1990, Hammer published Reengineering Work: Don't Automate, Obliterate in the Harvard Business Review. His complaint at the time sounds remarkably current: companies were spending heavily on information technology without seeing comparable improvements in performance because they were using computers to accelerate processes designed for an earlier era.
One of Hammer's examples remains useful because it puts a number on the problem. An insurer estimated that an application spent around 22 days moving through the organisation, even though the combined amount of time anybody actually spent working on it was only 17 minutes. Everything else was waiting: between departments, in queues, for approvals, reviews and handovers.
Now apply AI to that process.
Suppose the model is excellent and halves the time spent doing the actual work. Instead of 17 minutes, employees need eight and a half. The AI programme can truthfully report a 50% improvement in task efficiency.
The customer still waits almost 22 days.
This is the gap between task productivity and business productivity, and it helps explain the UK government's Copilot results. Saving several minutes while preparing a presentation is useful to the person preparing it. It does not necessarily change the throughput of the organisation around that person. If the output still waits two days for approval, gets copied into another system, is discussed in Thursday's meeting and then sits in an inbox over the weekend, those minutes disappear into the machinery.
Handing out Copilot or ChatGPT licences is also much easier than changing that machinery. Licences have owners and budgets. A process crossing finance, operations, sales and IT often belongs to nobody in quite the same way. Redesigning it means asking why a fourteen-step approval chain exists at all, then dealing with the answer.
This is where AI transformation stops being mainly a technology programme.
The useful starting point is not "Where can we use AI?", but "Where does the time actually go?"
That means understanding the process as it happens rather than as it appears in the slide deck, including the exceptions, workarounds and handoffs that rarely make it into the official documentation. Process mining can reveal part of that reality in system logs. The people doing the work reveal the rest.
Both matter. We have seen transformation programmes spend months mapping a process that everybody formally agrees exists, only to discover later that much of the actual work happens through exceptions the process map never captured. The operator who has handled the case for six years knows that a particular customer always requires another approval, or that the system status cannot be trusted after a certain event, or that someone in Finance has to correct a value manually before month-end. Those details often look like noise from the outside. In production they are the process.
Once the process is understood, the technology choices tend to become less mysterious.
A deterministic rule is usually still better handled by deterministic software. If an invoice is below a defined threshold and matches the purchase order and goods receipt, an ordinary rule will do the job more cheaply, reliably and transparently than a language model.
Agents become interesting where judgment is required, enough context exists to make a sensible decision and the cost of an occasional error is acceptable. Decisions that are too consequential or too novel should remain with a person, while the agent can still collect the evidence and prepare the decision.
The interesting outcome is not a 25-step process with AI attached to every step. It is a process that no longer needs 25 steps.
One ERP, one CRM, one source of truth. A much cleaner architecture diagram, and several years gone.
Once companies realise that a process runs across several systems, another familiar instinct kicks in: before doing any of this properly, surely we need one ERP, one CRM, one data platform and one source of truth.
We understand the appeal. It produces a much cleaner architecture diagram and, on paper, makes an impressive number of problems disappear at once.
It also tends to take years.
McKinsey and the University of Oxford analysed more than 5,400 IT projects and found that large projects ran 45% over budget and delivered 56% less value than predicted on average. 17% performed so badly that they threatened the existence of the company undertaking them.
There are good reasons to consolidate systems in some circumstances. "We need to do it before AI can create value" is increasingly not one of them.
Modern models are remarkably capable of navigating heterogeneous environments. They can call different systems, translate between formats and orchestrate workflows across infrastructure that was never designed to work together.
What they cannot safely do is invent the rules for resolving the disagreements they find there.
If Salesforce considers a company an active customer, SAP does not, and the warehouse contains a third interpretation used by the management dashboard, connecting an agent to all three systems has solved the access problem. It has not answered the business question.
Which definition is correct?
Quite often, the answer cannot be inferred from the data because more than one interpretation is technically plausible. Someone in the business has to decide.
What happens when a model leaves the clean benchmark and meets a schema that has stopped explaining itself.
The scale of this problem becomes visible when language models leave clean benchmark environments and encounter something closer to real enterprise data.
Spider has for years been one of the standard benchmarks for testing whether a model can translate a natural-language question into SQL. On Spider 1.0, o1-preview achieved 91.2%. On the harder BIRD benchmark, it reached 73%.
Spider 2.0 changed the environment. Its 632 problems were derived from enterprise-level database use cases involving systems such as Snowflake and BigQuery. The databases often contain more than a thousand columns, and solving the tasks can require searching metadata, reading documentation, understanding existing code and producing several SQL queries rather than one neat answer.
An o1-preview-based agent framework solved 21.3% of them.
That result should not be overinterpreted. Spider 2.0 is harder for several reasons; missing business meaning is only one of them. But that is precisely why the benchmark matters. The neat environment in which the model looks almost infallible has been replaced by something much closer to what companies actually have.
In a benchmark, you may find a column called cancelled.
In an enterprise database, you might find cncld, containing 6, joined to another table through a field created during a migration seven years ago. The schema can tell the model what type of field it is. It cannot tell it that Finance decided three years ago to count an order towards the current quarter if the cancellation happened after invoicing, while Sales excludes it as soon as the cancellation is received.
The model can inspect the schema. It cannot know what was decided in the meeting.
People have been remarkably good at working around this kind of mess.
An analyst who has worked in the company for eight years knows that the management report excludes intercompany transactions. The finance director knows which of two customer classifications to trust. Someone in operations remembers why one subsidiary calculates performance periods differently.
Nobody calls this "semantic reconciliation". It is simply part of knowing how the company works.
That arrangement survives until the human disappears from the loop.
Then the model encounters two plausible answers without the institutional memory required to distinguish between them. Worse, it often does not produce an obvious failure. It generates a query, retrieves a number and presents an answer that looks entirely reasonable.
A number that looks obviously wrong gets investigated. A wrong number that looks plausible gets used.
This is also why enterprise AI can look so convincing in a demo and become far less dependable in production. The demo usually runs on the part of the data that explains itself. Production eventually reaches the abbreviations, exceptions, conflicting definitions, regional variations and undocumented rules.
The data did not suddenly get worse. The person who used to compensate for it is no longer in the loop.
Process defines what AI is allowed to do. Meaning defines what it is allowed to believe.
Business Objects shipped the first commercially successful semantic layer the same year Hammer published his reengineering argument. What changed since is the consumer.
There is a useful historical symmetry here. Around the same time Hammer was arguing that companies needed to rethink their processes rather than simply computerise them, Business Objects was developing what it called a "Universe": an abstraction between the physical database and the business user that translated technical structures into business concepts. SAP still describes the purpose of a Universe as allowing business users to work with semantically understandable objects regardless of the underlying data structures.
It became one of the early commercially successful forms of what we now call a semantic layer.
The idea never went away. BI platforms, analytics tools and data teams have been implementing versions of it ever since.
What has changed is the consumer.
The original semantic layer helped a human ask a business question without understanding the database. AI requires something broader. A machine acting inside the enterprise needs not only the names of business concepts, but the rules that determine what they mean in context.
What constitutes revenue? Which transaction statuses are excluded? Which date determines the accounting period? Which exchange rate applies? Are two definitions legitimate for different purposes, or is one simply wrong? Which system has authority when they conflict?
Most organisations can answer these questions. The difficulty is that the answers are distributed across queries, dashboards, documentation, code and people.
The obvious response is to document all of it. Build a catalogue. Define the metrics. Describe the schema. Add a business glossary.
All of that helps. It does not solve the underlying problem.
Documentation records what somebody believed the system meant at a particular point in time. The system keeps changing afterwards.
Someone modifies a query. Finance changes the treatment of a transaction. A source system introduces a new field. An acquisition brings in another ERP. Nothing necessarily breaks, so the documentation remains untouched while the operational definition moves on.
The company now has two versions of reality: the documented one and the one its systems actually execute.
For AI, that distinction matters. A model does not simply need more description around the data; it needs to know which definition has authority in the current context.
That is why meaning cannot remain documentation alone.
If the definition of revenue is represented as versioned logic used by the system producing the answer, changing the definition changes the result. If two systems disagree on customer status, there needs to be an explicit rule for which one wins, in which context and for which user.
The meaning is no longer merely described next to the system. It becomes part of the system.
This also explains why the problem is larger than traditional BI semantics. AI is beginning to act on enterprise data rather than merely retrieve it. An agent may approve an exception, update a forecast, initiate a workflow or communicate a figure to a customer. At that point, a company needs to know not only where an answer came from, but why it was valid when the action was taken.
Meaning therefore has to stay current, be governed and remain explainable afterwards.
Gartner now expects universal semantic layers to become critical infrastructure alongside data platforms and cybersecurity by 2030, and describes them as a foundation for scaling AI and AI agents with governance and explainability.
Whether the industry ultimately keeps that terminology is less important than the underlying requirement.
Machines need a way to understand the business rules that people have historically carried around in their heads.
Start with the metrics people already argue about, and force the ambiguities into the open.
This is where discussions about "semantics" can become abstract enough to be almost useless. In practice, the work is much more concrete. Start with the metrics people already argue about and force the ambiguities into the open.
For each one, you need a definition that says what the business means by the term and who owns that definition when it changes. Then come the exclusions, which are often where the real disagreement sits: which statuses, transaction types or states are deliberately left out, and why?
You also need to preserve legitimate variants rather than pretending every company can have exactly one number. Finance may need a contractual quantity while operations needs a delivered quantity, and both can be correct. The job is to make the context explicit and reconcile the two, not average them into a compromise nobody recognises.
Then there is time. Which date assigns an amount to a period: invoice date, posting date, delivery date or performance date? What happens when an amount spans several months? In our experience, a surprising amount of silent disagreement begins here.
The same applies to currency and units: which exchange rate, from which day, and at which stage in the calculation? Then comes the system of record and the tiebreak. If two systems disagree, which one wins in this context? That rule is better decided before the management meeting in which the numbers suddenly fail to match.
Finally, there is scope and access. A number is not universally correct merely because its calculation is correct. Which legal entities, regions, customer groups or tenants belong in the result, and what is the person or agent asking the question actually allowed to see?
You find these rules in two places. Mine the existing queries, because whatever the wiki says, the query is what actually ran. Then talk to the people who use the numbers, because the rest lives in their heads. Either source on its own gives you an incomplete picture.
This is tedious work compared with prompting a model. It is also work that survives the next model release.
A Series A fintech where adding one report took weeks, and writing the query was never the reason.
One of our customers is a Series A fintech whose product is used by finance teams. Reporting is important to its offering, but adding a new report had become a small software-development project involving backend work, frontend work, testing and deployment. Even when everything went smoothly, the cycle took a couple of weeks.
At first sight, this looked like an obvious AI use case. Generate the query automatically and much of the development effort disappears.
Except writing the query was not what took the two weeks. The process around it did.
We connected read-only to the company's existing MongoDB rather than migrating the data elsewhere, indexed the underlying structure and started with five reports the team wanted to build.
The briefs described what those reports should contain. They did not contain all the business rules needed to produce them. When the first results differed from what the team expected, we worked backwards from the queries behind existing reports and then sat down with the people who understood why those queries had been written that way.
That exercise surfaced a question that had never been formally settled: when an amount spans several months, which performance period should it belong to?
The organisation had been answering the question in practice, but not consistently. Different reports had ended up implementing different versions of the rule.
We also found two legacy reports built years apart that returned different values for the same metric because one contained a hard-coded condition that the other did not. Neither developer had necessarily made a mistake. They had implemented the understanding available to them at the time, without a shared definition governing both reports.
Once that logic was pulled out of individual queries and turned into shared definitions, the benefit went beyond AI accuracy. A report that previously took weeks could be created in hours without an engineering release. Reports using the same metric stopped quietly diverging. Customers with multiple legal entities could aggregate them without exporting individual reports and adding the numbers together manually.
What looked initially like an AI and analytics problem was largely an organisational knowledge problem.
The business knew what it meant. Its systems did not.
Data, Meaning and Trust: the three barriers between a promising pilot and something a company will run in production.
This is where we think the traditional idea of a semantic layer starts to become something larger.
A semantic layer was built mainly to help humans query data consistently. An Enterprise Intelligence Layer has to make the meaning of the enterprise available to machines across systems and keep that meaning current as the systems change.
If customer_status in Salesforce, an account state in SAP and a field in a warehouse all describe different aspects of the same business concept, something has to preserve the rules that reconcile them and make those rules available to whichever model, agent or application is asking.
Crucially, doing that should not require moving all of the underlying data into another system first.
This is one of the core layers we are building at LazyFox, but it is not the whole platform.
LazyFox is an Enterprise AI Adoption Platform because meaning is only one of the barriers separating a promising AI pilot from something a company will trust in production. In practice, the problems tend to fall into three areas: Data, Meaning and Trust. AI has to reach the information it needs, interpret that information consistently across systems and produce an answer or action the business can explain and govern afterwards.
Our broader thesis is that enterprises have spent decades paying to work around the absence of governed meaning: copying data into warehouses, rebuilding definitions in BI, documenting them in catalogues and remapping them in integration projects. AI has now been added on top and is inheriting the same inconsistencies. LazyFox is designed to govern what enterprise data means across systems at runtime, while working read-only with the existing stack rather than forcing another migration before value can appear.
The point is not that every company needs another "semantic layer" product. The point is that AI cannot reliably operate across an enterprise unless something performs this function.
Redesign the work, make the meaning explicit, then make the result trustworthy enough to run in production.
Much of the current enterprise AI debate is happening one layer too high.
We spend enormous amounts of time comparing models, agent frameworks and copilots. All of them are moving quickly, and most will look very different two years from now.
The things underneath them change much more slowly.
A company still has to decide how an invoice gets approved, what revenue means, which customer record is authoritative and what happens when a case falls outside the normal process. Those decisions survive model generations. They are also precisely the context AI needs if it is going to move beyond assisting individuals and start operating parts of the enterprise.
That leads to a different sequence for AI transformation.
First, redesign the work. Remove steps that no longer need to exist. Use deterministic software for deterministic decisions, agents where judgment can sensibly be delegated and people where the consequences demand them.
At the same time, make the business meaning underneath the process explicit. Connecting an AI system to every database does not create a source of truth; in many companies it simply gives the model faster access to every disagreement accumulated over the past 20 years.
Then make the result trustworthy enough to use in production: permissions, lineage, versioning, reproducibility and the ability to explain why a system produced a particular answer or took a particular action.
These are not separate problems. A process depends on meaning. An agent can only determine whether an invoice "matches" if the company has decided what a match is. It can only escalate a "high-value customer" if that term has a defined meaning in the relevant context. It can only act on a KPI if the KPI is stable enough that asking the question twice does not produce two defensible but different answers.
Over the last few years, AI has become astonishingly good at understanding our language.
The next challenge is almost the reverse: making the enterprise understandable to AI.
Until that happens, companies will continue to run impressive pilots, employees will continue to save time and boards will continue to wonder why the promised transformation remains surprisingly difficult to find.
Enterprise AI does work. Just not on an enterprise that was never redesigned for it.
Process defines what AI is allowed to do. Meaning defines what it is allowed to believe. Trust determines whether the enterprise will let it do either.
Before you start the next enterprise AI project, these are the questions we would ask first.
If those questions do not yet have convincing answers, the model is probably not the bottleneck.
Enterprise AI fails on two different problems. The first is what happens when AI is added to a process nobody redesigned: Michael Hammer cited an insurer whose application spent 22 days in process while being actively worked on for 17 minutes, and a UK government trial of Microsoft 365 Copilot across 1,000 staff found 1.14 actions per person per working day, 72% satisfaction and no evidence the time savings reached organisational productivity.
The second appears when the redesigned process asks the enterprise for an answer and the underlying systems disagree about what the answer means. An o1-preview-based agent framework solves 91.2% on Spider 1.0 and 21.3% on Spider 2.0, which is built from real enterprise database workloads. The post covers why consolidating systems first is not a prerequisite, what has to be defined per metric (definition, exclusions, legitimate variants, time, currency and units, system of record and tiebreak, scope and access), why a data catalogue is not enough and meaning has to become executable, and how Data, Meaning and Trust form an Enterprise Intelligence Layer.
LazyFox holds your business definitions as versioned logic your company owns, and serves them to whichever model or agent is asking. It connects read-only. Nothing migrates.