Identifying the Right First Process for AI Rebuilding

Most enterprise AI efforts in asset-heavy industries fail for one structural reason: the process chosen for AI deployment was wrong, or it was never redesigned at all, not because the underlying models are flawed. A Fortune 500 retailer invested heavily in a computer vision system that worked flawlessly in the lab and generated thousands of data points per day once it reached production. It was shelved after 14 months. The reason wasn't the technology. No process existed to act on what the system produced, so the output accumulated with nobody positioned to use it. That retail case is the sharpest available illustration of a pattern recurring across construction, logistics, and manufacturing: an MIT study found that a strong majority of enterprise generative AI pilots fail to deliver measurable P&L impact, with the failures concentrated in integration, data, and governance gaps. Which process to rebuild first is the first technical decision, not a strategic preference exercised after the technology decision, and it determines everything that follows.

Deloitte's 2026 AI in Manufacturing survey polled more than 140 manufacturers and confirms the shape of this execution gap at scale. A strong majority of respondents already generate measurable value from AI. Only roughly one in five use cases has been scaled consistently beyond its original pilot site. That gap between generating value and scaling it tells you where the real problem sits: not in proving that AI can work, but in industrializing it across an operation. Industrialization begins with process selection, because a model proven on the wrong workflow has nowhere to go.

Why Automating a Bad Process Makes It Worse

Process selection outweighs model selection because AI does not repair a broken workflow when it runs inside one. It accelerates whatever damage that workflow was already producing. Deploying AI inside that structure automates the handoffs themselves. It leaves the underlying fragmentation untouched, and in many cases, it hides it.

Construction scheduling makes this concrete. Speed is not the same as accuracy, and an agent working from bad inputs will simply reach the wrong conclusion sooner.

The question that precedes any AI deployment decision should not be "what can we automate?" It should be: if this process were built from scratch for an agent to run, what would it actually look like? That question nearly always produces a workflow different from the one currently in place, because most existing workflows were designed around the assumption that a human would be present at every handoff to catch what the system itself couldn't. Deloitte's findings support this directly: AI creates the most value in processes marked by high variability, many interacting parameters, and material operational consequences. Those are exactly the processes where a broken baseline, once accelerated, does the most damage.

Four Diagnostic Criteria for the Right First Candidate

The right first process is the one that scores highest, simultaneously, across four concrete diagnostic criteria, not the most visible one inside an organization, the one most frequently requested by leadership, or the one with the most obvious technology fit, and most candidate processes will fail at least one of them. That failure is information an operations leader can use, not a reason to abandon the framework.

The first criterion is that the process is already painful in a measurable way. The pain has to be specific and attributable: not "scheduling is hard," but something closer to "we lose three weeks on average between submittal approval and material release because no one owns that handoff." Vague pain produces vague targets, and a rebuild needs a measurable baseline to prove improvement against once the new process goes live.

The second criterion is that the data already exists, or it can be gathered cheaply within a couple of weeks. If those five cannot be brought under control, predictive work on that process cannot proceed. Deloitte's survey backs this up directly: AI adoption is strongest where process signals are rich, outcomes are measurable, and operational ownership is clear. They are selection criteria to apply now.

The third criterion is that a rebuilt version of the process can go live fast enough to prove the model. The first AI-first process should be running in weeks, not quarters, because a long runway before production is itself a diagnostic signal that either the process choice or the approach needs reconsideration. Buy-and-configure deployments typically return investment in 8 to 18 months, while custom builds run 18 to 36 months. A first process should lean toward the faster end of that range, because the organizational proof of concept matters as much as the technical one.

The fourth criterion is that the workflow is reversible and the stakes are recoverable if the first version underperforms. Successful enterprise AI deployment programs start with reversible, low-stakes automation and expand scope only as reliability gets proven in production, and that sequencing is how trust in AI-first processes actually gets built inside an organization. Low-stakes means the failure mode is recoverable. Procurement tracking in construction qualifies even though the dollar values involved are large, because a human buyer can catch and correct an agent's error before it cascades into a missed schedule milestone.

The Gap Between Declared Process and Actual Process

The process that looks cleanest on an org chart or in an SOP is rarely the right first candidate. The right candidate surfaces where the declared workflow and the actual workflow diverge most sharply, and that divergence is where the real operational cost hides. Declared process maps describe intent. In construction and logistics particularly, the gap between what the SOP says happens and what actually happens on a live job is where money disappears, schedules slip, and nobody notices until the consequence lands somewhere downstream.

Surfacing that gap requires mapping how information actually moves through an operation, not the org chart version of that movement but the reality of emails, spreadsheets, and manual handoffs between people who were never meant to be permanent fixtures in the data flow. Every point where a person is manually connecting two systems or translating data between teams is a redesign target, a sign that the process was never designed with an agent in mind because a human is doing work that exists only to bridge a gap the organization never fixed.

