AI Will Not Fix a Broken Operating Engine

AI pilots fail on processes that were never stabilized and data that was never governed. Technology amplifies the operating engine it is given, in both directions.

Boards everywhere are asking the same question: what is our AI strategy? Budgets are moving, pilots are multiplying, and vendors are promising that this time, the technology will leapfrog the tedious work of fixing processes and data.

It is worth saying plainly: it will not. Not because the technology is weak, it is remarkable, but because of what AI actually does. It learns from an organization’s data and accelerates its workflows. Feed it fragmented data and broken processes, and it will faithfully accelerate the fragmentation. Feed it dirty data, and it will make confident, wrong decisions.

This is not a new lesson. It is the ERP lesson, and before that the digital and automation lessons, arriving again at higher speed. Every generation of enterprise technology has rewarded the companies that fixed their operating engine first and punished the ones that hoped the system would do it for them. Three decades of implementations, from GE’s process disciplines to today’s migrations, keep teaching the same sequence: stabilize, standardize, then digitize what processes and data are clean.

The Pattern: AI Pilots Everywhere, Production Nowhere

The current corporate AI landscape has a recognizable shape. A company runs ten, twenty, thirty pilots: a chatbot for customer service, a copilot for the finance team, a forecasting model for supply chain, a document reader for contracts. The demos impress. Then almost none of it reaches production at scale, and the few that do show fuzzy returns. AI is everywhere, yet nowhere.

The post-mortems rarely blame the models. They find the same operational culprits every time.

The data was not ready. Customer master data duplicated across systems. Product hierarchies that differ by region. Transactions coded inconsistently. No agreed definitions for basic terms like margin, active customer, or on-time delivery. AI does not resolve these conflicts, it inherits them, and at scale it industrializes them.

The process underneath was unstable. Automating a process requires the process to exist: one way of doing the work, not five local variants held together by experienced people. Companies discover during AI deployment what they should have discovered during process mapping: there is no standard to automate.

Nobody owned the outcome. Pilots run by innovation teams or IT produce technology successes and business orphans. If no operating leader owns the workflow being changed, carries the performance target, and forces the adoption, the pilot ends when the funding does. This is often the root cause behind the other three: an accountable owner would have forced process standardization and data governance before the pilot started.

The workflow was never redesigned. Dropping AI into an unchanged workflow produces a faster version of the old work, plus a new tool to check. The gains come when the workflow itself is rebuilt around what the technology makes possible: fewer handoffs, decisions moved earlier, exceptions routed differently. That is operating model design, and no model does it for you.

The ERP Parallel Nobody Should Ignore

Enterprise resource planning systems have been implemented for thirty years, and the success factors have been known since the beginning. I saw it firsthand on my first ERP implementation, migrating twelve countries running three different systems onto a single Oracle ERP, and moving data that had previously been managed internally out to external data providers.

Master data management and process harmonization were not a workstream on that project, they were the project. Standardize processes and eliminate complexity pre-migration, clean and govern the master data, run change management with discipline, run a pilot and track adoption as seriously as go-live. Implementations that respected that sequence created lasting control and scalability. Implementations that treated the ERP as an IT project bought themselves years of workarounds, shadow spreadsheets, and expensive re-implementations. The failure mode was always the same: the system went live, the organization did not change underneath it, and the gap between the two became permanent.

AI raises the stakes of this old lesson, and the reason is visibility, not volume. A misconfigured ERP posts an obvious error: a failed transaction, a rejected entry, a balance that will not close, something a controller catches the same day because the system itself refuses to proceed. A model trained on inconsistent data does the opposite. It produces confident, plausible, wrong answers, a forecast, a classification, a churn score, a recommended reorder quantity, and nothing in the output signals that anything is wrong. The number looks exactly like a correct one. It flows straight into a decision, and the error is discovered only when the consequence shows up downstream: the wrong inventory position, the customer flagged as low-risk who was not, the invoice routed to collections that should have been written off. Weak data governance under ERP produced reconciliation work, a known, bounded cost that finance teams have managed for decades. Under AI it produces misplaced confidence, which is unbounded and, until it fails visibly, invisible.

