Book Demo →

KaizenFlow AI Certified CI Specialist — Course

Module 01 · 26 min · 3 fig.

From Six Big Losses to a ranked backlog

As a Quality/CI specialist you already speak the Six Big Losses. This module shows how KaizenFlow maps each loss to a measurable factor and ranks the resulting backlog by dollars and confidence so you stop optimizing the loudest loss instead of the costliest one.

Every loss is a factor, not a feeling

KaizenFlow decomposes OEE into the Six Big Losses and ties each one to logged factors: Availability losses split into Breakdowns and Setup/Adjustment; Performance losses into Minor Stops and Reduced Speed; Quality losses into Startup Rejects and Production Rejects. Each factor is fed by a concrete data source — downtime tiles, reason-code logs, cycle-time deltas versus ideal, and scrap counts by station. The point is that nothing on the backlog is an opinion; every item traces back to a quantity the platform measured.

FIG. 1.A SIX LOSSES, SIX MEASURED FACTORS KF·CIS-01
Six Big LossesAvailabilityBreakdownsSetup/AdjustmentPerformanceMinor stopsReduced speedQualityStartup rejectsProduction rejects
Availability, performance, and quality each split into two factors, and each factor is fed by a logged source — downtime tiles, reason codes, cycle-time deltas, scrap counts. Nothing on the backlog is an opinion; every item traces to one of these leaves.

Ranking by dollars and confidence, not by noise

The AI converts each loss into an annualized dollar figure using the line's throughput value and the measured loss minutes or reject units. It then attaches a confidence score reflecting data density and signal stability. A frequent, well-instrumented minor-stop loss can outrank a dramatic but rare breakdown.

  • Dollars = loss magnitude × value of recovered capacity, normalized to a comparable annual rate.
  • Confidence reflects sample size, sensor coverage, and how stable the pattern is over time.
  • Sort by expected value (dollars × confidence) before committing scarce Kaizen capacity.
FIG. 1.B HEADLINE DOLLARS BY LOSS FACTOR KF·CIS-01
52kMINOR STOPSchronic · labeler40kBREAKDOWNSdramatic · rare30kREDUCED SPEED24kSETUP/ADJUST18kPROD. REJECTS9kSTARTUPREJECTS
Annualized dollars alone put the $52k minor-stop loss first and the $40k breakdown second — but this view hasn't asked yet how much of each number you can trust. That's the next sort.
FIG. 1.C RANKED BY EXPECTED VALUE KF·CIS-01
01Minor stops — labeler$44,000/yr$52K × 0.85 CONF02Reduced speed — downstream cell$27,000/yr$30K × 0.90 CONF03Breakdown — weekly, press$18,000/yr$40K × 0.45 CONF
Dollars × confidence re-sorts the three contenders: the dramatic $40k breakdown drops to last place because its sparse, one-operator data makes the savings unverifiable. Scarce Kaizen capacity goes to the top row.
Key takeaway

Rank the backlog by expected value — dollars times confidence — so you work the costliest verifiable loss, not the most visible one.

Module quiz · question 1 of 3

Q1Which pairing of a Big Loss to the factor KaizenFlow measures it with is correct?

Module quiz · question 2 of 3

Your ranked backlog shows three items. A: a dramatic weekly breakdown, $40k/yr at confidence 0.45 — logged by one operator, sparse sensor coverage. B: chronic minor stops on the labeler, $52k/yr at 0.85 — dense sensor data. C: reduced-speed loss on a downstream cell, $30k/yr at 0.90.

Q2Kaizen capacity is one team. Which item gets it?

Module quiz · question 3 of 3

Q3A supervisor wants 'the packer crew seems slow on Fridays' added to the Kaizen backlog. What has to happen first?

Module 02 · 26 min · 2 fig.

Root cause, accelerated

A manual fishbone can take a team days and still land on a plausible-but-wrong cause. This module shows how KaizenFlow's cross-line correlation narrows the candidate causes fast — and why correlation is a lead, not a verdict.

Cross-line correlation as an accelerated fishbone

Instead of brainstorming every possible Man/Machine/Material/Method cause, you let the platform surface which signals move together. KaizenFlow correlates a loss against other time-series across lines, shifts, materials, and upstream stations — so a scrap spike on Line 3 that tracks a humidity reading or a specific resin lot or a particular night-shift crew rises to the top automatically. You arrive at the high-probability branches of the fishbone in minutes, then spend your effort confirming rather than enumerating.

