It is a Tuesday on the floor of a mid-market job shop, and the continuous-improvement lead, a Lean practitioner named Maria, has a problem that has nothing to do with whether AI is impressive. She has booked a three-day kaizen event to attack the changeover time on Press Line 2, the line that bleeds the most overtime. Kaizen is the Japanese term for a focused, hands-on improvement event where a small cross-functional team studies one problem and fixes it in a tight window. The trouble is that her team is the same crew that runs the line. She has one operator who can attend, a maintenance tech who can give her half a day, and a quality engineer who is already underwater on a customer containment. Last quarter she ran a kaizen the old way: the first full day vanished into pulling data, arguing about which downtime reasons were real, and drawing a current-state map from three people's memories. By the time anyone proposed a change, the event was two-thirds gone and the team was exhausted. Eighty-five percent of manufacturers say staffing shortages are hurting product quality, and Maria feels that number in her bones every time she tries to gather a team. This lesson is about the single highest-leverage move a slammed CI lead can make in 2026: do the heavy analysis before the event, with AI, so the kaizen itself can be short, focused, and actually finish.

Why the Prep Is the Bottleneck, Not the Event

Walk into any kaizen post-mortem and you will hear the same complaint dressed up in different words: we ran out of time. The team did not run out of ideas. It ran out of the hours it takes to turn scattered plant data into a shared, agreed-upon picture of the current state. That picture, the current-state map and the loss breakdown that justifies the event, is the foundation everything else stands on. And it is almost always built live, in the room, during the most expensive hours the plant will spend that month.

Think about what a kaizen actually costs. A three-day event with six people pulled off the floor, at a fully loaded labor rate of roughly 55 dollars an hour, is 6 people times 24 working hours times 55 dollars, which is about 7,920 dollars in labor alone, before you count the production those people would have run. If the line they normally staff makes 400 dollars an hour in contribution margin and two of them coming off it slows throughput, the true cost of the event climbs past 12,000 dollars fast. When the first day, a full third of that spend, evaporates into data wrangling, you have burned roughly 4,000 dollars discovering things the data already knew. That is the bottleneck. Not the brainstorming. The cost of getting everyone to a shared starting line.

The reason this happens is structural. The information a kaizen needs lives in five different places that do not talk to each other: the historian (the time-series database that logs every machine signal, also called the data historian), the MES (Manufacturing Execution System, the software that tracks production orders and records on the floor), the CMMS (Computerized Maintenance Management System, where work orders and maintenance history live), the quality system, and the heads of the operators who actually run the line. Pulling those five sources together by hand, reconciling their disagreements, and shaping them into one story is genuinely hard work. It is also exactly the kind of work that AI, used as an analysis assistant rather than a decision-maker, can compress from a day into an hour.

The kaizen does not run out of ideas. It runs out of the hours it takes to agree on what is actually happening. Move that work before the event.

What AI Actually Does in the Prep Phase

Be precise about the role here, because this is where plants get burned. In kaizen prep, AI is doing three jobs, and none of them is deciding what to fix. It is summarizing, structuring, and drafting. The CI lead and the team still own every conclusion. The model assembles the raw material so the humans can spend their scarce hours on judgment instead of clerical work.

Job one: turn a downtime export into a ranked story. You pull the last 90 days of downtime records out of the MES, which is usually a messy spreadsheet with inconsistent reason codes, free-text operator notes, and the same fault described four different ways. You give that to the model and ask it to consolidate the reason codes, total the minutes by category, and rank them. What used to be an afternoon of pivot tables becomes a draft Pareto in minutes. A Pareto chart is the bar chart that ranks loss categories tallest to shortest so you attack the biggest one first. On Maria's Press Line 2, the raw export had 31 distinct reason-code strings; the model collapsed them into eight real categories and showed that changeover and die-setup accounted for 4,100 of the 9,600 lost minutes in the quarter, about 43 percent. That single number reframes the whole event.

Job two: draft the current-state map and the standard-work gaps. Feed the model the existing work instruction for the changeover, the operator interview notes, and the time-study observations, and ask it to lay out the current sequence step by step with the observed time for each step and flag where the documented procedure and the observed practice disagree. The model is good at this kind of structured comparison. It will surface that step 7, "torque the die clamps," takes the day-shift operator 90 seconds and the night-shift operator 6 minutes, because they do it in a different order. That gap is gold for a kaizen, and finding it by hand means transcribing two time studies and sitting them side by side.

