Continuous improvement workshops that reduce changeover and spoilage

Most breweries don't have a continuous improvement problem. They have a continuity problem. Somebody runs a decent kaizen session, the whiteboard fills up, two things get fixed, and then the next seasonal release swallows everyone's attention and the gains quietly rot. Six months later you're running the same sloppy changeover and tossing the same aging pallet of a slow SKU.

A brewery continuous improvement workshop only earns its keep if it produces something that survives the next three busy weeks. That means it can't be a one-off brainstorm. It has to be a short, structured sprint — with a baseline you actually measured, an experiment you tried, a pilot you scaled, and a routine that forces the change to repeat whether or not the person who ran the workshop is even in the building.

This post lays out a 4-week sprint template built around the two problems that quietly drain the most money in a small brewery: packaging changeover time and spoilage from poor FEFO discipline. The structure matters more than the specific fixes, because the structure is what makes the fixes stick.

Why most CI efforts die in week two

The usual failure isn't a lack of good ideas. Breweries are full of people who know exactly what's wrong — the cellar lead knows which valve configuration eats twenty minutes, the packaging crew knows which SKU order causes three extra rinses, the warehouse person knows which cooler corner always has beer sitting three weeks past its freshness window.

A few patterns come up again and again:

1. 1
   No baseline. People feel like changeover got faster but nobody wrote down what it was before. So when the GM asks if it worked, the answer is a shrug, and the project loses budget.
2. 2
   The fix lives in one person's head. Works brilliantly while the person who designed it is on shift. The moment they take a Friday off, old habits come back.
3. 3
   Too much at once. A workshop generates fourteen improvements. The team tries all fourteen, half-implements twelve, and can't tell which ones actually moved the needle.
4. 4
   No reinforcement. Nobody owns the daily check that confirms the new sequence is still being followed. Drift creeps in over weeks, not days, so no single person notices until it's fully unwound.

The sprint below is designed to close those gaps. One problem per sprint. A hard baseline. One experiment. A pilot you can measure. Then a reinforcement routine that someone owns every single shift.

The 4-week sprint at a glance

Each phase of this sprint exists for a reason. Skipping straight to solutions is the most common mistake — and usually the most expensive one.

The temptation is to compress this into one long meeting. Don't. The weeks aren't padding — each phase catches a different failure mode. Baseline stops you from fooling yourself. Experiment keeps the blast radius small. Pilot exposes the real-world friction. Scale is where you build the reinforcement that most teams skip entirely.

Week 1 — Baseline (measure before you touch anything)

Starting to fix things before you've measured the current state is the single biggest mistake in brewery CI work. You lose the ability to prove anything, and proving it is what keeps the project funded past the honeymoon.

For packaging changeover, your baseline isn't a single number — it's a distribution. Time five to eight real changeovers across different SKU pairs. A 16oz-to-16oz label swap is a completely different animal than a 12oz-can-to-bottle flip. Capture:

1. 1
   Line-down timestamp (last good unit of run A)
2. 2
   Line-up timestamp (first good unit of run B)
3. 3
   Which crew, which shift, which SKU pair
4. 4
   Where the time actually went (rinse, format parts, label setup, waiting on QC sign-off)

Don't average these into one tidy figure. A typical small brewery finds changeovers ranging from around 35 minutes on an easy swap to well over 90 on a format change — and the spread is the real target, because inconsistency is what wrecks your scheduling.

For spoilage / FEFO, the baseline is a short aging audit. Walk the cooler and finished-goods area and record by lot:

1. 1
   Pack date / freshness date
2. 2
   Current days-on-hand vs remaining shelf window
3. 3
   How many cases are already past your internal "sell by" threshold
4. 4
   Which SKUs keep showing up in the danger zone

Spoilage rarely spreads evenly across the whole cooler. It concentrates in two or three slow SKUs and one or two physical spots where older lots get buried behind newer pallets. You usually don't have a brewery-wide FEFO problem. You have a specific-corner-of-the-cooler problem, and naming it precisely is half the battle.

