Continuous Improvement Runs on Batch-Level KPIs

Most food and beverage plants have some form of continuous improvement program. Lean, Six Sigma, kaizen events, daily huddles with a board full of metrics. The intent is always the same: find where the process can be better, make a change, confirm it worked and keep it that way.

What often holds these programs back isn’t the method or the people. It’s the resolution of the data. Improvement happens batch by batch, but the numbers usually arrive as weekly or monthly averages.

The problem with averages

A monthly yield of 94% looks like a single, stable number. Underneath it, individual batches might range from 89% to 97%. That spread is exactly where the improvement opportunity is, and the average hides it completely.

Averages also make changes slow to evaluate. If a team adjusts a setting in the second week of the month, the effect is diluted by everything before it and everything else that changed in the meantime. It can take two or three months before anyone is confident whether the change helped, and by then the team has moved on to the next project.

Continuous improvement needs to see each batch, not just the month.

What a per-batch KPI looks like

A per-batch view gives every batch its own scorecard. Total duration, and how long each phase took. Yield and losses. Water, steam and energy used. Quality results. Any deviations or holds.

Just as important is the context attached to each batch: which product, which line, which shift, which raw material lot, which piece of equipment. Without that context, a list of batch results is hard to interpret. With it, patterns start to emerge on their own.

Most of this information already exists in the PLC and the systems around it. The step sequence, the timings, the temperatures and flows, the product code. What’s usually missing is the step that turns those signals into one row per batch, calculated the same way every time, without someone building it in a spreadsheet.

Finding where to improve

Once every batch has a scorecard, the first useful exercise is simply sorting them.

Compare the best quarter of batches with the worst quarter for the same product. Where do they differ? Often the difference is concentrated in one phase, one product or one set of conditions. That turns a broad goal like “improve yield” into something specific, like “reduce losses during the transfer phase on product B.”

The best batches also set a realistic target. The process has already achieved those results under real conditions, with the same equipment and the same team. Closing part of the gap between the typical batch and the best batch is usually far more achievable than chasing a theoretical number from a spec sheet.

Testing changes in days, not months

Per-batch data changes how quickly improvement ideas can be tested.

Here’s an example drawn from a few cultured dairy operations. A continuous improvement team suspected that fermentation time could be shortened by adjusting inoculation temperature slightly. Under a monthly reporting view, testing that idea would have meant changing the setting and waiting for the averages to move.

With per-batch KPIs, the team ran the change on a set of batches and compared them directly with similar batches from the weeks before: same product, same tanks, similar milk composition. After about 40 batches over two weeks, the result was clear. Fermentation time dropped by around 25 minutes per batch, with no change in final pH or texture results. The decision to adopt it was made with evidence rather than a feeling.

That speed matters. When each improvement cycle takes two weeks instead of three months, a team can test many more ideas in a year, and the ones that don’t work get dropped quickly instead of lingering.

Holding the gains

One of the hardest parts of continuous improvement is keeping an improvement in place. A change gets made, results improve, the project closes, and six months later the process has quietly drifted back to where it was.

Per-batch KPIs make that drift visible early. In the same example, a few months after the change, fermentation times on one shift started creeping back up. The batch data showed that inoculation temperature on that shift had gradually returned to the old setting. It was caught within days, while it was still a small adjustment rather than a lost improvement.

Once an improvement is confirmed, it becomes the new baseline. Future batches are compared against it, so any slide back shows up as a deviation rather than going unnoticed.

Making it part of the routine

Batch-level KPIs work best when they become part of the regular rhythm of the plant rather than a separate analysis project.

A weekly improvement meeting can look at the distribution of batches instead of an average: how wide was the spread this week, which were the three worst batches and what did they have in common, which was the best batch and what was different about it. That last question is often the most productive, and it gives operators recognition for good runs rather than only reviewing problems.

Over time, the team builds a shared understanding of what drives good and bad batches, grounded in data rather than memory.

A few things to watch for

Too many KPIs dilute attention. Three to five per batch is usually enough to start, chosen because they connect directly to cost, capacity or quality.

Comparisons need to be fair. Batches of different products, sizes or recipes shouldn’t be ranked against each other without accounting for those differences.

And not every variation is a signal. Every process has natural batch-to-batch variation. Knowing how wide that normal range is helps the team avoid reacting to noise and focus on the differences that are real.

‍