8.10 Kaizen, Kaizen Blitz, Theory of Constraints, and OEE

Kaizen and kaizen blitz

Kaizen means change for the better. As a management practice it is continuous, incremental improvement performed by everyone as part of normal work: small changes, suggested and implemented locally, accumulating over years.

Kaizen blitz (also kaizen event or rapid improvement event) is a concentrated, time-boxed attack on one bounded problem by a dedicated cross-functional team, typically over three to five consecutive days.

When to use which

Choose a blitz when the problem is bounded and physically visible, the solution is largely known or easily discoverable by observation, implementation rather than analysis is the constraint, and the people who do the work can be released for a week.

Choose DMAIC instead when the cause is genuinely unknown, the answer requires statistical analysis of data that must be collected over time, or the process spans several functions and sites.

Choose ongoing kaizen when the aim is a stream of small improvements and cultural change rather than a step change.

A typical blitz week: Monday train the team and map the current state at the gemba; Tuesday collect data and analyze waste; Wednesday design the future state and start physically changing the process; Thursday implement, trial, and adjust; Friday standardize, write the new standard work, train the shift, and present results.

Two failure modes are common. Blitzes are run on problems whose causes are unknown, and the team implements a plausible but wrong solution in a week. And gains are not sustained because the new standard work was never audited -- a blitz needs a 30-day follow-up with a named owner as part of its definition of done.

Theory of constraints

Developed by Eliyahu Goldratt, TOC holds that every system has at least one constraint that limits its throughput, and that improvement anywhere else produces no system gain.

The five focusing steps

1. Identify the constraint. Look for the step with the longest cycle time, the highest utilization, and inventory accumulating immediately in front of it.
2. Exploit the constraint. Get everything possible from it without capital spend: never let it idle, run it through breaks and shift changes, do not process defective material on it, move setup work off it, and inspect before it so it never works on scrap.
3. Subordinate everything else to the constraint. Non-constraint resources should run at the constraint's pace, not their own. This is counter-intuitive because it means deliberately leaving non-constraint equipment idle, and it conflicts directly with local utilization metrics.
4. Elevate the constraint. Now spend money: add capacity, buy equipment, outsource, add a shift.
5. Repeat. Once the constraint is broken, another becomes binding. Go back to step 1, and do not let inertia become the constraint -- policies written for the old constraint frequently outlive it.

The key implications

• Throughput of the system equals throughput of the constraint. An hour lost at the constraint is an hour lost by the whole system; an hour saved at a non-constraint is worth nothing.
• Local efficiency metrics are actively harmful. Measuring non-constraint machines on utilization drives overproduction, which creates inventory and hides problems.
• Buffer the constraint. A small protective inventory in front of the constraint prevents it from starving; this is the drum-buffer-rope scheduling mechanism, where the constraint is the drum that sets the pace.

TOC and lean are complementary rather than competing. Lean seeks to eliminate waste everywhere; TOC says sequence that work by starting where it changes throughput.

Overall equipment effectiveness

OEE is a single measure of how much of the theoretically available production time is genuinely productive.

$OEE = \text{Availability} \times \text{Performance} \times \text{Quality}$

These are the six big losses: breakdowns and setup (availability), minor stoppages and reduced speed (performance), process defects and startup losses (quality).

Worked example. A shift has 480 planned minutes, 60 minutes of downtime, produces 900 units at an ideal cycle time of 0.4 minutes per unit, with 45 rejects.

• Run time $= 480 - 60 = 420$ min. Availability $= 420 / 480 = 0.875$.
• Performance $= (0.4 \times 900) / 420 = 360 / 420 = 0.857$.
• Quality $= (900 - 45) / 900 = 855 / 900 = 0.950$.

$OEE = 0.875 \times 0.857 \times 0.950 = 0.712$

An OEE of 71.2%. The convention is that 85% is world class (roughly 90% availability, 95% performance, 99% quality), and that typical manufacturing runs around 60%.

Reading OEE correctly

• Never report OEE as a single number without its three components. The same 71% can arise from chronic breakdowns or from a quality problem, and the actions are completely different. Here the binding losses are availability and performance, not quality.
• The denominator matters. OEE is normally computed against planned production time, which excludes scheduled non-production such as unstaffed shifts. Computing against all 1,440 minutes in a day gives Total Effective Equipment Performance (TEEP), a different and much lower measure.
• OEE is a loss-analysis tool, not a target. Chasing an OEE number on a non-constraint machine produces overproduction, which is exactly what TOC warns against. Measure OEE at the constraint, where every recovered minute becomes system throughput.

That last point is the connection between the two frameworks: TOC tells you where to improve, and OEE tells you what the loss consists of once you are there.