A solid baseline week ends with two documents: a changeover time log with variance noted, and a one-page spoilage audit that says "we wrote off roughly $X last quarter and most of it came from these three SKUs."

Week 2 — Experiment (change one thing, on purpose)

Pick a single hypothesis and test it on a controlled run. Not the whole line. Not every SKU. One change, measured against your baseline.

For changeover, the highest-leverage experiments usually involve doing prep work before the line goes down rather than after. Staging the next SKU's format parts, labels, and date-code setup on a cart while run A is still finishing often cuts dead time significantly — the line comes down and the crew isn't walking to the parts shelf, they're reaching for a staged kit. This parallel-prep idea is covered in depth in our piece on reducing packaging changeover downtime with time-motion checklists, and the sprint is really just a way to make that discipline permanent instead of something that happens on a good day.

For FEFO, a good first experiment is almost embarrassingly low-tech: physically restripe or color-tag lots in one cooler zone so the oldest lot is always the one the picker reaches first, then re-sequence pick instructions to force oldest-first. Run it for one week on your worst-offender SKU and recount the aging audit.

The rule for this week: isolate the variable. If you change the staging cart and re-sequence the SKU order and add a new QC checkpoint all at once, you'll never know which one helped. Pick one. A typical experiment looks like: "staged format kit only, same crew, same SKU pair as three of our baseline runs." That way you can actually compare apples to apples.

Write down the result even if it's ugly. An experiment that saved four minutes instead of the fifteen you hoped for is still data. It tells you the bottleneck is somewhere else.

Week 3 — Pilot (does it survive a normal, messy week?)

An experiment proves a change can work. A pilot proves it works when a keg blows, two people call out, and a distributor moves up a pickup.

In week three you run the change as the default for a full shift cycle — ideally across both your fast and slow crews, because the whole point is finding out whether the improvement depends on your best people. If the staged-cart changeover only works when your most experienced packager runs it, you haven't built a system. You've built a dependency.

During the pilot, keep timing and keep auditing, but also collect friction notes. These are genuinely useful:

1. 1
   "Cart didn't have the right date-code ink for SKU 7."
2. 2
   "Oldest-first pick slowed us down because the old lot was blocked by a pallet."
3. 3
   "QC sign-off is still the bottleneck — line's ready but we wait 12 minutes."

That last one is a classic. You can optimize mechanical changeover beautifully and then lose it all waiting on a quality check or a cleaning cycle. If your changeover improvements keep colliding with cleaning windows, it's worth looking at how those cycles are sequenced — our CIP scheduling SOP that balances cleanliness with throughput gets into how to stop sanitation from becoming the hidden bottleneck behind your changeover gains.

The pilot either confirms the change is robust or surfaces the next constraint. Both outcomes are useful. What you're looking for is a number that holds up under real conditions — not your best-case experiment number, but your Tuesday-in-the-middle-of-a-seasonal-push number.

Week 4 — Scale and reinforce (the part everyone skips)

This is where CI either becomes part of how you operate or quietly dies. Scaling isn't an announcement. It's three concrete things:

1. 1
   Turn the pilot into a templated playbook. One page. The exact sequence, the staging checklist, who does what, and the target time. Laminate it, put it on the line.
2. 2
   Assign a daily owner for the reinforcement check. Someone — usually the shift lead — logs the changeover time and the aging audit count every single shift. Not to punish anyone. To catch drift the week it starts instead of the quarter it starts.
3. 3
   Set a measurable target with a review cadence. "Median changeover under 45 minutes, reviewed at Friday standup." A target without a review date is a wish.

The reinforcement routine is the whole ballgame. Improvements don't fail because the fix was wrong. They fail because nothing forces the fix to repeat. A 90-second daily log tied to a weekly five-minute review is what separates breweries that compound their gains from ones that re-solve the same problem every spring.

