Coach Kaizen

Welcome to Coach Kaizen

Most plants have the data. What's missing is the translation — turning raw exports into clear priorities your team can act on.

Upload your data, map your columns, and Coach Kaizen will walk you through a data quality review and Pareto analysis — step by step, with no surprises.

What would you like to analyze?

Upload your data file

Export your data as an Excel or CSV file, then upload it here. Coach Kaizen will detect your columns automatically.

Accepted formats: Excel (.xlsx, .xls) or CSV (.csv).

Coach note: Consistent naming in your data (e.g. "Line 3" vs "Line3") makes your Pareto cleaner. We'll flag potential issues — you stay in control.

Click to choose a file, or drag and drop here

Excel (.xlsx) or CSV (.csv) accepted

Match your columns

Coach Kaizen made its best guess at matching your columns to standard fields. Review and adjust anything that looks off. Fields marked * are required.

Columns detected in your file

Map to standard fields

Data Quality Review

Before running your analysis, Coach Kaizen scans your data and scores it for completeness. This tells you how much to trust your results — before you act on them.

Coach note: In Six Sigma, we validate our measurement system before drawing conclusions. Your data is your measurement system. Gaps here don't mean your analysis is worthless — they mean you should know where the blind spots are.

Overall data confidence

--

Analysis Ready

Scanning your data...

Field-by-field breakdown

Required fields directly affect your Pareto. Optional fields add depth but won't block your analysis.

Truth Gate

The Truth Gate scores your data before analysis runs. It tells you how many rows are fully usable, what's dragging the score down, and what that means for your results. Your data is never changed here.

Confidence score breakdown

Coach's take

Results

CK

Coach's Take

Data quality summary

See full quality details

Pareto chart — Top loss drivers

DMAIC Projects

Track your improvement projects through every phase of DMAIC.

D

Define

Clearly define the problem, the goal, and who's working on it.

CK

Coach's Take — Define Phase

Why Define Matters

In Six Sigma, a well-defined problem is half solved. The Define phase forces your team to agree on exactly what you're trying to fix before anyone touches a tool or suggests a solution. A vague problem statement leads to a vague project — and a vague project rarely delivers lasting results.

What Makes a Good Problem Statement

A strong problem statement describes what is happening, where it is happening, how much of it is happening, and since when — without assigning blame or assuming a cause. Example: "Surface scratches on Line 1 in the Stamping department account for 18% of total scrap over the last 90 days, representing approximately 640 units per month."

Problem being addressed

Problem statement

Describe what is happening, where, how much, and since when. Do not assign blame or suggest causes yet.

Project goal

What does success look like? Set a specific, measurable target.

Target reduction %

Target completion date

Project scope

What is included in this project? What is explicitly out of scope?

Team members

Who is working on this project? Add names and roles.

M

Measure

Confirm your baseline and define how you'll track progress.

CK

Coach's Take — Measure Phase

Why Measure Matters

You can't improve what you don't measure. The Measure phase locks in your baseline — the current state before any changes are made. Without a confirmed baseline, you have no way to prove your improvement worked. This is the number you'll compare against when you reach the Control phase.

Measurement System Analysis (MSA) — Are You Measuring It Right?

Before you trust your baseline number, ask yourself: is everyone measuring this the same way?

In Six Sigma this is called a Measurement System Analysis. You don't need to run a formal MSA study — but you do need to answer these questions honestly:

· Who records the data? Is it always the same person, or does it vary by shift?
· How is scrap counted? Is a "scratch" defined the same way across all operators and shifts?
· When is it recorded? At the time it happens, or at the end of the shift from memory?
· Where does it go? Is data entered consistently into the same system?

If different people are measuring differently, your baseline is already skewed — and your improvement results will be too. Fix the measurement standard before you fix the process.

On Data Collection

Be specific about who collects data, how often, and where it goes. A data collection plan that lives in someone's head isn't a plan — it's a wish. Write it down, assign an owner, and make sure the team knows the standard.

Baseline — current state

This is pulled from your Pareto analysis. Confirm or adjust if you have more current data.

Baseline quantity (units/period)

Period start date

Period end date

Data collection plan

How will you track this defect going forward? Be specific about who, how, when, and where.

Measurement owner

Tracking frequency

A

Analyze

Find the root cause — not just the symptom.

CK

Coach's Take — Analyze Phase

The Most Important Phase

Most failed improvement projects fail here — not because the team didn't work hard, but because they fixed a symptom instead of a root cause. The problem came back. The Analyze phase is about being ruthlessly honest: keep asking "why" until you reach something you can actually change. If your answer to "why" is "because that's how it's always been done" — you've found something worth fixing.

5 Whys — How to Use It

Start with your problem statement from Define — it's shown below. Ask "Why did this happen?" and write the answer. Then ask "Why did that happen?" Repeat until you reach something actionable and preventable.

The "Therefore" Check: Once you have your chain of whys, read it backwards using the word "therefore." If it makes logical sense, you have a solid chain. If it sounds forced, you've skipped a step or gone in the wrong direction.

Example: Operators aren't using padded trays therefore parts get scratched during transfer therefore surface scratch scrap is high. ✓ That chain holds up.

Common mistake: Teams often tailor their whys to fit a solution they already have in mind. Resist this. Let the whys lead you to the cause — not the other way around. If your why chain leads straight to "we need more training" every single time, that's a sign you're fitting the narrative.

