The board mandate landed in your inbox at 4:52 on a Friday. Eleven plants, three countries, one sentence: "Build us an AI plan, and show the operations council momentum in a quarter." You read it twice. The VP who pushed it just toured a competitor's "smart factory" and came back convinced your network is behind. Meanwhile the reality on the ground is the one you already know: Plant 4 still runs a 1990s programmable logic controller (PLC, the industrial computer that controls a machine), the historian at Plant 7 has not been queried in three years, Plant 2 lost its best quality inspector to retirement in March and first-pass yield dropped two points the next month, and 85 percent of your peers say staffing shortages are hurting product quality. You have ninety days to turn a board sentence into something a plant manager will actually believe in. Not a deck. Not a digital-twin demo. A first quarter that produces evidence, earns trust, and does not blow up the OT network on the way. This lesson is that ninety days, day by day, with a number attached to every move.

Why the First Ninety Days Decide the Program

An enterprise AI transformation is won or lost in its first quarter, and not for the reason the keynote speakers claim. It is not won by picking the right model or the flashiest vendor. It is won by whether the floor believes the program is real and worth their scarce attention, and whether leadership sees a number they trust before their patience runs out. Both clocks start the day the mandate lands, and both are shorter than you think.

The floor clock is about trust. Your operators and techs have lived through initiatives before: the Lean rollout that became a poster on the wall, the dashboard nobody opened, the digital-twin pilot that ran for six months and disappeared. An operator who was once burned by a false alarm on a vision system will quietly disable the green light, and a maintenance crew that got buried in noisy alerts will start ignoring the predictive-maintenance tool. If the first ninety days produce one more thing to ignore, the program is dead and no amount of L4 strategy will revive it. The first quarter has to ship something a real person uses on a real shift.

The leadership clock is about evidence. The operations council funded this on a promise, and promises decay. If quarter one produces a roadmap and a vendor shortlist but no measured result, the second quarter's budget conversation starts from a defensive crouch. You need at least one defensible number by day ninety: a logged save in the computerized maintenance management system (CMMS, the software that holds work orders and maintenance history), a measured drop in false-reject rate on one line, a first-pass-yield delta you can tie to a specific change. One real number, owned by a named human, beats ten slides of projected return.

Consider the math that makes this urgent. A single defect escape that becomes a customer containment can cost more than a month of the entire training program. One logged predictive-maintenance save on a critical asset, where you caught a bearing trending toward failure and replaced it on a planned weekend instead of a hot Tuesday afternoon, can pay back a whole cohort's training many times over. If you avoid one eight-hour unplanned line stop on a line that throws off 40,000 dollars an hour in contribution margin, that is 320,000 dollars that did not evaporate. The first ninety days are not about scale. They are about generating one or two of those numbers so the rest of the program funds itself politically.

The first quarter does not have to scale. It has to produce one number leadership trusts and one workflow the floor actually uses, both owned by a named human.

Greenfield plants deploy AI 40 to 60 percent faster than brownfield, and almost none of your network is greenfield. That is not a reason to wait. It is the reason the first ninety days have to be sequenced around the brownfield constraint honestly: pick the plant and the use case where the data already exists and the OT visibility is good enough, prove it there, and let that site become the reference the rest of the network copies. Trying to start everywhere at once on a network you cannot fully see is how transformations die in month two.

Days 1 to 30: Establish the Spine

The first thirty days are not for deploying anything. They are for building the spine that everything else hangs on: a governance forum that can say yes and no, a baseline of numbers you can later prove movement against, and an honest readiness picture of which plant goes first. Skip this month and you will deploy fast into chaos and have nothing to measure against.

Stand up the governance forum in week one

