Help me create a practical kaizen for this operational issue. Process and problem: [PROCESS AND PROBLEM] Current evidence: [CURRENT-STATE EVIDENCE] Target condition: [TARGET CONDITION] Team and constraints: [TEAM AND CONSTRAINTS] Time available: [TIME AVAILABLE] First, ask up to 3 clarifying questions only if a required input is missing. Do not assume root causes, baseline data, authority, or available tools that I have not provided. Produce a one-page kaizen plan with these sections: 1. Problem statement: define the gap in observable terms, including where it occurs, how often, and its effect. 2. Current state: map the relevant steps from trigger to handoff; identify waiting, rework, approvals, queues, motion, or information gaps using only my evidence. 3. Likely causes: separate confirmed causes from hypotheses to test. Use a short 5 Whys chain only where the evidence supports it. 4. Countermeasures: propose the smallest reversible changes first. For each, name an owner, exact action, due date, required support, expected effect, and leading measure. 5. Experiment plan: state the baseline, success threshold, test duration, and how the team will capture results. 6. Follow-through: give a daily check-in cadence, a review date, and a standard-work update step if the change succeeds. Use a table for the action plan. Keep the scope narrow enough to complete within [TIME AVAILABLE]; defer larger system changes to a clearly labeled next kaizen. Before answering, check that every action has one accountable owner and a measurable outcome, and flag claims or causes not supported by the evidence.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS AND PROBLEM] | Describe the workflow, where it breaks down, and the operational consequence. | Customer refund requests sit in an inbox for 3 to 6 days before review; customers send repeat emails. |
| [CURRENT-STATE EVIDENCE] | Paste observed timings, counts, examples, process steps, or team notes. | 42 requests last month; 31 lacked an order number; support copies details into a sheet, then finance approves twice daily. |
| [TARGET CONDITION] | State the desired measurable condition and any quality or safety requirement. | A complete refund request receives a decision within one business day, with no increase in incorrect refunds. |
| [TEAM AND CONSTRAINTS] | List the people involved, their roles, decision limits, systems, and constraints. | Two support specialists, one finance approver, Zendesk and Google Sheets; no new software this quarter. |
| [TIME AVAILABLE] | Enter the practical time window for the improvement work and trial. | Five working days to test changes, then a 30-minute review. |
How to use
- Paste an observed problem and the current-state facts, not a theory of what caused it.
- Check that the baseline and target use the same unit, such as hours, defects, or requests.
- Assign named owners before sharing the plan; a role without a person is not ownership.
- After the test, send: “Here are the results against the baseline. Update the plan and recommend standard work or the next experiment.”
Variations
Workshop agenda
Use this when you need to facilitate a short kaizen session.
Create a 90-minute kaizen workshop agenda for [PROCESS], attended by [PARTICIPANTS], to address [PROBLEM]. Use the available evidence: [EVIDENCE]. Include timed activities for defining the problem, mapping the current state, identifying waste, selecting one testable countermeasure, assigning owners, and agreeing on measures. Produce a facilitator script, materials list, and a decision log template. Do not claim causes are proven unless the evidence demonstrates them. Ask up to 3 questions only if a required input is missing.
A3 summary
Use this when leadership needs an A3-style improvement brief.
Write an A3-style improvement summary for [PROCESS PROBLEM] using [EVIDENCE] and [PROPOSED CHANGE]. Include background, current condition, target condition, root-cause analysis with confirmed facts separated from hypotheses, countermeasures, implementation owners, timing, and follow-up measures. Keep it to one page of plain language. Flag missing baseline data or unsupported causal claims instead of filling gaps. Ask up to 3 clarifying questions only when an essential input is absent.
Daily huddle
Use this when a kaizen is already running and the team needs a huddle format.
Build a 10-minute daily kaizen huddle template for [IMPROVEMENT GOAL] during [TEST PERIOD]. Use these actions and measures: [ACTION LIST AND DATA]. Include yesterday’s result versus baseline, barriers, owner commitments due today, escalation criteria, and one field for learning that changes the experiment. Produce a reusable agenda and a filled example using only supplied facts. Do not turn a single day’s result into a conclusion. Ask up to 3 clarifying questions if needed.
Tips
- Start with one failure mode, such as incomplete intake data or a delayed approval, rather than trying to repair an entire department.
- Measure the condition at the point of work; an average monthly dashboard can hide the queue or handoff causing the delay.
- Treat a countermeasure as an experiment until it improves the chosen measure without creating a quality, safety, or workload tradeoff.
- Update standard work only after the trial is stable enough to teach and audit.
FAQ
What is the difference between a kaizen and a project plan?
A kaizen tests a small, specific improvement against a current condition. A project plan may contain broader work, but it should not replace a clear baseline and experiment.
Can AI identify the root cause?
It can organize evidence and propose hypotheses, but it cannot verify a cause without observations or data. Test hypotheses before committing to a fix.
How many actions should a kaizen include?
Use only the few actions needed to test the first countermeasure. If the list requires multiple teams or months of work, split it into smaller kaizens.