FIG. 2.A THE FISHBONE, ACCELERATED KF·CIS-02
Loss flaggedSCRAP SPIKE · LINE 301CorrelateeverythingLINES · SHIFTS · LOTS02Top branchessurfaceMINUTES, NOT DAYS03Confirm mechanismYOUR JOB STARTS HERE04
Instead of brainstorming every Man/Machine/Material/Method branch, the platform surfaces which signals actually move with the loss. You arrive at the high-probability branches in minutes — then your real work starts.

Confirm the mechanism before you act

Correlation points; it does not prove. Before committing a countermeasure you need a plausible physical mechanism and, ideally, corroboration from a second independent signal or a small confirmation test.

  • Demand a mechanism: can you explain physically why X causes the loss?
  • Look for a second corroborating signal, not just the single strongest correlate.
  • Check the time order — the suspected cause should lead, not lag, the loss.
  • Watch for a lurking common driver that moves both variables.
FIG. 2.B TWO CORRELATES, SAME GATES KF·CIS-02
MECHANISM2ND SIGNALTIME ORDERCONFOUNDHumidity · r 0.82Resin lot · r 0.55passesplausible, untestedopen
Humidity's 0.82 clears no more gates than the resin lot's 0.55 — and neither has ruled the other out as a shared driver. A split test closes the last column; the r value never does.
Key takeaway

Cross-line correlation gets you to the right fishbone branches fast, but a root cause isn't confirmed until you can name the mechanism and rule out a common driver.

Module quiz · question 1 of 3

KaizenFlow flags that Line 2's production rejects correlate at 0.82 with ambient humidity over 30 days — and at 0.55 with a resin lot that happened to run on the humid days. Maintenance wants to buy a dehumidifier today.

Q1What do you do first?

Module quiz · question 2 of 3

Q2A correlate is most trustworthy as a root-cause candidate when:

Module quiz · question 3 of 3

Scrap on Line 3 correlates strongly with a vibration reading on the outfeed conveyor. You pull the time-series: the vibration spikes start a few minutes after each scrap run begins — never before.

Q3What does the timing tell you?

Module 03 · 24 min · 2 fig.

Designing the experiment

A fix you can't measure is a story, not an improvement. This module covers framing a Kaizen or DMAIC change as a clean before/after the platform can actually verify.

Define the metric and the baseline window first

Before you change anything, pin down the primary metric (e.g., minor-stop minutes per shift, or first-pass yield on a station) and capture a baseline window long enough to span normal variation — multiple shifts, crews, and product mixes. KaizenFlow uses this window as the comparison anchor. In DMAIC terms, this is Define and Measure done with platform data instead of a clipboard: the metric is operationally defined, and the baseline is the real distribution, not a single good day.

FIG. 3.A AN EXPERIMENT THE LEDGER CAN VERIFY KF·CIS-03
Define the metricMINOR-STOP MIN/SHIFT01Capture baselineSHIFTS · CREWS · MIXES02One stamped changeGO-LIVE IN LEDGER03Compare windowsPLATFORM VERIFIES04
Define and Measure happen in platform data before anything changes. The stamped go-live is the hinge — it's what makes 'before' and 'after' unambiguous instead of reconstructed.

Make the change isolable and time-stamped

An experiment the platform can verify needs a clean change boundary and as little simultaneous noise as possible. Mark exactly when the countermeasure goes live so before and after are unambiguous, and avoid stacking multiple changes at once.

  • Change one thing at a time, or you can't attribute the result.
  • Time-stamp go-live so the ledger compares the right windows.
  • Hold confounders steady where you can — same product, same line, comparable crews.
  • Pre-state the expected effect size so a too-small result isn't rationalized later.
FIG. 3.B BEFORE/AFTER WITH A STAMPED BOUNDARY KF·CIS-03
BASELINE RANGEPRE-STATED TARGETGO-LIVESHIFTMINOR-STOP MIN
Twelve baseline shifts span crews and product mixes; the go-live stamp splits the windows; the 30-minute target was pre-stated before the change. The after-window clears it — and nobody has to re-argue what success meant.
Key takeaway

Decide the metric, baseline window, and exact change boundary before you act — a verifiable before/after is designed, not reconstructed.

Module quiz · question 1 of 3

You want to prove a new SMED procedure cuts setup loss on Line 4. Production wants to roll it out across all three shifts Monday — and switch to a faster fixture the same week.

Q1How do you frame the experiment?

Module quiz · question 2 of 3

Q2Why pre-state the expected effect size before the change goes live?

Module quiz · question 3 of 3

For a first-pass-yield experiment, a teammate proposes last Tuesday's day shift as the baseline: one crew, one product, and the line's best run in weeks.

