Kaizen (改善) is not a method — it is a discipline. The word itself means continuous improvement, but the cultural practice it represents has a more specific structure: observe a problem, form a hypothesis about its cause, make a targeted change, and measure whether the change produced the expected result. The Plan-Do-Check-Act cycle that Deming and Shewhart formalized from Japanese quality practice in the postwar period is kaizen at its most explicit.
What distinguishes kaizen events that produce durable improvement from those that produce temporary momentum is the quality of the "Check" step. If before-and-after measurement relies on operator recollection, shift report summaries, or spot counts made during the event itself, the "Check" is unreliable. Problems look solved that have not been solved. Problems that were temporarily masked by the heightened attention during the event reappear after the kaizen team disperses. The improvement is not in the process — it is in the behavior of people who knew they were being watched.
Production data collected from PLC streams and process historians closes this gap. But only if the data collection is designed to support the kaizen loop, not merely to report on it.
What a Kaizen Data Record Requires
For a kaizen event to produce a traceable before-after record, four data conditions must be met.
First, the baseline measurement window must be defined and locked before the kaizen event begins. "Before" data collected during the same week the kaizen team is on the floor is contaminated — operators work differently when observed. A 4-week rolling average of the target metric, collected from PLC logs before the event was announced, is a cleaner baseline. For OEE-focused kaizen events, this means having continuous OEE data from the line at shift-level granularity for at least a month prior.
Second, the kaizen hypothesis must be stated in measurable terms. "Reduce changeover time" is not a measurable hypothesis. "Reduce changeover time on Line 2 die set A-to-B from 47 minutes (4-week average) to 30 minutes, measured as the interval between last good part of previous run and first good part of new run, sourced from PLC cycle count timestamps" is a measurable hypothesis. The specificity of the measurement definition is what makes the Check step meaningful.
Third, the post-event measurement window must be long enough to confirm durability, not just initial execution. A successful kaizen event will produce good results in week 1 when the new standard work is fresh in operators' minds. The question that matters is week 4 and week 8 — whether the improvement has been absorbed into standard practice or has reverted under production pressure.
Fourth, the record must be stored in a queryable format, not a PDF or presentation deck. Kaizen records that live in presentation files are practically inaccessible for future reference. When a similar problem appears on a different line six months later, the team that solved it previously will not remember the specifics, and retrieving the relevant presentation requires knowing it exists and finding someone who has access.
A Practical Example: Changeover Reduction at a Hydraulics Subassembly Line
A mid-size hydraulics components manufacturer in Saitama Prefecture was running 6 assembly lines with mixed product families. Their changeover times ranged from 35 to 80 minutes depending on product transition type. A SMED kaizen event was planned for Line 4, targeting the most frequent transition — product family B to product family C, which accounted for roughly 30% of all changeovers.
The Omron Sysmac NX controller on Line 4 was already logging production mode transitions with timestamps. Before the event, the production engineering team pulled 6 weeks of transition data: mean changeover 61 minutes, standard deviation 18 minutes, range 38-94 minutes. The variance was itself informative — the wide range suggested the changeover was operator-dependent rather than process-constrained, which shaped the SMED approach toward standard work documentation rather than tooling redesign.
Post-event week 1 average: 28 minutes. Week 4 average: 34 minutes. Week 8 average: 31 minutes. The improvement held with minor regression in week 4 — attributable, via shift log cross-reference, to a new operator being assigned to the line without receiving the updated changeover standard work training. That specific observation fed directly back into the training onboarding checklist.
This is the kaizen loop in its most functional form: the data is the record, the record surfaces secondary issues, and those issues feed the next improvement cycle. None of this is possible without continuous PLC-sourced timestamps as the measurement substrate.
The Problem with Event-Based Kaizen Without Continuous Data
Japanese manufacturing has a strong tradition of physical kaizen tools — the A3 report, the fishbone diagram, the 5-Why chain — that are effective for structured problem analysis without requiring digital infrastructure. We are not saying these tools are obsolete or that they require digital augmentation to work. Many of the most disciplined kaizen practices in Japanese manufacturing run effectively with paper-based tools and produce real, sustained results.
The limitation appears specifically at scale and at cadence. A facility running 6-10 kaizen events per quarter across multiple lines faces a practical information management problem: which improvement hypotheses have been tested on which lines, which produced results, which reverted, and which are pending validation. Without a queryable kaizen record linked to production data, this information lives in the memories of the engineers who ran the events — and turns over with employee transitions.
The institutional knowledge problem in Japanese manufacturing, particularly at mid-size facilities facing the demographic shift of experienced engineers approaching retirement, is not primarily a cultural problem. It is a data architecture problem. Decades of improvement knowledge embedded in individual expertise can be partially preserved in structured digital records — but only if the kaizen loop is designed from the start to produce records, not just outcomes.
Connecting Kaizen Records to OEE Trend Analysis
When kaizen events are tagged in the production database — with a start date, the target metric, the line affected, and the hypothesis — they become overlayable events in OEE trend analysis. A 12-month OEE chart with kaizen events marked as annotations shows clearly which improvement activities produced sustained OEE movement and which produced temporary spikes followed by reversion.
This overlay is one of the most valuable outputs of a production intelligence system for a facility actively running kaizen programs. It answers the question that is genuinely hard to answer from memory: "Of the 14 kaizen events we ran on the discrete lines last year, which 6 produced the most durable OEE improvement, and what did they have in common?"
Pattern recognition at that level — looking back across a year of improvement activity and identifying the structural characteristics of successful events — is a 改善 (kaizen) of the kaizen process itself. Shigeo Shingo, whose work on SMED and error-proofing has influenced nearly every discrete manufacturing quality program, was fundamentally interested in this kind of meta-improvement: not just solving specific problems but understanding the conditions under which improvement efforts succeed. Production data makes that inquiry concrete rather than impressionistic.
Implementation Priorities
For a facility beginning to integrate production data into its kaizen practice, the sequence matters. Start with continuous OEE data at shift granularity on the lines where kaizen events are planned. This is the baseline infrastructure — without it, before-after comparison is impossible.
Second, establish the convention of tagging kaizen events in the production system before the event begins, not after. Pre-registration forces the team to define the measurable hypothesis before they start work — which is independently valuable for kaizen discipline, separate from the data benefit.
Third, set a review cadence for kaizen records: 4 weeks post-event and 12 weeks post-event, with automatic pulls of the target metric from the production database. The review should be brief — 15 minutes to look at the trend, note whether the improvement held, and file the result. This is the "Act" step of PDCA applied to the kaizen event itself.
The overhead of this process is lower than it sounds. Once the baseline data infrastructure is in place, the marginal cost of tagging an event and scheduling two brief follow-up reviews is small. The return — a growing library of tested improvement records that new engineers can reference, and a trend analysis that shows which improvement investments are actually working — accumulates over years, not weeks. That is the timescale on which kaizen discipline operates.