Skip to content

Modernisation playbook

How to modernise a meat wholesale business with controlled operational change.

A phased plan for orders, stock, traceability, weight and invoicing, with a parallel-run worksheet to check the evidence before cutover.

Test the plan against your operation

Published 28 August 2026 · Reviewed 31 August 2026

Jump to the parallel-run worksheet

Modernisation is not the act of replacing a spreadsheet or buying an ERP. It is the work of deciding how the operation should run, which records people can trust and how a change will be proved safe before it carries real orders, stock or invoices.

For a meat wholesaler, those decisions cross commercial and physical work. Customer prices, lots, catch weight, production, labels, delivery evidence and final invoice values have to agree. A phased plan keeps that dependency visible instead of moving a large, poorly understood process into a new screen.

Map the current operation

Start with records, decisions and hand-offs.

Do not begin with a list of software features. Walk through what actually happens, including work performed in inboxes, notebooks, labels, scales and conversations that never reach the current system.

Order capture

Questions to answer

Where does the order arrive, who rekeys it, which price applies and how are shortages or substitutions agreed?

Evidence to preserve

Original order, confirmed lines, customer price source, changes and owner.

Stock and allocation

Questions to answer

Which lots are available, held or committed, and when does allocation become operationally binding?

Evidence to preserve

Lot balance, status, location, expiry, allocation and release decision.

Production and weight

Questions to answer

What is transformed or weighed, which inputs were used and how does actual weight change the commercial record?

Evidence to preserve

Input lots, output identity, target and actual weight, tolerances and operator or device provenance.

Dispatch and delivery

Questions to answer

What was loaded, who accepted it, and how are failed or partial deliveries represented?

Evidence to preserve

Run, vehicle or driver assignment, dispatch lines, delivery result and POD where required.

Invoice and control

Questions to answer

Which final quantities and prices are fixed when issued, and how are credits, approvals and exports handled?

Evidence to preserve

Invoice-ready source, approval, snapshot, exception and downstream finance hand-off.

A seven-phase plan

Make each expansion earn the next one.

A useful phase is small enough to understand but important enough to prove. It should have a clear owner, acceptance evidence and a safe fallback.

  1. 1

    Write down the current operation

    Follow several representative orders from receipt to invoice. Include a normal order, a variable-weight order, a shortage, a product substitution, a held lot and a failed delivery. Record every hand-off, rekey and informal decision.

  2. 2

    Choose the first control boundary

    Select a bounded workflow where better information would remove meaningful risk or repeated work. Define where the new process starts and stops, which existing system remains authoritative and what must not change yet.

  3. 3

    Prepare the master data

    Agree stable identifiers and ownership for customers, delivery addresses, products, units, price agreements, suppliers, lots, shelf life, allergens and weight rules. Do not hide unresolved meanings inside a bulk import.

  4. 4

    Configure representative exceptions

    Build and test the awkward cases before the happy path becomes familiar. A system that handles one clean demo order has not proved it can support the operation on a difficult morning.

  5. 5

    Rehearse with disposable data

    Run the workflow using anonymised or synthetic records first. Confirm roles, labels, outputs, reports, integrations and recovery steps without placing live stock, invoices or customer commitments at risk.

  6. 6

    Run a controlled parallel period

    Process a small number of real orders in the existing process and the new one. Reconcile lines, prices, lots, inputs, outputs, actual weights, delivery evidence and invoice values before expanding scope.

  7. 7

    Make expansion conditional

    Move to the next workflow only when acceptance evidence is complete, users know the fallback, open exceptions have owners and the business can explain which record is authoritative at every stage.

Master data

Resolve meaning before moving rows.

Data migration is not complete because a file imported. A product can have a code and still be unusable if nobody agrees its unit, pack definition, weight behaviour, shelf life, allergen information or label rule.

Give each data group an owner. Record ambiguous values, decide whether blanks mean unknown, not applicable or inherited, and test the result in the workflow that consumes it.

Use the ERP evaluation scorecard

Minimum questions for each imported field

  • What does the value mean operationally?
  • Who owns and approves changes to it?
  • Which current record is authoritative?
  • Can a blank, zero or duplicate be legitimate?
  • Which workflow, label, report or calculation consumes it?
  • How will the imported result be reconciled and accepted?

Parallel acceptance

Reconcile real work before cutover.

A parallel run is useful only when both versions of the same work are compared. Choose a small set of representative orders and agree the expected evidence before processing them.

Differences are not automatically defects. They are prompts to establish whether the old process, the new process or the underlying data is wrong. Resolve and record each difference rather than forcing the totals to match.

Acceptance checklist

  1. 1.Every customer, product, unit and price used in the trial has an agreed source and owner.
  2. 2.Opening stock and lot identities reconcile to the accepted baseline.
  3. 3.A representative order can be followed from capture through invoice-ready evidence.
  4. 4.Variable-weight lines preserve target, actual, tolerance and commercial calculation context.
  5. 5.A source lot can be followed to affected stock, production or dispatch records, and the exercise can be reversed.
  6. 6.Held or quarantined stock cannot silently enter normal allocation or dispatch.
  7. 7.Shortages, substitutions, partial deliveries and credits have explicit states and owners.
  8. 8.Labels, scales, printers and integrations used in the phase have been tested with the physical equipment involved.
  9. 9.Users have rehearsed the fallback and know who decides whether the phase continues, pauses or rolls back.
  10. 10.The final comparison is recorded and signed off rather than accepted from memory.

Parallel-run worksheet

Matching totals can hide two wrong lines.

Use the same representative order in both records, then compare each line against independently checked evidence. Do not assume the old system is right, or approve the new one because the order total agrees. This worksheet is an operator-led test method, not a claim that Larder automatically performs reconciliation.

