A food and beverage producer. Three legal entities, 140 staff, one production site, supplying two national retail chains and 312 independent stores. Turnover had tripled in six years. The systems had not changed since the first year of it.
There were five of them: an accounting package, a standalone stock system, recipes and yields in Excel, a homegrown dispatch tool somebody's cousin built in Access, and a shared drive holding everything else. Month-end took eleven working days, and the number it produced was argued about for two more.
It is the longest project in this series, because ERP always is. Nine months, phased, with production running throughout.
Why food is not like other manufacturing
Generic ERP advice falls apart in food and beverage, because five things are true here that are not true in most factories.
- Stock expires. Allocation has to be first-expired-first-out, and stock value is a function of remaining shelf life, not just quantity.
- Traceability is a legal and commercial necessity. You must be able to go from a raw material lot to every pallet that left the building, in both directions, quickly.
- Recipes do not yield what they say. Actual yield varies by batch, by raw material quality and by operator. An ERP that treats a bill of materials as fixed will report margins that are politely fictional.
- Retailers deduct rather than dispute. Rebates, listing fees, promotional support and claims arrive as deductions on a remittance months later. If the system cannot accrue them against the sale, the margin you reported was never real.
- Seasonality moves everything. Raw material pricing, demand and cash all swing on a calendar the system has to understand.
Most failed ERP projects in food did not fail on the finance module. They failed because nobody modelled yield variance, shelf life or retailer deductions, and the business went live with numbers it trusted less than the spreadsheets it replaced.
What we did, and the order we did it in
A mid-market ERP, implemented in four phases with a live production line throughout. Two peripheral systems were kept and integrated rather than replaced, which is often the right answer and rarely the one the vendor proposes.
| Phase | Scope | Why here |
|---|---|---|
| 1. Finance | General ledger, debtors, creditors, all three entities, inter-company | Everything else posts into it. Going live at the start of a financial year meant one clean set of opening balances. |
| 2. Inventory and production | Item master, recipes, batches, yields, warehouse locations, FEFO | The heaviest data work and the biggest behaviour change, given its own runway. |
| 3. Sales and distribution | Pricing, orders, retailer EDI, dispatch, proof of delivery | Depends on stock being right, so it could not come earlier. |
| 4. Trading terms and analytics | Rebate and claim accruals, customer profitability, production dashboards | Only meaningful once three phases of real data exist. |
Phase it, and let each phase settle
A big-bang ERP go-live puts finance, production, warehouse and sales through their worst week simultaneously, with nowhere to fall back to. Phasing costs more in integration and takes longer on paper, but each group learns while the others are still stable, and a problem in one area does not stop the business. Every phase here had at least four weeks of quiet before the next one started.
Nine months, in order
| Months | Phase | What actually happened |
|---|---|---|
| 1 | Select, honestly | Three products, scripted demos using their own recipes, their own retailer deductions and their own worst month-end. Not the vendor's demo data. |
| 1–3 | Item master | 2,300 item codes rationalised to 1,450. Units of measure, pack configurations and catch weights standardised. The single longest task in the project. |
| 2–4 | Finance build and go-live | Chart of accounts rebuilt to report by entity and by product family. Live on the first day of the financial year. |
| 4–6 | Inventory and production | Recipes verified on the floor rather than from the spreadsheet. Eleven were wrong. Batch and lot structures set up for two-way traceability. |
| 6–8 | Sales and distribution | Retailer EDI mapped and tested with both chains, which took twice as long as planned and always does. |
| 8–9 | Trading terms and analytics | Rebate accruals modelled per customer agreement, then customer profitability reported for the first time. |
| Throughout | Parallel month-end | Two month-ends run in both old and new systems, deliberately. Painful, and the reason the third one was believed. |
The data, which was most of the work
Sixty percent of the effort went into data, which is normal and almost never budgeted for. The item master was rationalised with the sales team in the room, because half the duplicates existed for reasons that turned out to be commercial rather than technical. Recipes were checked against what production actually did, not what the spreadsheet said. Customer trading terms, which had been living in signed agreements in a filing cabinet, were captured as structured data for the first time, which is how the rebate accrual became possible at all.
Opening balances were reconciled twice, and stock was counted physically the weekend before the inventory go-live. There is no shortcut through this part, and every attempt to find one shows up later as a number nobody trusts.
Training, by department, because they are not the same
- Finance got depth. Three days plus a sandbox they could break for a month. They were also the group most attached to their spreadsheets, and the way through that was to rebuild their two most-loved reports inside the system before go-live rather than after.
- Production got brevity. Twenty minutes per person at the station, on the two screens they use. Nobody on a factory floor needs to know what a journal is.
- Warehouse got their scanners and a fortnight of dual running, with FEFO enforced from day one rather than phased in politely.
- Sales got the customer view and, more importantly, the pricing rules. Every argument about pricing that had previously been settled by a person was now settled by configuration, and that had to be agreed before go-live, not discovered after.
- Super-users were named per department and given time in their week for it. That last part is what makes a super-user real rather than an honorary title.
What it cost
| Line | Once-off | Notes |
|---|---|---|
| Implementation partner | R1,442,000 | Four phases, configuration, testing, go-live support |
| Data preparation and migration | R376,500 | Item master, recipes, balances, trading terms |
| Integrations | R288,400 | Retailer EDI, payroll, the two systems that were kept |
| Hardware, scanners, terminals | R163,700 | Warehouse and production floor |
| Training and parallel running | R207,900 | Including two duplicated month-ends |
| Contingency, largely used | R318,200 | EDI, and a fourth entity discovered mid-project |
| Total once-off | R2,796,700 | Across nine months |
| Licences and support | R61,800 / month | Thirty full users, forty light users, hosting, support |
For scale: a ten-user distributor on a cloud package lands under R500,000, and a multi-site group with heavy customisation lands in the tens of millions. Treat any ERP quote without a data-migration line as incomplete.
What changed, measured
- Month-end went from eleven working days to four, and the number stopped being debated.
- A traceability query went from a day and a half to under ten minutes, tested in a mock recall the quality manager ran unannounced.
- Yield variance became visible per production run, and two products turned out to be running consistently below their assumed yield. Repricing one of them recovered more margin in a year than the software licences cost.
- Retailer deductions stopped being surprises. Accrued against the sale, they moved from an unpleasant discovery to a forecast, and R412,000 of invalid claims were successfully challenged in the first year because the supporting data existed.
- Stock write-offs from expiry fell by 38% once FEFO allocation was enforced by the system rather than by whoever was picking.
- Customer profitability was reported for the first time, and one large account turned out to be marginal after rebates and delivery costs. That conversation happened with evidence.
What we would do differently
We would finish the item master before the build started, not alongside it. Every phase inherited that decision, and the inventory phase in particular would have been three weeks shorter.
We would start EDI mapping in month one. It has the longest external lead time of anything in an ERP project, depends on other people's schedules, and always slips.
We would also insist on the fourth month-end being parallel too. Two was enough to be technically correct and one short of being emotionally convincing, and the finance team spent an extra month checking things by hand that were already right.
If an ERP is on your table
Two honest tests before you sign anything. First, can you name the three questions the business currently cannot answer? If not, you are buying software rather than solving a problem. Second, script the demos with your own worst-case data: your messiest recipe, your most complicated customer agreement, your ugliest month-end. Vendors demo beautifully on their own data, and almost all of the risk lives in yours. And be genuinely open to the answer being integrate what you already own, which is cheaper, faster and right more often than the industry likes to admit.
