Continuous improvement is supposed to create learning that compounds over time. In many factories, however, improvement work still depends heavily on workshops, spreadsheets, isolated reports, and what people remember from the previous shift. A Kaizen event can create visible progress, but a few weeks later the same loss often appears again under slightly different production conditions. The issue is not always the quality of the improvement idea. The bigger problem is that teams often cannot prove whether the countermeasure actually worked, where it worked, and under which conditions it stopped working.

WHY KAIZEN IMPROVEMENTS OFTEN DISAPPEAR
A workshop creates focus for a few days. Teams map the process, identify waste, assign actions, move tools, change checklists, or adjust handoffs. Then normal production pressure returns. The supervisor has another urgent order, maintenance has another fault, planning changes the sequence, and quality puts another batch on hold. The improvement action remains somewhere in an Excel file or project tracker instead of becoming part of the operating rhythm. The important question is therefore not whether an action was completed, but whether the production condition actually improved.

PDCA NEEDS A REAL CHECK STEP
Plan, Do, Check, Act sounds simple, but many organizations effectively run Plan, Do, and Move On. PLAN should define a testable problem, the current condition, the expected improvement, and the hypothesis behind the countermeasure. DO means testing the countermeasure under real production conditions while recording enough context to understand what actually happened. CHECK means comparing the expected result with real production evidence. ACT means standardizing the change when the evidence supports it, or adapting, narrowing, or reversing it when it does not.   
• Did the loss actually decrease?
• Did the problem simply move somewhere else?
• Did the change improve availability while damaging quality?
• Did it work across different products, crews, and shifts?
• Did maintenance, material, scheduling, or another process change influence the result?
A single successful production run is not proof. Continuous improvement needs enough evidence to separate a repeatable improvement from a lucky shift.

GEMBA AND DATA NEED EACH OTHER
Data does not replace Gemba. Operators, supervisors, technicians, planners, and quality teams understand production conditions that systems often cannot capture. A machine record may show a ten-minute stop, while an operator knows that the stop happened because a component felt wrong, a normal material route was blocked, or the previous shift left the station in an unusual condition. At the same time, observation alone shows only one shift, one event, or one version of the problem. Connected operational data makes it possible to test whether an observation repeats across orders, products, machines, shifts, material batches, and longer periods of time.    

Gemba helps teams identify where to look and which questions matter. Operational data helps test those questions across the real production pattern. Standard work then carries the learning forward so the next shift does not start from zero.

START WITH THE IMPROVEMENT QUESTION
One of the biggest mistakes in manufacturing analytics is beginning with the data that happens to be available. A modern production line can generate huge volumes of information from PLCs, sensors, MES systems, ERP, quality systems, maintenance applications, and spreadsheets. More data does not automatically create better decisions. A useful improvement process starts with the production question the team actually needs to answer.

Instead of asking “What data do we have?”, ask “What production question are we trying to answer?” A statement such as “changeovers take too long” is still too broad. A better question would be: Why does changeover time vary significantly for the same product family on the same production line? That immediately helps define the context that matters.   
• Previous product
• Next product
• Production order
• Resource or line
• Tool configuration
• Material
• Shift or crew
• Setup start
• Restart time
• First acceptable unit
• Stable production
• Quality results
• Machine alarms
The goal is not to collect everything. The goal is to collect the smallest set of facts capable of changing the improvement decision.

ERP EXPLAINS THE PLAN
ERP provides the commercial and planning context around production. It can show planned quantities, routing, customer commitments, material requirements, order priority, and the intended production sequence. That context matters because production conditions constantly change. A countermeasure might genuinely reduce setup time while delivery performance still deteriorates because the production mix changed or planners introduced more frequent product transitions.
ERP therefore helps explain what was supposed to run, in what sequence, for which demand, with which routing and materials. But ERP primarily describes intent. It does not necessarily describe what physically happened on the shop floor.  

MES EXPLAINS WHAT ACTUALLY RANThe Manufacturing Execution System fills part of that gap. MES can provide the execution history behind an order, including actual operation start and finish, produced quantity, rejects, holds, rework, resources, operator transactions, material consumption, traceability, and reason codes. This allows improvement teams to connect losses with real orders and operations instead of relying on memory or daily averages.   

MES data still needs interpretation. Transactions may be entered late, different crews may use reason codes differently, and a timestamp may represent when an operator confirmed something instead of the exact physical moment when it happened. The system provides evidence, but the process gives that evidence meaning.

MACHINE AND IOT DATA EXPLAIN THE PHYSICAL PROCESS
When teams need to understand what happened inside an operation, machine data becomes important. PLC and IoT signals can expose machine states, cycle times, alarms, speed, temperature, pressure, interlocks, motor load, restart behavior, and time to stable production. MES may show that an operation restarted at a particular time, while machine data explains what happened during the minutes before stable output returned. 
• Repeated alarms
• Reduced speed after restart
• Temperature recovery
• Manual adjustments
• Interlocks
• Unstable cycle times
Machine data without production context can still be misleading. An alarm becomes much more useful when it can be connected to the work order, product, operation, resource, tool condition, material, and quality result surrounding the event.

THE SHOP FLOOR ADDS MEANING
Operators, maintenance technicians, supervisors, and quality teams fill the gaps that automated systems cannot. A reason code such as “material issue” may describe very different situations in practice. The material may have arrived late, behaved differently, carried an incorrect label, been damaged, or created a downstream problem that only became visible later.

Structured codes help categorize events. Human context helps explain them. Data capture therefore needs to fit the reality of production instead of interrupting it. The useful question is not how much information an operator can enter, but what is the smallest human input that would make the next improvement decision better.    

YOU NEED A SHARED FACTORY LANGUAGE
ERP, MES, maintenance systems, historians, and spreadsheets can all describe the same production event differently. One system may call a resource “Line 3,” another may use “LINE03,” maintenance may track several separate assets inside the line, and a historian may still use an old PLC tag. All of these identifiers can technically be correct while still making cross-system analysis unreliable.

The same problem applies to definitions. “Production complete” might mean the machine finished, MES posted the quantity, quality released the batch, the product was packed, or the order was ready to ship. A dashboard cannot decide which definition is correct. The organization has to define that shared meaning. Why Continuous Improvement Need…

THE DATA MODEL BEHIND CONTINUOUS IMPROVEMENT
A useful manufacturing data model preserves meaning as information moves between systems. Products, batches, work orders, resources, process steps, shifts, tools, materials, quality outcomes, maintenance conditions, production events, and timestamps need managed relationships so teams do not rebuild the same logic every time they investigate a problem.
• Product
• Product family
• Work order
• Batch
• Process step
• Resource
• Machine or asset
• Shift
• Tool
• Material
• Quality result
• Maintenance condition
• Production event
• Time
Definitions also need ownership and versioning. Downtime, scrap, rework, good count, target rate, and changeover duration should not quietly mean different things in different reports. Products change, recipes change, tools change, machines are upgraded, routes change, and approved target rates change. Without versioning, today's process rules can accidentally be applied to historical production data.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.