Fishbone Diagram — Do This in Person

The fishbone (Cause & Effect) diagram is one of the most powerful tools in CI — but its power comes from the team conversation, not the drawing. Do this on a whiteboard with your team before filling in the 5 Whys below.

How to run it:
1. Write your problem statement on the right — the "head of the fish."
2. Draw six branches: Man, Machine, Method, Material, Environment, Measurement.
3. For each category, ask: "What here could cause our problem?" Write every idea — no filtering yet.
4. For the most likely causes, drill deeper with "why."
5. Circle the top 2–3 most likely causes. These feed your 5 Whys.

Who to invite: Line operators, supervisors, maintenance, quality. The people closest to the work know what's really happening.

Your problem statement

Use this as your starting point for the fishbone and 5 Whys.

Fishbone session — attach your completed diagram

After your in-person fishbone session, upload a photo of the completed diagram here. This is optional but recommended — it keeps the visual record with the project.

Upload a photo of your fishbone diagram

JPG, PNG, or PDF accepted

5 Whys

Start with your problem statement above and keep asking why. Use the "therefore" check to validate your chain.

Root cause conclusion

Based on your fishbone and 5 Whys, what is the confirmed root cause? It must be specific, actionable, and something your team can actually change. If you can't change it, it's not the root cause.

I am confident this is the root cause — ready to move to Improve

I

Improve

Design, test, and implement solutions that address the root cause.

CK

Coach's Take — Improve Phase

Solutions Must Target the Root Cause

Every solution you propose should connect directly back to the root cause you identified in Analyze. If it doesn't address the root cause, it's a workaround — and workarounds create complexity without solving the problem. Before implementing anything, ask: "Does this prevent the root cause from occurring, or does it just catch the problem after it happens?" Prevention beats detection every time.

Levels of Control — Aim for Level 3

Not all solutions are equal. In Six Sigma we rank solutions by how "mistake-proof" they are. Here's the scale:

Level 0 — Do Nothing. The problem continues. No change.
Level 1 — Training / Awareness. You tell people to do it differently. Works until someone forgets, gets distracted, or is replaced. The weakest form of control.
Level 2 — Checklists / SOPs / Visual Aids. You give people a tool to follow. Better than training alone, but still relies on people choosing to use it.
Level 3 — Physical / Engineering Control. You change the process or equipment so the problem cannot happen. The machine stops, the part doesn't fit wrong, the system won't allow the error. This is the goal.

When designing your solution, ask: "Can we get this to Level 3?" Even if you start at Level 1 or 2, have a plan to get to Level 3 over time.

Pilot Before You Scale

Run your solution on a small scale first — one shift, one line, one week. Document what happened, measure the result, and compare to your baseline. Only scale after you've confirmed it works. This protects your credibility and gives you data to defend the change.

How Long Should You Track Before Declaring Success?

Longer than you think. A common mistake is picking one good week or month and calling it a win — only for the problem to come back the next month.

The rule of thumb: Track for at least 2–3 times longer than your baseline measurement period. If your baseline was 30 days, track for 60–90 days post-implementation before closing the project.

Why this matters: Scrap rates naturally fluctuate. A good month might just be a good month — not evidence that your countermeasure worked. You need enough data to tell the difference between a real improvement and normal variation. If scrap went down but came back up the following month, the improvement didn't hold. Don't chase the low point — chase the sustained average.

Proposed solutions

List each solution you're considering or implementing. Note the level of control where possible.

Pilot plan

How will you test this solution before full implementation?

Pilot owner

Pilot start date

Pilot result

What happened during the pilot? Did it work? What did you measure?

C

Control

Lock in the gains and make sure the problem doesn't come back.

CK

Coach's Take — Control Phase

Why Projects Fail After Improve

The most common failure mode in Six Sigma is a successful Improve phase followed by backsliding — the team moves on, the standard isn't maintained, and six months later the problem is back. The Control phase exists to prevent exactly this. A good control plan makes the new standard the path of least resistance.

Sustaining Your Level of Control

Remember the levels of control from Improve. Your control plan should reflect the highest level you were able to achieve — and identify how you'll get higher over time.

If you're at Level 1 or 2 (training, SOPs, checklists) — your control plan must include a regular audit schedule. Without it, standards drift. People get busy, shortcuts get taken, and the old behavior returns.

If you're at Level 3 (physical / engineering control) — your control plan is simpler because the process prevents the problem. Document what was changed and who is responsible for maintaining the equipment or system change.

Audit cadence recommendation: Weekly checks for the first 30 days. Monthly after that. If a check reveals a deviation, treat it as a new problem to solve — not just a reminder to try harder.

What a Good Control Plan Includes

At minimum: what the new standard is, who owns it, how compliance is verified, what the trigger is for escalation, and what happens when someone deviates. The best control plans are simple enough that a new employee could follow them on their first day — no tribal knowledge required.

Control plan

Document the new standard. What changed, what must be maintained, and how?

Standard owner

Check frequency

Verify the improvement held

Upload a new data file from after your improvement was implemented. Coach Kaizen will run the same Pareto and show you whether your top problem moved.

Upload post-improvement data file

Excel (.xlsx) or CSV (.csv)

Improvement verified — the problem has been sustainably reduced