So the uncomfortable but liberating conclusion: the boring foundations are not a delay to the AI agenda. They are the AI agenda, or at least its first phase.

What “Ready” Actually Requires

None of this argues for waiting. It argues for sequencing, and the foundations are more targeted than the phrase “fix your data” suggests. Readiness is not company-wide perfection. It is readiness along the specific workflows where the value is.

Pick the use cases from the value, not from the technology. Start where the operating drivers already say the money is: forecast accuracy in a business drowning in inventory, collections prioritization where receivables are aging, quality inspection where rework is eating margin, document processing where a back office is scaling headcount linearly with volume. A use case tied to a driver has an owner, a baseline, and a measurable result. A use case tied to a technology has a demo.

Stabilize the process in the path of the use case. One standard workflow, exceptions defined, ownership clear. Often this step alone captures a third of the value before any model is deployed, which is a clue about where the value was really sitting.

Govern the data that the use case touches. Common definitions, a named owner for each critical data domain, quality measured and reported. Not a corporate data program that tries to fix everything for two years, a focused effort on the datasets the prioritized workflows actually consume.

Make an operating leader accountable for the result. Not for the pilot, for the performance improvement: the inventory reduction, the DSO improvement, the productivity gain. Technology teams enable; the line owns. Adoption, training, and the redesign of roles belong to the same owner, because a tool nobody uses has no ROI, however good the model.

Industrialize deliberately. Move from pilot to production the way a factory qualifies a new line: defined performance thresholds, monitoring, a clear owner for the model’s ongoing behavior, and the discipline to switch off what does not perform. AI at scale is an operations capability, not a procurement event.

What the Board Should Actually Ask

Board oversight of AI tends to oscillate between two unhelpful modes: fascination with the technology, or delegation to a committee. A board that wants real assurance can get it with a handful of operating questions, none of which require technical depth.

Which business outcomes, in EBITDA, cash, or service terms, is the AI portfolio accountable for this year, and who owns each one by name? If the answer lists pilots rather than outcomes, the portfolio is a collection of demos.

What share of AI spend goes to foundations, process standardization, data governance, integration, versus models and licenses? A portfolio that is all models and no foundations is borrowing from its own future.

Which pilots were killed last quarter? A healthy portfolio kills things. If nothing has ever been stopped, either the selection is perfect, unlikely, or nobody is measuring against a threshold.

Where does AI output flow into decisions without a human owner, and who is accountable when it is wrong? This is the governance question that matters, and it is an ownership question, not an ethics abstraction. Every automated decision path needs a named owner, exactly as every process does.

What would it cost us to switch models or vendors in two years? The technology layer is moving too fast for ten-year loyalty. Architecture that keeps the data and process layer independent of any single model vendor is cheap now and expensive to retrofit.

Boards that ask these questions change the behavior underneath them, because they make the operating conditions of AI success, ownership, foundations, discipline, the thing that gets reported, rather than the demo.

The Real Competitive Position

Here is the reframe that matters for boards. The companies that will compound value from AI over the next decade are not the ones with the most pilots today. They are the ones whose operating engine, stable processes, governed data, clear ownership, disciplined cadence, lets them absorb each new wave of technology faster and cheaper than their competitors. The engine is the durable advantage. The models will keep changing; the ability to deploy them is what compounds.

That has a practical implication for how the money gets spent. For most companies, the highest-return AI investment available right now is not another pilot. It is the process and data foundation that every future pilot, and every future system, will run on. Fix the engine, and each new technology multiplies it. Skip the engine, and each new technology multiplies the noise.

Digital, ERP, data, and AI create value under one condition: that they serve better decisions, stronger controls, and faster execution. That condition is built in the operating model, not in the model. The companies that understand the difference will own the next decade of performance.