On day one, you name the AI governance forum and you put quality, maintenance and reliability, operational technology (OT, the control-system side of the plant) security, and environment, health and safety (EHS) at the same table, with a single accountable executive who owns the program. This is not bureaucracy. It is the body that prevents the most common first-month failure: an enthusiastic engineer at one plant bolting an AI model onto a PLC over the weekend because the vendor said it was easy, with no one checking the OT boundary. Remember that 78 percent of OT networks lack centralized monitoring, which means most of your plants cannot even see what is happening on the control network. The forum's first rule, written on day one, is simple: AI stays advisory and out of direct control of anything that moves until it is properly governed, and every AI-touched quality decision gets logged for the customer audit.

The forum's job in month one is to set the guardrails and the decision rights, not to design workflows. It decides who can authorize a pilot, what the kill criteria are, and how a save or an escape gets logged. It writes down that the customer audits the plant, not the vendor, so accountability for any AI-assisted quality or maintenance decision stays with the human who signs the record. "The model flagged it" is never a sufficient answer to an auditor or a customer, and the forum makes that explicit before anyone deploys.

Baseline the numbers in weeks two and three

You cannot prove a transformation moved the needle if you never wrote down where the needle started. In weeks two and three, you baseline the metrics that the whole program will be judged on, at every site, in the same definitions. The core set is overall equipment effectiveness (OEE, the combined measure of availability times performance times quality), first-pass yield (FPY, the share of units that pass without rework), unplanned downtime hours, scrap and rework cost, and where a vision system already exists, the false-reject rate.

The trap here is that every plant defines OEE slightly differently, so a network-level number built on eleven different definitions is a vanity metric. Pick one definition, document it, and have each plant restate its last twelve months against it. A worked example: Plant 7 reports OEE of 78 percent, but on inspection half of its planned-maintenance downtime is being excluded from the availability calculation in a way Plant 4 does not exclude it. Restated on the common definition, Plant 7 is at 71 percent. That seven-point gap is not a failure, it is the discovery that tells you where the real opportunity is, and you only find it because you baselined honestly in month one.

Run the readiness assessment and pick the first site

By the end of week four you choose the lighthouse site, the one plant where the first real deployment happens. The selection is not political and it is not the plant with the loudest manager. It is the plant that scores highest on four brownfield-honest readiness factors: the data already exists and is queryable (the historian has been maintained, the CMMS records are clean enough), OT visibility is good enough to deploy safely, the workforce includes at least one champion who wants this, and there is a single loss big enough to matter. A plant losing 320,000 dollars on a recurring unplanned stop, with a clean historian and a reliability engineer who has been asking for this for a year, beats a bigger plant with messy data and no internal advocate every time.

Days 31 to 60: Ship One Workflow at One Site

Month two is where the program stops being a plan and becomes a thing that runs on a shift. You deploy exactly one workflow, at the lighthouse site, on one line or one critical asset. Not three workflows hedged across three plants. One, done all the way to a logged result, because a single deep success is the reference the whole network will copy and a portfolio of shallow pilots is the thing the operations council defunds.

Choose the workflow by loss size and data readiness

The choice between the two highest-value use cases comes down to which one your lighthouse site is ready for. If the site's biggest loss is the hot-afternoon breakdown and it has a maintained historian, you ship the sensor-to-work-order predictive-maintenance workflow: the model reads the historian tag, flags the asset trending toward failure, and the workflow writes a prioritized, verified work order rather than stopping at a dashboard. If the site's biggest loss is the defect escape and it already runs a camera, you ship the vision-quality workflow with drift and false-reject guardrails built in from day one instead of bolted on after the first failure.

Either way, the workflow must end in an action and a log, not a screen. The difference between a model that alerts and a workflow that prevents is the entire point. A predictive-maintenance dashboard that shows a rising vibration trend but never becomes a work order is the dashboard nobody reads. The same signal, routed into a verified work order that a tech executes on a planned weekend, is a logged save worth six figures.

Design the human handoff so the floor trusts it