Job three: pre-build the event agenda and the data pack. Once the loss is ranked and the gaps are mapped, the model can draft a focused agenda that spends the team's hours on the 43 percent that matters, a one-page data pack the team reads before they walk in, and a starter list of likely root-cause hypotheses to test, not to accept. The agenda and the pack are deliverables the CI lead edits and owns. The hypotheses are a thinking aid the team will confirm or kill with their own eyes on the floor.

The line every prep crosses, and must not

The model can say "changeover is 43 percent of your loss and the torque step varies wildly between shifts." It cannot say "the root cause is operator training" and have that be trusted. Correlation in a downtime export is not a root cause. The prep produces a sharp, evidence-backed starting question. The event, with humans on the floor, produces the answer. Confuse those two and you will walk into a kaizen having already decided the conclusion, which is the fastest way to fix the wrong thing.

The Prep Workflow, Step by Step

Here is the workflow Maria now runs in the two days before any event. It takes her about three hours instead of the first full day of the kaizen, and it is repeatable.

Step one: pull and clean the loss data. Export 60 to 90 days of downtime and scrap data from the MES and the quality system. Hand it to the model with a clear instruction: consolidate inconsistent reason codes into a defined list, total the impact by category in both minutes and estimated dollars, and rank them. Always give the model the dollar conversions yourself, because it does not know your contribution margin. On Press Line 2, Maria told it that a downtime minute on that line costs about 6.70 dollars in lost margin, so the 4,100 changeover minutes carried a roughly 27,500 dollar quarterly price tag. That dollar figure is what gets a slammed team to show up.

Step two: verify the ranking against a second source. Before you trust the Pareto, cross-check the top category against the CMMS and the historian. If the MES says changeover is the tallest bar, the historian should show the matching idle-time signatures on the press during those windows. If the two sources disagree, you have either a data problem or a more interesting story, and either way you found it in prep, not in front of six people. This is the verification habit the whole program is built on: never let one AI-shaped summary be the only witness.

Step three: build the current-state map. Give the model the work instruction, the time studies, and the operator notes, and have it draft a step-by-step current-state sequence with times and flagged variances. Then you walk the actual line once with a stopwatch and check the draft against reality. The model's map is a hypothesis; your walk confirms or corrects it. The combination is far faster than building the map from scratch and more accurate than trusting the document alone.

Step four: assemble the data pack and agenda. Have the model draft the one-page pack (the ranked loss, the current-state map, the top variances) and a time-boxed agenda. Edit both. Send the pack to the team 24 hours ahead with one instruction: read this before we start. Now the event opens with everyone already at the shared starting line that used to eat the first day.

The payback is direct. A three-day event becomes a one-and-a-half-day event because the day of data wrangling is gone, and the analysis is sharper because it is built on consolidated 90-day data instead of three people's memories. At roughly 4,000 dollars of saved event time per kaizen, a plant that runs ten events a year recovers about 40,000 dollars of its most expensive hours, and the improvements land faster because the team spends its energy on the floor, not in a spreadsheet.

A Worked Example: Press Line 2

Let us run Maria's actual changeover kaizen end to end so the numbers are concrete.

Before the event. Maria exports 90 days of MES downtime for Press Line 2: 9,600 total lost minutes across 31 raw reason codes. The model consolidates these into eight categories and ranks them. Changeover and die setup top the list at 4,100 minutes. At 6.70 dollars per minute, that is about 27,500 dollars for the quarter, an annualized run rate north of 110,000 dollars. She cross-checks against the historian, which confirms long idle stretches on the press flywheel signal during shift-start windows. The ranking holds.

The current-state draft. The model lays the changeover out in 14 steps from the day-shift time study and the night-shift time study side by side. It flags three steps where the two shifts differ by more than two minutes. The biggest: die-clamp torque, 90 seconds day shift, 6 minutes night shift. Maria walks the line during a real changeover and confirms the night-shift operator hunts for the right torque wrench every time because it is not staged at the press. That is not something the data could prove, but the data pointed her straight at the step where the answer was hiding.

The event. Because the team walked in with the data pack already read, the kaizen opened not with "what is our problem" but with "we know changeover is 43 percent of our loss and we have three high-variance steps; let us fix them." The team spent its hours on the floor running and timing changeovers, standardizing the sequence, and staging the tools. They did not spend a single hour building a Pareto. The event closed in a day and a half.