A reinforcement checklist that actually holds

1. 1
   [ ] One-page playbook exists and lives at the point of work, not in a shared drive nobody opens
2. 2
   [ ] A named person logs the key metric every shift (time, or aging count)
3. 3
   [ ] The log takes under two minutes or it won't get done
4. 4
   [ ] There's a weekly five-minute review where the number gets looked at out loud
5. 5
   [ ] A drift threshold is defined ("if median changeover creeps above 55 min for three days, we re-run the sprint")
6. 6
   [ ] New hires are trained from the playbook, not from whoever's standing nearby

Here's a quick visual of the reinforcement workflow to pin near the playbook.

Keep this visual near the line so the daily owner can reference it during shift logs.

“

Use a single laminated checkbox line on the playbook for the per-shift log so it truly takes under two minutes.

Scaling isn't done by announcement. It's done by making the pilot the default, giving someone the small, boring job of logging the number, and looking at that number out loud once a week.

A real scenario: a 7,000-bbl brewery and its two worst SKUs

A mid-sized production brewery running roughly 7,000 barrels a year had two chronic leaks. Changeovers on their mixed-pack line were all over the map — anywhere from 40 minutes to nearly two hours, with no one quite sure why. And they were writing off somewhere in the $11k–$14k range per quarter in spoilage, most of it concentrated in two seasonal leftovers and one hazy IPA that aged out fast.

Changeover sprint: Baseline put their median around 72 minutes with brutal variance. The experiment was a staged format-and-label cart prepped before line-down. The pilot ran across both crews for a week. By week four, median landed near 48 minutes — and more importantly, the spread tightened, which let scheduling actually trust the number. The reinforcement was a one-page sequence and a per-shift time log kept by the lead.

FEFO sprint: The aging audit showed roughly 80% of their spoilage dollars sitting in three SKUs stacked in one cooler corner where new pallets kept burying old ones. The experiment was dead simple: a physical oldest-first zone and re-sequenced picks for those three SKUs. After the pilot and a weekly aging count, quarterly write-offs dropped to around $4k–$5k. Not zero, because some slow SKUs are just slow, but a meaningful chunk of cash they stopped throwing away.

The number nobody put in a slide deck but everyone felt: the packaging crew stopped dreading changeover days, because a staged, repeatable sequence is just less stressful than scrambling.

Where this fits — and where it doesn't

When the sprint format makes sense: You have recurring, measurable waste — changeover, spoilage, yield loss — and a team small enough that one owner can actually run the daily check. The 4-week cadence works best when you can protect a little focused attention each week without blowing up production.

When it's a bad idea: Don't run a CI sprint on a process that's about to change structurally anyway. If you're installing a new filler next month, timing your old changeover is wasted effort. Fix the thing that's going to stay.

Who should hold off: If you don't have any reliable way to capture a baseline — no changeover times, no lot dates, no aging visibility — fix that first. A sprint built on a baseline you made up is theater. You need the raw data to exist before you can improve against it.

For a lot of breweries this is where lightweight production and inventory software earns its place: not as the hero of the story, but as the quiet system that makes the baseline log and the daily reinforcement check take thirty seconds instead of ten minutes. If logging the metric is painful, the reinforcement routine dies, and the whole sprint dies with it.

The point isn't the workshop. It's the loop.

A brewery continuous improvement workshop that ends with a whiteboard photo and good intentions is worth almost nothing. One that ends with a measured baseline, a tested change, a one-page playbook, and a named person logging the number every shift — that's an operating habit, and operating habits compound.

Pick one problem. Changeover or spoilage, not both at once. Measure it honestly for a week, test one change, pilot it through a messy week, then make it the default and assign the daily check. Four weeks later you'll have a real number and a routine that protects it. Then do it again on the next problem. That's not a workshop — that's a brewery that gets a little better every month and actually keeps the gains.