Halving bakery waste by asking for the numbers

Twenty-three shops in one city, and a waste line that had settled at RMB 1.3 million a year. Nobody needed a study to know the number was bad. The number that mattered was smaller and harder: how much of each product should leave the kitchen for each shop, each day.

The operator arrived asking for a better plan. Every previous attempt had pointed at the same place — measure more, count more, control more. The purchase on the table was, in effect, better counting. The engagement ended up spending almost nothing on counting equipment, and the waste line halved.

What it looked like they were buying

A production and delivery discipline. Schedule the ovens better, batch smaller, stop over-sending. This framing is natural because the waste is physically visible at the end of the day: trays of unsold product, counted and written off. A buyer standing in front of that tray will describe the problem in the language of supply.

The framing also survives because it is partly right. There was over-delivery. What it hides is where the number that produces the over-delivery comes from.

Where the money actually leaked

Two lines, not one.

The visible line was unsold product at close of day, written off against head-office gross margin. That arrangement explains why the problem lasted: the cost landed on head office, while the decision that created it was made shop by shop from experience. The shop felt nothing, so nothing at shop level pushed back.

The second line was less visible. A forecast needs a shelf-life window — how long a given product stays sellable under given conditions — and that window existed only as a claim held by experienced staff. Without it expressed as a number, a demand model cannot decide what to send when; it can only reproduce the experience it was handed.

The three maps

These are reconstructed from what the case records about where cost landed and who decided; the engagement did not publish them.

Money. Revenue came from counter sales. The cost of over-delivery was absorbed at head office. One arrangement, and it decides the rest of the project: the person who feels the loss is not the person who sets the number.

Power. Delivery volume was set from experience, and experience is held by people rather than by shops. Shop staff could watch the demand curve daily; the authority to change the volume did not sit with them, which is why any change had to be authorised above the shop floor.

Who loses. The obvious candidate is the experienced person whose judgement was the current system. That skill is real — years of knowing which shop, which day — and a model replacing it removes the visible value of it. In this case nobody blocked the change, and the record is unusually clean: no rework, no interruption, no client walk-back. Treat that as a finding about this customer rather than a rule. When a pass through the three maps turns up nobody who loses, the usual explanation is that the loss sits somewhere the map did not look.

Where the judgement was initially wrong

At the framing, not at the customer. The first read was supply-side; the correct read is demand-side, a forecast per shop per time slot built from three inputs — the footfall curve, the characteristics of the location, and the freshness window.

The second error was hardware. The working assumption was that better counting needs new counting equipment. The shops already had cameras, and those cameras already produced footfall statistics. Nobody had extracted them. The gap was not sensor coverage; it was the distance between what the equipment emitted and what anyone used.

The handbook locates errors of this type in reconnaissance, where the job is to falsify assumptions rather than accumulate information. The two readings produce proposals that look similar on paper and differ by an order of magnitude in cost: one buys equipment, the other asks for a file.

What lived

A per-shop, per-time-slot delivery model that adjusted volume shop by shop, day by day. It lived for a structural reason: it changed one number that a person already had to decide every morning, and left the rest of the workflow alone. The handbook's death-cause index includes "workflow change exceeds benefit"; here the ratio ran the other way, which is why nothing had to be renegotiated with shop staff.

Annual waste fell from RMB 1.3m to RMB 0.6m — about RMB 700,000 a year, roughly RMB 30,000 per shop per year. The measurable form of "lived" here is the four-week rule: still in use four consecutive weeks after go-live, and not switched off afterwards.

What died

One thing: the gut-feel number. There was no failed subsystem to report — no dashboard abandoned in month two, no integration that had to be switched off. The only casualty was a practice.

That is the least transferable feature of this case and should be labelled as such. Most deployments kill something somebody liked, and the killing is where adoption is won or lost. This one removed a habit with no defender, because its cost was booked somewhere else.

One addition is worth flagging precisely because it is small. A handful of low-cost temperature and humidity sensors went in, to turn the freshness window from a claim into a computable range. They were cheap, and they are not where the saving came from. The saving came from a dataset that had been sitting in the shops, unread, for as long as the cameras had been producing it.

The lesson, made operational

When the answer is in data the customer already owns, more hardware is the expensive way to look busy.

The handbook distils a five-step check from this case. It takes half a day to a day:

1. List every device the customer already operates.
2. For each, list what it can emit.
3. Calculate the gap between what is emitted and what is actually used.
4. Rank the gap by frequency and by value.
5. Take the data by asking, before proposing to install anything.

Ending criterion: if the first pass cannot name an installed device that would answer the question, hardware belongs on the table. If it can, hardware is a way of postponing the conversation — and the conversation is the deliverable. Run the five steps before the first prototype, not after the three maps have been drawn into a project plan.