Q3What's wrong with that baseline?

Module 04 · 24 min · 2 fig.

Proving it landed

The verified-savings ledger is where a Kaizen becomes a number finance will sign. This module covers how to read it: baseline normalization, confidence weighting, and what makes a claim defensible.

Baseline normalization: comparing like with like

Raw before/after deltas are misleading if conditions shifted. The ledger normalizes the baseline for confounders — production volume, product mix, runtime, and demand — so the savings reflect the change, not a busier month. If after-period volume was higher, the platform adjusts the comparison rather than crediting your countermeasure with throughput it didn't create. When you read a ledger entry, check what was normalized; an un-normalized delta is the first thing finance will challenge.

FIG. 4.A COMPARING LIKE WITH LIKE KF·CIS-04
RAW DELTA$90kafter-window +20% volumeNORMALIZED DELTA$63kvolume · mix · runtime adjusted−$27kCREDIT THE BUSIER MONTH KEEPS
The after-window ran 20% more volume, so part of the raw $90k is scrap the busier month would have avoided anyway. Normalization returns that credit before the claim moves forward.

Confidence weighting and the finance-ready number

Each ledger entry carries a confidence weight reflecting data quality and how cleanly the change was isolated. The savings figure finance signs is the confidence-weighted, normalized value — deliberately conservative.

  • Headline gross delta: the raw improvement, before adjustments.
  • Normalized delta: adjusted for volume, mix, and runtime.
  • Confidence-weighted savings: the normalized value discounted by certainty — this is the sign-off figure.
  • Attribution note: what else changed in the window that could share credit.
FIG. 4.B FROM GROSS TO FINANCE-READY KF·CIS-04
90$kGROSS DELTA−27$kNORMALIZATION−15$kCONFIDENCEDISCOUNT48$kSIGN-OFFFIGURE
Two deliberate haircuts stand between the headline and the signature: normalization for what conditions gave you, and a confidence discount for how cleanly the change was isolated. $48k is the number that survives the meeting.
Worked example — the sign-off number

Your scrap fix shows a gross reduction of $90k annualized — but the after-window ran 20% more volume, and a supplier switch overlapped the first week. The ledger works the claim down:

Gross delta = $90k/yr Volume/mix adj. = −$27k Normalized delta = $63k/yr Confidence weight = 0.76 Sign-off = $63k × 0.76 ≈ $48k/yr

The $42k that disappeared isn't lost savings — it's the part of the claim finance would have found and rejected. A conservative ledger number survives the meeting; a gross one doesn't.

Key takeaway

Finance signs the normalized, confidence-weighted number — not the raw delta; if you can't explain what was normalized and discounted, the claim isn't ready.

Module quiz · question 1 of 3

Your ledger entry shows a gross scrap-cost reduction of $90k annualized. After-period volume ran 20% above baseline, and the change overlapped a one-week supplier switch. The normalized, confidence-weighted figure reads $48k.

Q1What do you present to finance?

Module quiz · question 2 of 3

Q2What does baseline normalization in the verified-savings ledger primarily correct for?

Module quiz · question 3 of 3

A ledger entry reads: gross delta $30k · normalized delta $24k · confidence-weighted $19k · attribution note: 'new nozzle set installed the same week.'

Q3Which number goes in the savings report, and what happens to the note?

Module 05 · 20 min · 2 fig.

Standardize and scale the win

An unstandardized win decays the moment attention moves on. This module covers turning a verified fix into a standard and rolling it across comparable lines and plants without assuming it transfers blindly.

Standardize so the gain holds

A verified countermeasure becomes durable only when it's written into standard work, reason codes, and the control plan — and when the platform watches the metric for regression. In CI terms this is the Control phase: define the new standard, set the metric the line is held to, and let KaizenFlow alert if the loss creeps back. A fix that isn't standardized shows up again on next quarter's ranked backlog, which is the platform telling you the gain leaked.

FIG. 5.A HOLD THE GAIN OR REPEAT THE WORK KF·CIS-05
Verified fixLEDGER ENTRY SIGNED01Write the standardSTANDARD WORK · CODES02Watch the metricREGRESSION ALERT SET03Gain holdsCONTROL PHASE04NO STANDARD → BACKLOG AGAIN
A verified fix only becomes durable when it's written into standard work, reason codes, and the control plan — with the platform watching for regression. Skip that, and next quarter's backlog hands you the same loss back.

Replicate by similarity, verify per site

