Modernization dependencies: what AI initiatives need
Readiness is not one condition. What an initiative requires is set by how much of the operating decision it takes over, and that map can be read before capital is committed.
Two systems can run the same AI model against the same data and still be different projects.
Drafts a maintenance recommendation for a planner to accept or discard.
- Document access
- A defined scope
- A working sense of what planners currently catch
The planner absorbs the errors.
Writes the work order and moves the schedule.
- Asset identity reconciled across three systems
- Data freshness matched to the pace of the decision
- A rollback path and an audit trail
- A plant manager measured on utilization who now has an opinion about it
The organization absorbs the errors.
Authority is the difference: how much of the operating decision the AI makes, and therefore how much of the business has to be true before it can make it.
Those conditions are modernization dependencies: facts about how the business runs that decide whether a system can be implemented reliably, adopted, and expanded safely. They are specific to an initiative rather than universal. Clearing all of them before starting is not the objective. The objective is to read which ones bind a specific initiative.
Strategic alignment
- 01-AOperational outcome and evidence
- 01-BScope and operational authority
- 01-COwnership and incentives
Operational logic
- 02-AProcess legibility and stability
- 02-BDecision logic and expert attention
- 02-CExceptions, reversibility, change capacity
Information foundation
- 03-AAvailability and dark data
- 03-BShared entities and definitions
- 03-CLineage, provenance, and freshness
Technical foundation
- 04-AIntegration surface and connective architecture
- 04-BIdentity, security, and write-back topology
Governance and evolution
- 05-AProportional governance and adoption
- 05-BEvaluation after deployment
- 05-CReplaceability
Strategic alignment
Operational outcome and evidence
The initiative connects to a business metric: engineering throughput, proposal turnaround, schedule adherence, cost per claim. The baseline is captured before deployment, because afterward there is no clean way to reconstruct what the old process achieved. Skip it and the organization spends the next year arguing about whether the system works, with nothing capable of settling the argument.
Scope and operational authority
Read-only advisory carries low operational risk and simple evaluation. Automated write-back into systems of record requires validation, rollback, and audit. The boundary has to be stated, because advisory tools acquire authority by drift. A recommendation that is always accepted is a decision, and the controls around it were designed for something else.
Ownership and incentives
Executive sponsorship launches an initiative. Operational ownership sustains it. The capability has to survive the incentives of the people who run it. A scheduler that recommends downtime meets resistance from managers evaluated on utilization, and model accuracy does not answer that, because the objection is correct on their scorecard.
Operational logic
Process legibility and stability
AI does not stabilize an inconsistent process. It can expose variation, enforce structured inputs, or guide operators toward a standard path. The meaningful variations and exception routes have to be mapped before authority is delegated into them.
Decision logic and expert attention
Consequential operations run on senior people whose judgment was never written down. Initiatives stall less often on technical failure than on those people having nothing left after daily execution: no time to validate outputs, define edge cases, or adjudicate disagreements. Expert attention is the scarcest input in the program and the only one that cannot be bought at the margin.
Exceptions, reversibility, and change capacity
The design states what happens when confidence is low, when two sources conflict, and when output falls outside expected parameters. Controls are sized to the cost and reversibility of the error, not the ambition of the project. Pace is set by what the organization can absorb without degrading the operations that already run.
Information foundation
Availability and dark data
Much of the operational record never reaches a system of record: local drives, uncaptured paper, email, and legacy platforms whose export paths nobody documented. One clean representative sample pulled out of production proves availability. A software inventory proves nothing. Availability also has a clock on it. A domain that nobody extracts before its host system retires gets far more expensive to recover afterward, which puts platform retirement dates on the sequencing critical path.
Shared entities and definitions
Any workflow that spans systems needs a dependable way to resolve entity conflicts. Where an ERP and an MES disagree about part identity, or two regions issue their own identifiers for the same item, automated workflows corrupt everything downstream. The resolution can be canonical definitions, targeted mappings, confidence thresholds, or human exception review. It cannot be an assumption.
Lineage, provenance, and freshness
Lineage traces the hops between source and output and keeps corrupted context away from the model. Freshness has to match the tempo of the decision. An overnight batch is adequate for a maintenance document assistant and useless for a real-time scheduling call.
Technical foundation
Integration surface and connective architecture
Every hop across ERP, PLM, MES, CRM, and finance adds a vendor access restriction, an API rate limit, or a legacy dependency that breaks in undocumented ways. Physical topology counts too. A plant network deliberately segmented from IT is not a harder integration, it is a different one, and it has to be designed for rather than discovered. A modular connective spine keeps the core systems reachable and the components replaceable.
Identity, security, and write-back topology
Role-based permissions, data residency obligations, and program boundaries apply along the entire path, not only at the interface. As a capability moves from advising to executing, validation loops, transaction limits, idempotency, and audit trails go into the architecture before write authority is granted.
Governance and evolution
Proportional governance and adoption
Governance is matched to operational consequence. Over-governing a lightweight internal assistant suppresses adoption that costs nothing to allow. Under-governing a high-authority system creates exposure that is expensive to unwind. Both errors are common, often in the same organization in the same quarter.
Evaluation after deployment
The baseline captured at the start doubles as the instrument for detecting decay. A capability that was correct at launch drifts as product mix, process, and staffing change. Without continuous measurement, the drift surfaces as a downstream failure, at which point the organization is relitigating trust rather than tuning a system.
Replaceability
Models and vendors change faster than operations do. Whether a component can be swapped without rebuilding the configuration around it is a property of the architecture, decided at build time and expensive to retrofit.
Someone has to define correct
An ERP integration is correct against a specification. The field maps or it does not, and the test is mechanical.
Most operational AI has no specification. Whether an extracted requirement is the right requirement, whether a failure diagnosis is plausible, whether a drafted response is acceptable to send: a person whose judgment the organization already trusts settles each of those. Defining correct is a deliverable in its own right, and it consumes the people with the least time to give.
A conventional IT dependency list bottoms out in engineering capacity. This one bottoms out in the attention of the people who can say what good looks like, and the operation spends that attention first.
The architecture was correct and the number did not exist
CaseA multinational manufacturer migrated to a properly layered data architecture, raw through curated, staged the way the reference material prescribes.
The board had a question about product metrics.
It could not be answered.
The relevant data existed and was accurate. It could not be answered because no product master existed. Each region issued its own identifiers for items that were frequently the same item, and nobody had ever agreed, at the enterprise level, what a product was. A clean pipeline moving undefined entities produces totals that are confident and wrong.
Every element of that diagnosis is legible from the map above, and the executives could recite it from memory. They knew the identifiers conflicted. They knew which regions were worst. They had a fair estimate of what a product master would cost.
What none of that produced was an order of operations.
Dependency logic says fix entity definitions first, because everything downstream inherits the error. Credibility logic says ship something visible first, because a team that spends its first quarter on plumbing loses the room and the budget with it. Definitions have to be centralized to be fixed at all, and permanent centralization recreates the bottleneck the organization was trying to escape. Each of those has a defensible answer in both directions.
The right sequence turned on facts no framework contains: how much credibility the team had left, how much of the definitional work could run in parallel, and who in the business had the standing to declare what a product is and make the declaration stick.
How the weighting shifts by operating environment
Aerospace and defense
Program risk, configuration management, multi-decade lifecycles, and export control load the weight onto lineage, write-back topology, and governance. Advisory tools over historical proposals and technical documents deploy quickly on light integration. Anything that modifies engineering change orders, supplier commitments, or configuration-controlled records requires immutable audit before it executes, and the cost of that audit layer belongs in the first business case rather than the third.
Heavy industrial and manufacturing
The binding constraint is usually freshness paired with entity resolution, and the two interact: a stale record and a mismatched identifier produce the same wrong answer by different routes. Document assistants run comfortably on periodic batch. Anything touching material movement or production schedules needs pipelines at operational tempo and a defined behavior for the moment two systems disagree.
Technical engineering services
Here the rate limit is human. Drafting support needs little senior intervention during a pilot. Automated bidding, structural calculation, and client-facing deliverable generation all require senior engineers to set the standard of correct and clear the exceptions, which is the same capacity the firm sells by the hour. The economics of building that capability run against the economics of the current quarter.
The five limits on modernization pace
A capability can be fully buildable and still rate-limited by the organization around it.
- 01Integration capacityFew people can safely modify a system of record, and that number is fixed over any horizon that matters.
- 02Expert attentionThe people who define correct are the people the operation cannot spare.
- 03Leadership bandwidthExecutives can sponsor and unblock a small number of cross-functional initiatives at once, and the ceiling is lower than most portfolios assume.
- 04Change absorptionSimultaneous deployments degrade adoption across every workflow, including the ones that were working.
- 05Organizational credibilityIt drains during a visible failure and refills only when something works in production. A team starting with a deficit has fewer attempts available than the plan assumes.
Most documented enterprise AI failures reduce to one of these five, not to a defect in the technology.
What the initiative leaves behind
Every deployment consumes capacity. The useful question is what remains when it ends.
Local value
The task is solved, the operating model does not change, the result is self-contained and useful.
Compounding capability
The task is solved and something reusable remains: canonical entity definitions, documented decision logic, a secure integration, a structured knowledge base. The next initiative starts cheaper.
Avoidable complexity
The task is solved and what remains is a brittle integration, an undocumented dependency, and a tool with no owner.
The third outcome rarely follows an obvious mistake. An industrial distributor moving to a new data platform planned to port every object in its existing reporting layer. More than half were redundant, accumulated over years of answering individual requests, overlapping and unowned. Porting them was both the fast path and the defensible one: auditing first would have delayed a program with a hard date. The result would have been the same duplicated semantic layer on better infrastructure, at full price, with the ownership gap intact.
The second outcome usually costs the same as the first. It requires only that someone name it before the build starts. A product master is paid for once, by whichever initiative reaches it first, and it is the precondition for demand forecasting, for anything the call center can act on, for automated replenishment, and for every capability that has to know what an item is.
Point solutions generalize across companies, and often add value to an overall stack. They are inadequate in situations where effectiveness depends on variables specific to one company, such as its parts, its sequence, its tolerances, its definition of correct.
Advantage comes from encoding those variables. The definitions, integrations, controls, and operating rules assembled around commodity models form a configured operating layer, what Talbot West calls the enterprise harness. Built modularly, it keeps the models underneath replaceable while the configured layer remains an asset the enterprise owns.
It runs both directions. A capability nowhere near production authority can still classify legacy documents, reconcile duplicate records, extract structure from engineering drawings, or make institutional knowledge findable. Each of those resolves a dependency using the technology that depends on it.
The importance of sequencing
Dependencies are readable. Most of what is on this map can be established with a sample export, a set of interviews, and a willingness to hear an unwelcome answer. Most organizations already know most of it.
A map does not contain the sequence. Which constraint binds first, what can run in parallel, how much credibility is available to spend, and which unwelcome answer is worth acting on this quarter are decisions made against incomplete information, on a clock, inside an organization with its own politics and its own memory of the last initiative. That is a different discipline from assessment, and it is where the difficulty concentrates.
The organizations that compound read their constraints accurately, choose an order they can defend, and build each capability so the next one starts from a better position than the last.
Assessment and sequencing are different disciplines.
Talbot West reads the dependencies with the operators who own them, then commits to an order and the reasoning behind it.
Download the full report (PDF)
Jacob Andra