The single biggest reason a technically correct AI workflow fails on the floor is that the human who has to act on it does not trust it. So in month two you design the operator-AI handoff explicitly. The model is advisory. It proposes, a named human disposes, and the disposition is what gets logged. For a vision system, that means the operator sees the flagged part, makes the call, and the system records both the model's flag and the human's decision. For predictive maintenance, the reliability engineer reviews the alert, verifies it against the historian and the machine's own model book, and either issues the work order or marks it a false alarm with a reason.

That false-alarm path matters more than it looks. False-reject economics are real money: a vision system's false-reject rate can quietly cost more than the escapes it catches, and an operator burned by a false alarm will disable the green light. By logging every false alarm with its reason, you do two things at once: you give the model owner the data to tune it, and you show the operator that their judgment is part of the system, not overruled by it. A worked example: on the first line, the model flags 50 parts a shift, the operator confirms 6 as real defects and marks 44 as false rejects. That 12 percent precision is a problem you can now see and fix, instead of a green light the crew silently stopped trusting.

Log the first save in the language leadership trusts

When the first save lands, you log it in the CMMS in dollars and downtime hours, not in model accuracy. Leadership does not trust "the model achieved 94 percent recall." It trusts "we caught the number-three press bearing trending toward failure on March 14, replaced it on the planned Saturday shutdown, and avoided an estimated eight-hour unplanned stop worth 320,000 dollars in contribution margin, logged in work order WO-44817." That sentence, with a work-order number behind it, is the artifact that funds quarter two. It is also grounded and defensible, which matters when someone on the council asks how you know the stop would have happened.

Days 61 to 90: Prove It and Make It Repeatable

The final thirty days turn one site's success into something the network can repeat. The temptation at day sixty is to declare victory and start deploying everywhere. Resist it. Month three is for proving the result honestly, packaging it into a playbook another plant can follow, and building the human capacity that the rest of the rollout will depend on.

Measure the result against the baseline you set in month one

Now the month-one baseline pays off. You measure the lighthouse site's result against its own restated starting point: the false-reject rate dropped from 12 percent to 4 percent after two tuning cycles, first-pass yield on that line moved up 1.5 points, or unplanned downtime on the critical asset fell by the logged save. The number has to be honest, including the part that did not work. If the vision model still struggles on the wet parts under changed lighting, you say so, because the credibility you build by reporting the limitation is worth more than the point you would gain by hiding it. Structured programs see 3 to 4 times higher adoption than self-directed learning precisely because they are honest about what works and teach the verification, not just the demo.

Package the playbook so the next site does not start from scratch

The reusable asset from quarter one is not the model. It is the playbook: the readiness checklist, the common metric definitions, the governance guardrails, the human-handoff design, and the logging standard. When Plant 4 deploys next quarter, it should not rediscover that OEE definitions diverge or that operators ignore unverified alerts. It should inherit the lighthouse site's hard-won lessons. This is how a brownfield network closes some of the 40 to 60 percent greenfield speed gap: not by pretending the plants are clean, but by making the second deployment far faster than the first because the pattern is now written down.

Build the human capacity the rollout depends on

The talent cliff is the reason this program exists, so the first ninety days have to start solving it, not just deploying around it. Roughly 2 million manufacturing workers need reskilling by 2026 against about 500,000 unfilled roles, and you cannot hire your way out of that. In month three you name AI champions across shifts at the lighthouse site and at least one at each of the next two sites, and you start the structured training that gives them the verification skills the program runs on. The champion is not a data scientist. They are the reliability engineer or quality engineer who learned to read a model's output skeptically, verify a flagged spec against the drawing, and log a save in language leadership trusts. That person, multiplied across shifts and sites, is the actual transformation. The models come and go; the verified, AI-literate crew is the durable asset.

Present to the operations council with a number and a next move

At day ninety you go back to the council not with a status update but with a result and a defensible next step. The structure is simple: here is the baseline we set, here is the one workflow we shipped, here is the logged save and the yield delta, here is what did not work and what we learned, here is the playbook, and here is the next site and the next single workflow with its expected loss reduction. You are not asking them to believe a projection. You are showing them a number and asking to repeat the pattern. That is the difference between a transformation that gets its second quarter funded and one that becomes another deck in the shared drive.