Terminal Use's process audit methodology treats this divergence as the starting point. Operations leaders in construction and logistics often assume the most visible or politically requested process is the right one to rebuild first, but the discipline of separating genuine operational pain from internal preference is what narrows the field before any resources get committed to a redesign. The practical first move, in this model, is an operational audit in which the client walks through how a process runs today: every decision point, every handoff, every place where a person is quietly serving as the connection between two systems that should be talking directly to each other. That audit happens before any technology gets discussed, because the technology choice only makes sense once the real process, not the declared one, is on the table.

In construction, and especially on mission-critical programs like data centers, procurement and fabrication tracking is almost always the right first process to rebuild. It is where the most catastrophic schedule surprises originate, and the data needed to fix it already exists inside most firms.

Equipment lead times for generators, switchgear, transformers, and cooling systems often extend 12 to 18 months. By the time a delay becomes visible as a field issue, the root cause has often been sitting in a supplier report for weeks.

This process satisfies the first two criteria cleanly. The gap isn't data collection, it's data integration and signal extraction across documents nobody is systematically reading together. The pain is measurable too: schedule surprises traced back to procurement are among the most expensive recovery scenarios in capital project delivery, making the pain in this process concrete.

It satisfies the fourth criterion as well. A procurement tracking agent that flags a late factory release can be overridden and verified by a human buyer before any downstream action gets taken, so the failure mode is a missed alert. Scheduling and commissioning readiness monitoring, where an agent tracks prerequisite completion in real time and flags which incomplete items sit on the critical path to energization, are second-wave targets. They become reachable only once the upstream procurement data is reliable enough to feed them.

The objection: shouldn't the first process be the one with the highest potential value, not the easiest one?

The strongest objection to this framework is that starting with a tractable process delays the organization's access to its largest source of value. That objection has real force and deserves a direct answer. Deloitte's survey found that AI creates the most value in processes marked by high variability, many interacting parameters, and material operational consequences. A framework that always defaults to the easiest available process would never reach those higher-value targets.

The resolution lies in what "low-hanging fruit" actually means inside this framework. It means selecting a process where data readiness, organizational competence, and problem complexity are currently matched to each other. Procurement tracking on a $500 million data center program is a hard problem that happens to satisfy all four criteria simultaneously, which is a different claim than saying it's easy.

The real risk sits on the other side of this objection. Organizations that attempt to rebuild the most complex process first, without the data infrastructure or the organizational trust needed to support it, tend to reproduce the 14-month shelf-ware pattern the retail computer vision case illustrated. The right ambition is to start where the model can be proven fast enough that the organization builds the confidence to take on the harder processes next.

Running the Process Audit That Surfaces the Right First Candidate

The process audit is a structured diagnostic an operations leader can run in days, not a consulting engagement requiring months of discovery. Its output is a ranked list of candidate processes scored against the four criteria above, and it can be run before any vendor or platform gets evaluated.

The first step is mapping what actually happens, not what the SOP claims happens. Every team that touches a candidate process should walk through what they do: every email, every spreadsheet, every point where a person is the connection between two systems that don't otherwise communicate. This is sometimes called finding the human glue, and every instance of it marks both a redesign target and a signal that the process was never built with an agent in mind.

The second step is a two-week data quality audit against the candidate process. If those five can't be brought under control inside two weeks, predictive or agentic work on that process can't proceed. Data quality functions as a prerequisite here, not a parallel workstream to be handled later.

The third step is scoring each candidate process against the four criteria directly. Is the pain specific and measurable, with a dollar figure, a schedule impact, or an error rate attached to it? Does the data already exist, or can it be gathered within two weeks without standing up new infrastructure? Can a rebuilt version realistically be live within weeks rather than quarters, and if the honest answer is quarters, is the blocker solvable or structural? Is the failure mode of an early version recoverable, with a human able to catch and correct an agent's error before it cascades into something worse?

The fourth step is asking whether this process, if built from scratch for an agent to run, would look anything like it does today. That rebuild specification typically differs from the current workflow in ways revealing exactly where the real friction sits. Once that question has an answer, a platform or vendor can enter the conversation, because the process design should drive the technology choice.

What the First Live Process Makes Possible

A first process that is live, measurable, and producing reliable outputs gives an organization something no pilot ever has: the data, the governance infrastructure, and the internal credibility to rebuild the next process, and the one after that. The scaling gap Deloitte identified, with only roughly one in five use cases scaled consistently across sites or enterprise-wide, is closed by organizations that build governance, data quality standards, and operational trust through a first process that actually ran reliably in production rather than one that merely demonstrated a capability in a controlled setting.

A regional civil contractor with a $40 million heavy equipment fleet offers a useful parallel from outside procurement specifically. The fleet monitoring capability that resulted didn't stay confined to maintenance. It became the data foundation for scheduling and resource allocation improvements on the programs that followed. Terminal Use's diagnostic approach reflects this same structural insight: every engagement begins by auditing the specific workflow that is both measurably broken and ready to rebuild, then getting a live agent into production within weeks, on the premise that process selection determines success long before model capability or technology fit enters the picture. The first process chosen correctly is the first operational unit of an organization that now runs AI-first, with every process built after it inheriting the trust, the data discipline, and the infrastructure the first one earned.