Continuous Improvement Experiment Tracker

An interactive experiment tracker for kaizen events and rapid operator-led tests. Capture hypothesis, baseline and target metrics, run plan, data collection, results, learnings, and sustainment actions so experiments produce reproducible evidence and clear next steps.

Interactive Tool

Continuous Improvement Experiment Tracker

Use this tracker to run short experiments (kaizen tests, A/B trials, operator-led improvements) with clear measures, evidence, and next steps. Fill the fields below; saved submissions will be stored for review and follow-up.

Quick guidance

  • Write a concise hypothesis in the form: If (change) then (expected result) because (reason).
  • Record a measurable baseline and a clear target. Include how you measure it and over what period.
  • Keep run plans simple and time-boxed. Prefer short cycles with clear owners.
  • Capture results and decide: adopt, iterate, scale, or abandon.
Short, specific name (e.g., 'Reduce conveyor changeover time').
Person accountable for running the experiment and reporting results.
Use YYYY-MM-DD. Helps schedule and compare runs.
Use YYYY-MM-DD. Keep runs short where possible.
Write: If (we do X) then (metric Y will change by Z) because (reason). E.g., 'If we add a visual cue at station A then part defects will fall by 30% because operators will notice misfeeds earlier.'
Connect to customer, safety, cost, throughput, or quality impact.
Name the metric you will measure (e.g., 'Defects per 1,000 units', 'Changeover time (min)').
Enter the numeric baseline (use same units you'll use for results). If baseline varies, describe period below.
Describe dates or sample size used to compute the baseline (e.g., 'Last 2 weeks, 500 units').
Data source, measurement steps, sampling method, and any filters. This makes results reproducible.
Numeric target you expect to achieve (same units as baseline). Be realistic and time-bound.
State exact decision rule, e.g., '>= 20% reduction sustained over 2 shifts' or 'no increase in cycle time > 5%'.
Step-by-step plan, who does what, when data is recorded, and any training or communication required. Keep it short and actionable.
How many units, shifts, or events you'll observe. Needed for reliable comparisons.
Number of calendar days or business days for the run. Short cycles often reveal problems faster.
Who collects data, how (manual log, sensor, OEE export), where it's stored, and frequency (e.g., hourly, per batch). Include links to files if needed.
Select 'Yes' if you have an unchanged group or line to compare against.
Describe the control condition (which line, shifts, products). Leave blank if not applicable.
Mark the current state so reviewers know if action is needed.
Brief narrative of what happened, surprises, and contextual notes.
Enter the numeric result using the same units as baseline. You can compute percent change separately.
Operator feedback, anomalies, and contextual observations that help explain results.
What you learned about the process, assumptions that held or failed, and root causes suggested by the run.
Choose one or more actions to clarify follow-up.
Who will own the change in day-to-day standard work and audits.
E.g., 'OEE, changeover, defect, assembly line A'. Helps search and grouping.
Links to spreadsheets, photos, SOPs, or audit records stored in your systems. Attachments are not collected here; store links or references.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.

Discussion

Comments and conversation will live here.