2019–2021live, five years in production

Where a food producer’s numbers begin

A food manufacturer ran its production on a spreadsheet — one so large, so slow and so old that the specification for replacing it was, in effect, a copy of the spreadsheet. I built the system that replaced it: capture on the plant floor, the production calculations, and the integration that lands the result in the financial system.

role: solo, end to end
build: two and a half years
in production: five years
sector: food manufacturing

// the problem

Production was run on a spreadsheet. A very large one — slow, and understood in full by almost nobody. Updating a production run was a long manual process, and the result was then re-keyed into SAP by hand: two manual steps, each with its own opportunities to be wrong, sitting directly upstream of the financials.

It also made new people expensive. Onboarding meant learning the internal logic of a spreadsheet, because that was where the knowledge lived — not in documentation, and not in anybody’s head in a form they could hand over.

For scale: this is a business turning over billions of rand a year, running multiple products across several different types of production run. The system does not produce that; operations do. What it does is record and calculate the production runs those numbers are built from. Cost of sales, indirect costs and wastage all trace back to a run captured in it, because this is a production business and that is where its accounting starts.

// the decision I’d defend

There was no real-time instrumentation. Every number in those financials begins with a person typing on a plant floor.

That single fact decides where the engineering effort belongs. If capture is wrong, nothing downstream can rescue it — you cannot audit your way out of bad source data, and a reporting layer built on it is just a faster route to the wrong answer.

So the work went into structure, validation and workflow at the point of entry: making the correct entry the easy one and the incorrect one difficult, across multiple products and several types of production run.

That also means the workflow has to match how the plant genuinely operates rather than how a process document says it does. Get that wrong and the operators work around the system — and once they are working around it, the numbers it produces are fiction, however elegant the reports look.

// what I built

Capture for the operators, covering multiple products and several types of production run, designed around the reality that the plant floor — not a sensor — is the source.
Every production calculation, plus the schemas, workflows and front-end flows underneath them.
The integration into SAP, which removed the manual re-keying. An integration engine already existed, but each integration still had to be written: it resolves to an API call, and what matters is populating that call correctly — which is where the accounting logic actually sits.
The reporting the office side works from, so analysts and finance take their numbers out of the system or out of SAP rather than reconstructing them.

// what changed

The spreadsheet is gone, and with it the second manual step — production no longer gets typed twice on its way to the financials.
Onboarding stopped meaning “learn this spreadsheet”. The process is in a system with defined structures and workflows, so it can be taught rather than absorbed.
Five years in production. It has run the production operation of the plant, largely automatically, since it went live — which for a solo build is the outcome I am most pleased with.

// what I didn’t decide, and what I couldn’t choose

I did not define what should be measured. A business at that scale arrives knowing what it wants, with a large team to substantiate it. They specified the operational system and the reporting; I defined the structures, schemas, workflows, interfaces and every calculation that made it real.
The absence of real-time measurement was not my call. I designed around it rather than solving it — instrumenting a processing plant is a capital project, not a software one.
I could not pick the stack. The in-house platform it had to be built on meant SQL and only SQL, which shaped everything about how it was written.

// what it actually took

Two and a half years of development, QA and UAT, and a great many hours of calls. The specification documents were enormous and close to unreadable, for the honest reason that they were largely a transcription of the old spreadsheet. A meaningful part of the job was working out what the spreadsheet actually did before anything could replace it.

The platform constraint made it stranger still: every piece of logic lives in SQL — stored procedures, functions and triggers. No packages, no libraries, no editor tooling worth the name, and this was before any of it could be handed to an AI. Getting object-like structure out of procedures and triggers took a certain amount of creativity.

Mostly, though, it took persistence. Getting a two-and-a-half-year project through the door is a different skill from building it, and it is the one people underestimate.