Rolling a win to other lines is a hypothesis, not a copy-paste. Use the platform to find lines with similar equipment, loss profile, and product to prioritize where the fix is likely to transfer — then run a real before/after at each new site rather than assuming the savings carry.

  • Target lines whose loss signature matches the original, not just the same machine model.
  • Each rollout site gets its own baseline and verified ledger entry.
  • Expect effect size to vary by site; don't extrapolate one line's dollars across all.
  • Standardize the standard itself so each site adopts the same operational definition.
FIG. 5.B PICK ROLLOUT SITES BY SIGNATURE KF·CIS-05
SAME MODELLOSSSIGNATURECALLLine 5pilot nowLine 7holdLine 9pilot nextmatches Line 2partial matchdiffers
Line 7 shares the labeler model but not the minor-stop signature the fix attacks — it waits. Line 9's different machine bleeds the same loss, so it pilots. Every site still gets its own baseline and its own ledger entry.
Key takeaway

Standardize to hold the gain locally, then replicate by loss-profile similarity with a fresh verification at every site — savings transfer as a hypothesis, never as an assumption.

Module quiz · question 1 of 3

You verified a $44k/yr minor-stop fix on Line 2's labeler. Leadership wants to multiply by your eleven other lines and book $528k. Four lines run the same labeler model; the rest use different equipment with different loss profiles.

Q1How do you roll it out?

Module quiz · question 2 of 3

Q2How does KaizenFlow tell you a standardized fix has decayed?

Module quiz · question 3 of 3

Your changeover fix verified clean. You briefed all three crews at shift meetings and moved on. Three months later the same setup loss is back on the ranked backlog.

Q3What was missing?

Module 06 · 22 min · 2 fig.

When the AI is wrong

Trusting AI rankings blindly is its own failure mode. This advanced module covers stress-testing a recommendation, spotting spurious correlation, and keeping a human in the loop before dollars move.

Stress-test before you commit

Treat every AI recommendation as a hypothesis to attack. Ask what data it rests on, how dense and recent that data is, and whether the confidence reflects real signal or just a short, lucky window. Probe the failure cases: would the recommendation survive a different product mix, a crew change, or last quarter's data? A recommendation that only holds in one narrow window — or that no operator can physically explain — is a candidate for spurious correlation, not action.

FIG. 6.A STRESS-TEST BEFORE DOLLARS MOVE KF·CIS-06
AI proposes$60K · CONF 0.801What data?9 DAYS · RUSH ORDER02Other windows?MIX · CREW · QUARTER03Mechanism?NO ONE CAN SAY04Hold, don't spendASK FOR MORE WINDOW05
Treat the recommendation as a hypothesis to attack. This one dies on the data check and the mechanism check — nine days covering a one-off rush order, and no operator who can explain the physics.

Spot the spurious, keep the human in the loop

Spurious correlations are seductive because the math looks clean. Your job is to apply the judgment the model can't.

  • No mechanism, no action: if nobody can explain the physics, hold.
  • Beware coincidence at scale — search enough signals and some will correlate by chance.
  • Distrust thin data: high confidence on a tiny or stale sample is a red flag.
  • Gate spend on human sign-off; the AI ranks and proposes, the specialist decides.
  • Feed the outcome back — confirmed and rejected recommendations both sharpen future ranking.
FIG. 6.B THE SCORE CAN'T TELL THEM APART KF·CIS-06
LOOKS LIKE SIGNALconf 0.809 days · one crew · no mechanismIS SIGNALconf 0.783 months · multi-crew · mechanismnamed−0.02AND WORTH ACTING ON
A 0.80 on nine lucky days versus a 0.78 on three months of multi-crew data with a named mechanism. The lower score is the one you act on — the judgment between them is exactly the part the model can't do.
Key takeaway

The AI ranks and proposes; the specialist verifies the mechanism and decides. No mechanism plus thin data equals hold, not spend.

Module quiz · question 1 of 3

KaizenFlow's top recommendation: re-sequence Line 6 jobs to cut a performance loss — $60k/yr at confidence 0.8. The correlation spans only nine days, no operator can explain why sequence would matter, and those nine days covered a one-off rush order.

Q1What do you do?

Module quiz · question 2 of 3

Q2Which condition most strongly suggests an AI recommendation is spurious?

Module quiz · question 3 of 3

You stress-tested a recommendation, found the window thin, and rejected it. A teammate says logging the rejection in KaizenFlow is wasted admin — 'just skip to the next card.'

Q3Why log it?

Course complete.

You’ve worked all 6 modules. Sit the free practice exam to see if you’re ready for the real assessment — same format, instant grading, keyed back to the modules.

Take the practice exam → Get certified