1. Agree the trial boundary

Record the date, trial owner, reviewer, included workflows and the system that remains authoritative. Start with synthetic data. During any approved live shadow run, prevent the second record from issuing customer documents, changing stock, printing production labels or triggering payments or accounting exports. Include only actions explicitly approved for that phase.

Agree how to stop and resume the existing process before starting. Keep held-stock and interruption tests in a safe rehearsal, not an experiment that can release real product or interrupt a busy station.

2. Copy these four blocks for every trial line

Use them as column groups in your own trial log. Keep original exports or screenshots with the record; redact customer details before sharing outside the business. Mark excluded steps as “not tested”.

Identity and meaning
Trial ID; order and line references in both systems; customer and delivery address; product code; ordered, stock and selling units; pack definition; agreed price source and effective date. Write down whether weight determines the charge or is recorded for another purpose.
Quantity, weight and value
Requested quantity; target weight; accepted actual net weight; tare basis; scale or manual-entry reference; operator and time; permitted tolerance and review decision; chargeable quantity; price unit; rate; rounding rule; expected and observed line values. Keep tax, delivery charges and discounts separate.
Lot and physical evidence
Supplier and receipt reference; source lot; any split or output lot; quantity by lot; hold status; label version; dispatch reference where in scope. Check the physical identity as well as the screen. Matching money does not prove the right batch was selected.
Difference and decision
Expected result and its source; result in each system; difference; explanation; evidence reference; responsible owner; correction; retest result; reviewer and date; pass, pause or not tested. An empty result is not a pass.

3. Check the line calculation

Synthetic example, not customer data or Larder output. Both lines are fully supplied. Prices exclude tax, delivery charges and discounts; line values are rounded to two decimal places. “Expected” comes from the agreed selling unit, price and accepted quantity, not a copied legacy total.

One order, two errors, the same £127.40 total
Agreed basisExpectedShadow resultDifference
A · Sold by kilogram12 kg target; 11.60 kg actual; £6.50/kg£75.40£78.00+£2.60
B · Sold by each4 items; 3.80 kg recorded; £13.00/each£52.00£49.40−£2.60
Order total£127.40£127.40£0.00

Scroll the table sideways to compare all four columns.

Line A should be 11.60 × £6.50 = £75.40. The shadow record used the 12 kg target. Line B should be 4 × £13.00 = £52.00. The shadow record multiplied 3.80 kg by a per-item rate. The £2.60 differences cancel, but neither line passes. Recording a weight does not make every product a per-kilogram sale.

Repeat with your actual unit and pack definitions. For a case-priced product, establish what one case contains; do not silently treat cases, pieces and kilograms as interchangeable. Separately verify tax treatment, charges and rounding with your finance owner.

4. Pause, correct and retest

  • Pause expansion for an unexplained price or unit difference, missing lot link, wrong label, duplicate write or held stock passing a release check. Preserve both results before correcting anything.
  • In a safe rehearsal, interrupt one capture or hand-off and retry it. Check that there is one accepted result, no duplicate stock or commercial effect, and a clear way for the operator to recover.
  • Resolve the cause with the data or workflow owner. Retest the failed line and another affected example; do not overwrite the evidence or widen tolerances just to obtain a pass.
  • Record the reviewer, evidence references, remaining exclusions and next approved scope. A scale-only pass does not approve labels, stock, dispatch or invoicing. Physical equipment and any required verification remain separate acceptance gates.

If a trial reveals a real food-safety concern, stop treating it as a test discrepancy and follow your incident procedure and the relevant authority’s guidance. This worksheet does not replace that response.

Measure the operating change

Track a small baseline before promising improvement.

Choose measures that expose the reason for the project. Record the baseline consistently, define the denominator and keep improvements separate from seasonal or volume changes.

Order handling

Time from receipt to confirmed order, rekeys per order, pricing queries and unresolved shortages.

Stock confidence

Unexplained adjustments, allocation failures, held-stock breaches and lot discrepancies.

Weight and margin

Lines awaiting actual weight, tolerance exceptions, invoice corrections and value lost between expected and invoiced quantity.

Traceability

Time to complete a forward and backward exercise, missing links and records that require manual reconstruction.

Delivery and finance

Failed-delivery resolution time, missing evidence, credits and time from dispatch to an approved invoice record.

Common failure modes

Avoid the shortcuts that move risk downstream.

Starting with every department

A broad programme creates dependencies faster than the team can validate them. Start with a bounded operational slice and an explicit interface to what remains unchanged.

Treating the legacy system as automatically correct

Old records may contain conventions, workarounds and stale values. Preserve them as evidence, then verify their meaning with the people and workflows that use them.

Testing only clean transactions

Shortages, holds, substitutions, weight exceptions and failed deliveries reveal whether ownership and recovery are designed or improvised.

Using training as acceptance

Knowing where to click does not prove that prices, lots, labels, weights and invoice values reconcile. Keep training and operational acceptance as separate gates.

Cutting over without a fallback

Define how work continues if a device, integration, connection or process fails, and rehearse who can pause or roll back the phase.

Promising savings without a baseline

Record the current delays, errors and corrections first. Otherwise the project can feel better while the business remains unable to show what changed.

Primary sources and control context

The modernisation method above is Larder's operating framework. These primary sources provide context for traceability, food-safety management and cloud-provider assessment. Check the latest requirements for your location and operation. The linked FSA incident page covers England, Wales and Northern Ireland and points Scottish operators to Food Standards Scotland. Sources checked 31 August 2026; the worked example is synthetic and the worksheet is Larder's own method, not an authority-approved form.

Turn the framework into a plan for your operation.

Tell us which workflow creates the most risk or repeated work. We will separate what Larder supports now, what needs configuration and what would require implementation work.

Talk through your operation