The Traps That Kill a First Quarter

Most failed enterprise AI transformations do not fail on the technology. They fail on a small number of predictable traps in the first quarter, and naming them is how you design around them before they happen.

The everywhere-at-once trap. The board said eleven plants, so the instinct is to start at all eleven. Spreading a thin team across a network you cannot fully monitor produces eleven shallow pilots, no logged save, and a defensive budget conversation in quarter two. One lighthouse site, one workflow, one number. Depth before breadth.

The dashboard trap. A model that produces a screen is not a workflow that produces a result. If the predictive-maintenance output is a vibration chart that never becomes a work order, or the vision output is a defect count nobody dispositions, you have built another thing for a slammed crew to ignore. Every workflow must end in a logged action owned by a human.

The vanity-metric trap. "Models deployed" is not a result. "Sites with an AI dashboard" is not a result. The only metrics that fund a transformation are the ones tied to a real loss: logged downtime avoided, false-reject rate reduced, first-pass-yield delta, scrap cost down. If your day-ninety deck leads with activity instead of outcome, the council hears a program spending money without proving value.

The OT-shortcut trap. The vendor demo makes connecting the model to the control system look like a weekend job. On a network where 78 percent lack centralized monitoring, an AI model with a path to a PLC is a security and safety exposure first and a productivity tool second. Keep it advisory, keep it off anything that moves, and route the OT decision through the governance forum every time.

The verification-skipped trap. Under deadline pressure, the easiest thing to cut is the human verification step, and it is the one thing that must never be cut. An invented torque spec, a fabricated procedure, or a confidently wrong root cause that ships to a customer because nobody checked it against the drawing is exactly the failure that turns the board's enthusiasm into a containment and a lawsuit. The job shifted from producing the draft to verifying the draft against the drawing, the standard, and the historian, and the first ninety days have to make that verification a logged, non-optional step.

Key Takeaways

• The first ninety days are won on trust and evidence, not technology. Ship one workflow the floor actually uses and produce one number leadership trusts, both owned by a named human, before the floor clock and the leadership clock run out.
• Days 1 to 30 build the spine: stand up a governance forum with quality, maintenance, OT security, and EHS in week one; baseline OEE, first-pass yield, downtime, scrap, and false-reject rate on one common definition; and pick the lighthouse site on brownfield-honest readiness, not politics.
• Days 31 to 60 ship exactly one workflow at one site, ending in a logged action not a dashboard. Design the operator-AI handoff so a human disposes and the disposition is logged, and capture every false alarm with its reason so the model can be tuned and the crew stays trusting.
• Days 61 to 90 prove the result against the month-one baseline honestly, package the readiness checklist, metric definitions, guardrails, and logging standard into a playbook so the next site is faster, and name AI champions across shifts to start closing the talent gap.
• Log every save in dollars and downtime hours with a work-order number, never in model accuracy. "Avoided an estimated eight-hour stop worth 320,000 dollars, logged in WO-44817" is the artifact that funds quarter two; "94 percent recall" is not.
• Keep AI advisory and out of direct control on a brownfield network where 78 percent of OT cannot be centrally monitored, and route every OT decision through the governance forum. The customer audits the plant, not the vendor, so accountability stays with the human who signs the record.
• Avoid the five first-quarter traps: starting everywhere at once, building dashboards instead of workflows, reporting vanity metrics, taking the OT shortcut, and skipping verification. Each one is predictable and each one is fatal to the second-quarter budget.
• The durable asset of the first ninety days is not the model but the AI-literate, verifying crew. With roughly 2 million workers needing reskilling against about 500,000 unfilled roles, the champion who can verify a flagged spec and log a save is the transformation; the models come and go.