Build continuous improvement into the way your factory operates.

Define continuous improvement as an operating system

NIST describes continuous improvement as an organizational mindset focused on ongoing effort, while Lean Enterprise Institute places PDCA and Kaizen at the center of scientific learning. In practice, the system needs explicit inputs, decisions, roles, and feedback, not just encouragement to submit ideas.

Separate three rhythms. Daily management exposes deviations from standard. Structured problem solving addresses recurring or consequential gaps. Portfolio review selects larger cross-functional or capital changes. Connecting the rhythms prevents small abnormalities from disappearing and prevents every problem from becoming a large project.

• Purpose and customer outcome
• Visible standard and target condition
• Safe route for surfacing abnormalities
• Evidence and experiment method
• Owner, review cadence, and escalation path

What does continuous improvement look like in a normal shift?

A team notices that orders repeatedly wait for a missing drawing. It records ten consecutive handoffs, tests a readiness check with the next ten, then compares waiting and correction work. This fictional example is small enough to inspect without claiming that twenty orders prove a lasting result.

The working principles are straightforward: define value for the customer, observe the work, involve the people doing it, test a manageable change and check whether it holds. Keep safety, quality and the next team in view. Daily Kaizen provides that ongoing practice; an event gives a bounded problem concentrated attention. Use the PDCA guide to plan the check and the Kaizen event guide when the change needs a cross-team session.

Start with a measurable gap at the gemba

Write the current condition and target in operational terms: product, process boundary, shift, time window, expected result, observed result, and impact. Visit the work with the people who run and support it. A dashboard can locate a pattern; it cannot show every workaround, queue rule, material condition, or control behavior.

Preserve the baseline before changing anything. Use counts, timestamps, process states, quality evidence, maintenance history, and direct observations. Label estimates and missing data. If the team cannot agree on what success means, it is too early to debate solutions.

Use the smallest experiment that can teach safely

Form a causal hypothesis and state the predicted result before the trial. Choose the smallest reversible change that can distinguish the hypothesis from alternatives. Keep safety, regulatory, quality, and customer controls outside the experiment unless a qualified owner approves a controlled change.

Compare like conditions and record what else changed. A useful test may be one shift, one product family, one machine mode, or a simulation when the live system cannot be interrupted. The result should show effect size, uncertainty, side effects, and the conditions under which the conclusion applies.

1. Frame

   Define the gap, customer consequence, boundary, and owner.

2. Observe

   Build a shared timeline from process evidence and direct work observation.

3. Predict

   State the mechanism, expected result, and evidence that would disprove it.

4. Test

   Run a bounded change or validated scenario with guardrails.

5. Verify

   Confirm the local mechanism and system outcome over time.

Connect daily improvement to priorities and capacity

Not every idea deserves immediate work. Rank opportunities by expected system impact, confidence in the evidence, effort, risk, strategic fit, and available people. Protect capacity for urgent containment, daily improvements, and a small number of deeper projects.

Make stopping rules explicit. Close work that lacks an owner, cannot obtain evidence, duplicates another effort, or no longer addresses the constraint. A healthy pipeline contains rejected and paused ideas as well as completed ones; otherwise prioritization is ceremonial.

Sustain the result without freezing the process

Update standard work, training, controls, maintenance tasks, data definitions, and response rules after the result is verified. Assign a process owner and define a review window long enough to include different products, shifts, and operating conditions.

Sustainment does not mean treating the new method as permanent. It means making the best known method visible, detecting drift, and reopening PDCA when the context changes. Compare actual benefit with the prediction so future prioritization becomes more accurate.

Use 3C for a small problem, not as a whole improvement system

In daily problem solving, 3C can mean Concern, Cause and Countermeasure. Record the observed problem, the evidence for its cause and the action to test. Add an owner and a result check. If the cause is still a guess, the next action is to investigate, not to close the problem.

Names depend on the model. Toyota describes continuous improvement and respect for people as the two pillars of the Toyota Way. These are not two stages of an investigation. A short 3C record can support that approach, but it cannot replace the wider work of developing people, setting priorities and checking results.

Which seven-step improvement process do you mean?

ITIL uses a named continual-improvement model for services. PeopleCert describes seven prompts: agree the vision, establish the current position, choose the target, plan the route, act, check achievement and keep the improvement going. It is a useful service-management model, not a required seven-stage manufacturing standard.

Older ITIL material also calls its measurement sequence the seven-step improvement process: identify the improvement strategy, define measurements, gather data, process it, analyze it, present and use the findings, then implement improvements. Do not mix that sequence with the seven prompts above. For a shop-floor trial, PDCA may be enough; an uncertain defect problem may need DMAIC.