They Configured a Process Plant. They Never Ran One.

PROCESS MANUFACTURING · ERP IMPLEMENTATION · AUSTRALIAN INDUSTRY

“We need better batch tracking.” “Our recipe management is a mess.” “We can't get a clear picture of what each product actually costs us.”

Walk into almost any mid-market process manufacturer in Australia — a dairy operation in regional Victoria, a food manufacturer in Western Sydney, a chemical blender in South Australia — and some version of these three statements surfaces within the first hour. The follow-up question is always the same: how long has your ERP been live? The answer is rarely six months. It's more often three years. Sometimes five. The system went in, passed go-live, the project manager signed off — and the business has been quietly working around it ever since.

Australian mid-market process manufacturers occupy a difficult space. They are large enough to carry real operational complexity — FSANZ food safety obligations, TGA compliance requirements, EPA reporting, Safe Work Australia obligations — but often too small to attract implementation teams with genuine process manufacturing depth. The result is a generic implementation delivered by competent people who have never had to trace a batch recall across seventeen finished goods before a FSANZ auditor arrives.

Three areas of complexity define the difference between a process manufacturing ERP that works and one the business eventually learns to ignore. They are not obscure edge cases — they are the core of what makes process manufacturing operationally distinct from any other industry.

THE FUNDAMENTAL DIFFERENCE

Why Discrete Logic Fails Process Plants

The table below maps seven dimensions where process and discrete manufacturing diverge — and where that divergence directly drives ERP configuration decisions. Each row is a design choice. Get it wrong, and the business builds a workaround. Get enough of them wrong, and the ERP becomes a compliance artefact rather than an operational system.

This is not a theoretical exercise. A Victorian dairy producer running batch traceability configured for a discrete environment cannot answer a Safe Food Victoria trace query in under four hours. A Queensland food manufacturer whose recipes are managed as static master data cannot demonstrate version-controlled formulation history to an auditor. These are real compliance exposures, not hypothetical risks.

01 · TRACEABILITY

Batch Traceability Is Not a Compliance Checkbox

The real question is not ‘can we trace this batch?’ It is: what happens across the entire production chain when this batch is compromised, and can the business answer that question before the FSANZ auditor needs to leave?

Australia's food safety framework is unambiguous on this. The Food Standards Australia New Zealand Code requires manufacturers to identify and recall affected product rapidly. Safe Food Queensland, PrimeSafe in Victoria, and their state-level equivalents all expect producers to demonstrate traceability capability as a live operational system, not a document. Pharmaceutical manufacturers face TGA audit requirements that assume batch records are system-generated and version-controlled, not assembled retrospectively from spreadsheets.

The design difference that separates a fit-for-purpose implementation from a compliant-looking one is where traceability sits in the system. It must live in the transaction layer, not as a report generated from it. Every goods receipt captures a batch or lot number in real time. Every production order confirmation records which input batches were consumed and in what quantity. Every quality inspection creates a traceability event against a specific batch. That discipline has to be engineered into the implementation from the first configuration session, not retrofitted when the first recall notification arrives.

When traceability is treated as a reporting function, operators learn within weeks of go-live that the system is optional for that step. Batch capture rates deteriorate. By the time a genuine trace event is triggered, a supplier contaminant notification, a FSANZ query, a customer product withdrawal, the data needed to answer the question does not exist in the system the business spent eighteen months implementing.

02 · FORMULATION

Recipe and Formulation Management Is a Moving Target

In discrete manufacturing, a bill of materials is largely stable. Engineering changes occur but are managed through structured change orders with defined approval workflows. In process manufacturing, the equivalent — a recipe or formulation — is in near-constant evolution. This is not a failure of discipline. It reflects the reality of the operating environment.

Ingredient substitutions occur continuously based on supplier availability, seasonal raw material variation, or market price movements. A Victorian dairy processor may substitute one milk powder grade for another mid-production season. A South Australian food manufacturer reformulates when a key flavour ingredient becomes unavailable. The recipe changes. The system needs to know.

Regulatory changes trigger mandatory reformulation, and customer or market specifications add further complexity — a contract manufacturer producing private label product for a major Australian retailer may manage six variants of the same base formulation, one per customer specification, each with its own approved recipe, quality parameters and approved supplier list.