The result. Standardizing the sequence and staging the torque wrench cut average changeover from 38 minutes to 24 minutes. Across the changeover frequency on that line, that recovered about 1,500 minutes a quarter, roughly 10,000 dollars of annualized margin from one event, plus a written standard the next shift can follow. The prep did not make the improvement. The team did. The prep made the team's scarce hours count.

What would have gone wrong without verification

Imagine Maria had trusted the first draft Pareto without the historian cross-check. One of the 31 raw reason codes, "press fault," was being entered by the night shift for everything from a real PLC fault to "I had to wait for the forklift." A PLC, the Programmable Logic Controller, is the industrial computer that runs the machine's logic. Left unconsolidated, "press fault" looked like the second-tallest bar and would have pulled the kaizen toward a controls problem that barely existed. The cross-check against the historian, which showed almost no actual fault signatures during those windows, exposed the miscoded data. Verification is not bureaucracy. It is what kept the event aimed at the real 43 percent instead of a data artifact.

Keeping It Audit-Ready and Honest

A kaizen produces a record: a current-state map, a future-state plan, an action list, and a results claim. When AI helped build any of those, the same accountability rule that governs every AI-touched decision on the floor applies here. The customer audits you, not the vendor, and "the AI built our Pareto" is not an answer an IATF 16949 auditor will accept. IATF 16949 is the automotive quality management standard most suppliers are certified to. If your CI records feed a corrective action that touches a customer part, they have to be defensible.

Three habits keep AI-assisted kaizen prep honest.

Keep the source data, not just the summary. The model's consolidated Pareto is a derived artifact. Keep the raw MES export it was built from, so anyone can re-derive the ranking and confirm the consolidation was faithful. If an auditor or a skeptical plant manager asks how "changeover" got to 43 percent, you can show the line-level records, not a chart you cannot reconstruct.

Name a human on every conclusion. The data pack should say who verified the ranking, who walked the line to confirm the current-state map, and who owns each action. The model drafts; a named person signs. This is the same discipline a thinning crew needs everywhere AI touches a record, and it is what makes the difference between a credible kaizen and a generated one.

Separate what the data showed from what the team concluded. Write the record so the evidence (changeover is 43 percent; the torque step varies by shift) is clearly distinct from the root cause the team verified on the floor (the wrench is not staged at the night-shift station). When those two are blurred, a future reader cannot tell which claims rest on data and which rest on the team's on-the-floor judgment, and that ambiguity is exactly what erodes trust in AI-assisted work.

Done this way, AI-assisted prep does not weaken the kaizen's credibility; it strengthens it, because the event now rests on consolidated 90-day data with a clear audit trail instead of on whoever in the room remembered the most. A thinner, greener crew gets to run a tighter event and defend it to a customer, which is precisely the leverage the talent cliff demands.

Key Takeaways

• The kaizen bottleneck is the prep, not the event: a full first day commonly vanishes into pulling data and agreeing on the current state, burning roughly 4,000 dollars of the most expensive hours a plant spends that month.
• In prep, AI does three jobs and decides nothing: it consolidates a messy downtime export into a ranked Pareto, drafts the current-state map and flags shift-to-shift variances, and pre-builds the agenda and data pack. The team still owns every conclusion.
• Always feed the model your own dollar conversions; it does not know your contribution margin. On Press Line 2, 4,100 changeover minutes at 6.70 dollars a minute was about 27,500 dollars a quarter, the number that got a slammed team to show up.
• Verify the ranking against a second source before you trust it. The historian cross-check exposed a miscoded "press fault" category that would have aimed the kaizen at a controls problem that barely existed.
• The model's current-state map is a hypothesis you confirm with a stopwatch walk; the combination is faster than building from scratch and more accurate than trusting the document alone.
• Prep turned Maria's three-day event into a day and a half, cut changeover from 38 to 24 minutes, and recovered roughly 10,000 dollars of annualized margin, because the team spent its hours on the floor, not in a spreadsheet.
• Keep audit-ready records: retain the raw source data behind every AI summary, name a human on every verified conclusion, and keep the evidence the data showed distinct from the root cause the team confirmed on the floor.
• For a thinning crew, moving the analysis before the event is the highest-leverage CI move available: it makes scarce hours count and produces a kaizen you can defend to an IATF 16949 customer audit.