Bakeries and confectioners sit in an awkward place. They are manufacturers, with bills of materials, yields, batch costs and shift planning. They are also perishable-goods distributors, with shelf life, returns and a delivery window measured in hours. Most software is built for one of those and hopes the other sorts itself out.
We have implemented ERP for businesses in this category, and the pattern of what actually goes wrong is consistent enough to write down.
Recipes are the system of record, or nothing works
In most bakeries the true recipe lives with the head baker and the written one is out of date. Flour is added by feel, a syrup is adjusted for the weather, and the standard batch on paper has not matched the batch on the floor for two years.
Everything downstream depends on fixing this. Ingredient consumption, theoretical versus actual usage, cost per unit and reorder planning are all calculated from the bill of materials. If the recipe in the system is wrong, the ERP will confidently produce wrong numbers faster than the spreadsheet did.
The first workstream in a bakery implementation is therefore not configuration. It is sitting with production and writing down what is actually being made, in what quantity, with what expected yield.
Yield variance is the number that pays for the project
Once recipes are accurate, the system can compare what a batch should have consumed against what it did consume. That single report is usually where the money is.
Dough loss, over-portioning, trim, burnt trays and unrecorded sampling are all invisible in a monthly stock count and obvious in a daily variance report. Most operations we have seen carry a few percentage points of avoidable loss that nobody had a way to observe.
Batch and expiry tracking is not optional
Baking is a food business, which means traceability is a regulatory and reputational question rather than an operational nicety. Every production batch should carry its inputs, its production date and its shelf life, and every delivery should be traceable back to it.
Configure this properly and a customer complaint is a two-minute query. Configure it badly and it is two days of paperwork, at exactly the moment you can least afford the delay.
What to insist on
- Batch numbers generated at production, not written on a clipboard afterwards
- Shelf life derived from the production date, so expiry is calculated rather than typed
- First-expiry-first-out picking enforced by the system, not by the storekeeper's memory
- Full traceability in both directions: batch to customer, and customer back to batch
Returns and waste need a real process
Confectionery and bread go out on sale-or-return more often than not. If returns are handled as an informal credit at the depot, two things happen: revenue is overstated until someone reconciles it, and the waste never gets attributed to the product or the route that caused it.
Treat returns as a transaction. Goods come back into a quarantine location, are dispositioned as resale, discount or waste, and the write-off posts against the route and the product. Then you can answer the question that matters, which is which product on which route is quietly losing money.
Cost per unit, calculated rather than estimated
Ingredient prices in Nigeria move sharply and often. A cost per unit worked out at the start of the year is fiction by the middle of it, and pricing decisions made on that fiction erode margin without anyone seeing it happen.
A properly configured system revalues as purchase prices change, so the cost of a batch reflects what the flour actually cost this month. Combined with yield variance, this is what lets you price with confidence instead of adding a percentage and hoping.
Production planning against real demand
Bakery demand is patterned: weekday versus weekend, month end, festive periods, school terms. Once sales history sits in the same system as production, planning stops being a morning guess and becomes a forecast someone can challenge with evidence.
This is also where the shift and labour conversation becomes possible, because you can see what capacity a given plan actually requires.
The process discipline it all depends on
None of the above is a software feature you can buy your way into. Each one depends on a habit being kept:
- Production is recorded as it happens, not reconstructed at the end of the shift
- Issues to production are booked against the batch, every time
- Returns come back through the system rather than being settled informally
- Recipes are version controlled, and a change is a decision rather than a drift
- Stock counts investigate variance instead of absorbing it
This is why we start every implementation with a structured requirements review rather than a licence quote. In a bakery, the software is rarely the constraint. The constraint is whether the operation is willing to record what it is doing at the moment it does it, and an implementation that does not confront that honestly will produce a very expensive set of numbers nobody trusts.
What a good implementation looks like
Sequence it. Get the recipes right and the stock accurate first, because costing and planning are built on them. Add batch and expiry next, since traceability has an external deadline attached. Bring returns and route profitability in once the basics hold. Trying to do all of it in the first eight weeks is the most common way these projects stall.
Done in that order, a bakery ends up knowing what a unit costs, where the waste is, which route earns its keep and which batch went to which customer. That is a different business from one running on a stock book and a strong memory.