The challenge is not managing one version of a recipe. It is managing the complete version history: understanding which version was active on any given production date, ensuring quality results attach to the correct recipe version, and that cost calculations reflect the formulation actually produced, not the current one.

Generic ERP platforms typically treat recipes as stable, centrally maintained master data, changed through a basic revision mechanism. Australian process manufacturers live in a world of versioned, effective-dated, conditionally approved formulations, where a change requires technical review, quality sign-off, a regulatory check where applicable, and a controlled activation step before production can use the new version.

When recipe management is implemented without this workflow, manufacturers default to workarounds almost immediately: printed recipe books, separate spreadsheets tracking which version was current on which date, new starters following what the physical folder says rather than what the system holds. The ERP becomes a costing and inventory platform, disconnected from what is actually being manufactured.

03 · COSTING

Co-Products and By-Products Are a Costing Blind Spot

This is the most technically underestimated aspect of process manufacturing ERP, and the one most likely to be glossed over with the phrase ‘yes, our system handles that.’ In discrete manufacturing, one production run produces one product; cost in equals cost out, adjusted for labour and overhead. In process manufacturing, a single production process routinely yields multiple outputs simultaneously — and how those outputs are costed determines whether the business has an accurate picture of margin, or an optimistic one.

• Victorian dairy processing: cream separation produces whole milk, skim milk and cream as distinct outputs; cheese production yields cheese as the primary product and whey as a co-product with its own commercial value — if whey isn't costed correctly, cheese cost is overstated and whey margin is invisible
• Queensland sugar milling: crushing and refining yields raw sugar, molasses and bagasse simultaneously; input cost needs allocation across all three based on commercial value and yield, not assigned entirely to raw sugar
• South Australian wine production: pressing yields free-run juice as the primary output and pressings as a secondary output with different quality and value; lees, pomace and tartrate by-products carry disposal costs or recovery value that discrete cost models never account for
• Chemical and specialty manufacturing: reaction processes commonly yield primary products, intermediates used in further production, commercially saleable by-products, and waste streams with EPA disposal obligations — costing any of these incorrectly distorts the margin picture

Most Australian process manufacturers have a rough answer to co-product costing, built on historical averages, management assumptions and periodic cost accounting reviews. What they rarely have is a system that calculates co-product and by-product costs dynamically, at the batch level, reflecting actual yields and actual input costs for each individual production run.

A well-designed implementation models co-product costing at the process level: yield factors captured at production confirmation, not estimated monthly; split cost allocation rules configured to reflect the commercial economics of each output; actual batch costs visible within 24 hours of production completion, not four weeks later when management accounts close.

WHAT FIT-FOR-PURPOSE LOOKS LIKE

Three Requirements, Present From Day One

The difference between a process manufacturing ERP implementation that passes a go-live review and one that genuinely runs the business comes down to the depth of industry understanding in the room when the first configuration decision is made. That understanding cannot be imported at go-live — it has to be present from the start. In practical terms, fit-for-purpose means:

• Traceability as an operational control, embedded in every transaction, delivering full forward-and-backward batch trace within hours — capable of supporting a FSANZ mock recall exercise or a TGA audit without manual reconstruction
• Recipe management as a governed workflow, versioned, effective-dated, approval-controlled and auditable inside the ERP, with production orders locked to the correct approved formulation at the time of manufacture
• Co-product costing at the batch level, with actual yields captured at production confirmation, split cost allocation reflecting real process economics, and product-level margin visible in real time rather than estimated retrospectively

None of this requires a different ERP platform. The capability exists in modern mid-market systems including SAP Business One, when configured by a team that understands the manufacturing reality behind each design decision. The implementation risk is not the software — it is the gap between what an Australian process manufacturer needs and what a generalist implementation team, however technically competent, knows how to configure when they have never stood on a dairy floor, a chemical blending plant, or a food production line.

For process manufacturers currently evaluating, implementing, or reviewing their ERP: which of these three areas has been genuinely designed in your current system — and which has been assumed?

Process Manufacturing  ·  ERP Implementation  ·  ThynkProcess