Multi-plant standardisation fails in one of two directions, and both are expensive. Push too hard and you get a template designed at head office that survives contact with the second plant for about a fortnight, after which every site quietly builds workarounds and the group loses the comparability it was trying to buy. Push too little and you get eleven plants running eleven definitions of dwell, a group scorecard nobody trusts, and no ability to move a practice from the site that solved a problem to the four sites still living with it. The way through is not a compromise between the two — it is a deliberate split. Standardise the event model absolutely, standardise process by parameter, and let genuinely physical differences stay local. The practical ratio from global template work is well established: expect somewhere north of 70% of processes common across sites with 15–30% local variation, and treat any project claiming 100% as one that has not yet met its second plant. Ask for the deployment brief to see the split applied to your own network.
2026 GUIDE · MULTI-PLANT NETWORKS
Standardising Logistics Across Multiple Plants
What must be identical everywhere, what varies by parameter, and what is genuinely local — plus how to choose the model site, sequence the waves, and tell a real constraint from an inherited habit.
Three Buckets, Decided Once
Every element of plant logistics belongs in exactly one of these. The work of a standardisation programme is almost entirely the work of assigning things correctly — and most of the pain comes from items that were put in the wrong bucket at the start and defended there for years.
Core — identical everywhere
Changing this requires group governance, not a site decision
Event names and their meaning
Metric definitions and clock boundaries
Exception codes and severity tiers
Supplier scorecard formula and thresholds
Escalation ladder structure and rung names
EDI message set and validation rules
Master data conventions and naming
Authority tiers — what a system may do unattended
Configured — same logic, local values
Site sets the parameter; the rule itself is common
Tolerance bands and their widths
Dwell and turnaround targets
Slot density and appointment granularity
Priority scoring weights
Maximum hold durations per lane type
Yard utilisation ceilings
Sequence window length
Notification routing and named owners
Local — genuinely site-specific
No group value would be meaningful here
Yard geometry and lane layout
Door count, tiers and eligibility constraints
Gate configuration and lane count
Line-feed method — tugger, AMR, conveyor
Compound location and distance
Shift patterns and local labour agreements
Statutory and regional compliance overlays
Carrier mix and holding-yard availability
The bucket that decides everything
Middle column is where the programme is won. Items pushed left become rigidity that sites route around; items pushed right become the fragmentation you were trying to eliminate. If a rule is the same everywhere but the number is different, it is configured — and treating configured items as local is the single most common reason multi-plant programmes deliver less comparability than promised.
The Common Event Model
This is the part that must be genuinely identical, because everything above it depends on it. Two plants can run entirely different yards and still produce the same events — and if they do, every metric, comparison and cross-site practice transfer becomes possible without touching either plant's physical operation.
← Swipe to see all columns →
| Event | Emitted when | Mandatory fields | Enables |
|---|---|---|---|
| gate.checkin | Barrier crossed, identity confirmed | timestamp · vehicle · carrier · advice ref | Arrival compliance, dwell start |
| yard.assigned | Staging position issued | position · lane type · trailer | Staging discipline, extraction analysis |
| move.completed | Shunt task confirmed by driver | origin · destination · move type · driver | Spotter productivity, empty running |
| dock.spotted | Trailer secured at a door | door · door tier · trailer | Door utilisation, dock-to-line start |
| unload.complete | Physical unload finished | door · quantities · discrepancy flag | Turn time, receipt against a real event |
| exception.raised | Any coded exception detected | code · severity · detection point · owner | Time-to-resolution, supplier attribution |
| part.available | Scanned available at point of consumption | part · location · sequence position | Dock-to-line stop, sequence adherence |
| container.cycled | Returnable despatched full | container id · direction · pool | Container cycle time, pool reconciliation |
Deliberately small. Eight events cover every metric in a plant logistics framework, and a short list is what makes adoption realistic at site eleven as well as site one. Resist the pressure to add events for local nuance — that nuance belongs in the field values, not in new event types, or the model fragments within two waves.
Standardise the events. Let the yards stay different.
The deployment brief covers the event schema, how each event is captured against existing gate, yard, dock and ERP systems, and the configuration surface each site controls locally.
Is This Variation Real?
Every site will produce reasons why the template cannot apply to them. Some are correct. This is the test — the claim on the left, the verdict on the right, and the question that settles it.
"Our yard layout makes single-move extraction impossible"
Real
Geometry is physical. Adjust the parameter, keep the rule, and record the site as a known exception with a target.
"Our carriers won't accept a fifteen-minute window"
Test it
Ask whether the transit times from their origins make the window achievable. If yes, it is a commercial conversation, not a constraint.
"We measure dwell from the gate, not the dock"
Not real
This is a definition, and definitions are core. Both clocks can be captured; only one carries the group name.
"Our line feed is AMR, not tugger, so milk runs don't apply"
Real
Feed method is local. The consumption-triggered replenishment logic above it is not, and should still apply.
"Our suppliers can't send validated despatch advice"
Test it
Usually a subset can and a subset won't. Measure the split — the group standard applies, the transition period is local.
"We've always used our own exception categories"
Not real
Duration is not justification. Map the old categories to the core codes and retain the mapping for historical continuity.
"Local regulation requires a different retention period"
Real
Statutory overlays are local by definition. The core rule sets the minimum; the site can exceed it.
"Our planners need the yard stock counted in coverage"
Not real
That is a symptom of the yard operating as a warehouse. Fix the underlying condition rather than encoding it into the template.
Choosing the Model Site
The template does not have to come from head office, and it usually should not. Model solutions traditionally originated at corporate, but in recent years the pattern has shifted toward selecting a branch site to work out the model and take the first implementation — because a template built by people who will live with it is a template that survives.
1Representative, not exemplaryPick a site with typical constraints rather than your best one. A template built at the easiest plant transfers to nowhere.
2Willing, with capacityThe model site does roughly triple the work of a rollout site. Selecting an unwilling one produces a template built to be argued with.
3Big enough to hit the edge casesSmall sites do not generate enough exception variety to shake out the model. You want the awkward cases surfacing in wave one.
4Not the one in crisisA struggling plant makes a poor model site because every design decision gets entangled with firefighting. Fix it with the template later.
What the Template Actually Contains
A standardised model is a package of artefacts, not a slide deck. If these do not exist as documents, there is no template — there is a first implementation that other sites are being asked to imitate.
Process documentation and configurationThe documented flow of each standardised process together with its system configuration, so a rollout site inherits decisions rather than remaking them.
Organisational structure guidelinesHow a site models itself within the common structure — the shape is given, the local instance is filled in.
Standard reports, forms and interfacesIncluding any functional extensions. Every report rebuilt locally is a definition drifting quietly out of alignment.
Standard roles and authorisationsCommon role definitions, so authority tiers mean the same thing at every site and audit is possible across the network.
Project document templatesUniform documentation and status reporting across all rollout projects. Dull, and the difference between four parallel waves and four separate projects.
The configuration registerEvery parameter a site may set, its permitted range, and who approves anything outside it. This is what keeps configured items from becoming local ones.
Sequencing the Waves
Each wave should prove something specific. If a wave has no proposition to test, it is just more rollout, and it will surface its problems later at higher cost.
Wave 0
Model site buildDesign and implement at the chosen site, producing the artefact package rather than just a working plant.Proves: the model works somewhere real
Wave 1
One deliberately different siteA plant with a materially different yard, feed method or carrier mix. Not the easiest second site — the most instructive one.Proves: the core/configured split is drawn in the right place
Wave 2
Two sites in parallelThe first test of the template as a template rather than as a project. Different teams, same package, minimal central hand-holding.Proves: the artefacts are sufficient without their authors
Wave 3+
Industrialised parallel rolloutMultiple concurrent sites on a repeatable method, with local requirements captured and fed back into the core rather than handled as one-offs.Proves: scalability, and the feedback loop works
Capture local requirements into the core, not around it
Successful multi-country programmes make a point of capturing local and legal requirements so they are picked up in the core solution rather than bolted on at each site. Governance has to strike a deliberate balance between central control and local flexibility — too far either way and you get, respectively, workarounds or fragmentation. A template that never changes after wave zero is not stable; it is being ignored.
Where Standardisation Pays — and Where It Doesn't
An honest ledger. Standardising the wrong things costs real money and buys nothing, and the items in the bottom half are where most over-reach happens.
← Swipe to see all columns →
| Area | Verdict | Reasoning |
|---|---|---|
| Metric and event definitions | Pays heavily | Without it no cross-site comparison is valid and no practice transfer is possible |
| Exception codes and severity | Pays heavily | Enables supplier attribution across the network, which is where the leverage sits |
| EDI message set and validation | Pays heavily | Shared supply base — one integration effort serves every plant that supplier ships to |
| Supplier scorecard mechanics | Pays | A supplier scored differently at each site can dispute all of it credibly |
| Rollout artefacts and method | Pays | The difference between waves and a sequence of unrelated projects |
| Target values and thresholds | Configure, don't standardise | Same rule, different number. Common targets across dissimilar sites get quietly ignored |
| Yard layout and lane design | Does not pay | Physical geometry. A group standard here is a document nobody can comply with |
| Shift patterns and staffing model | Does not pay | Local labour agreements dominate, and the standardisation buys nothing measurable |
| Dock hardware and automation level | Does not pay | Justified by site volume and freight profile, not by network consistency |
The VDA and Odette Layer Is Core, Not Configured
Worth stating separately because it is the clearest case on the whole page. Your supply base is shared — the same supplier ships to several of your plants — so message standardisation is the one area where the network effect is direct and immediate. Our integrations overview covers the wider data surface.
VDA 4987 despatch adviceOne version across the network. A supplier maintaining two despatch advice variants for two of your plants will get one of them wrong, and it will be the plant that shouted less.
VDA 4937 APERAKCommon acknowledgement handling, so "validated" means the same thing everywhere and the exception code for a missing one is identical.
VDA 4902 Odette transport labelSame label version and scan handling. Physical labels travelling between sites is exactly where local variation causes avoidable failures.
VDA 4905 and 4915Delivery schedule and JIT call-off. Common structure, site-specific content — the textbook configured item within a core message standard.
VDA 4945 transport statusShared carrier base means shared status handling. Standardising here removes duplicated integration work per site.
OFTP2 transportOne secure transfer approach across the network rather than per-site arrangements each needing separate maintenance.
Get the Deployment Brief
Covers the common event schema and its capture requirements, the core versus configured versus local allocation, the configuration register format, and the wave method with what each wave should prove. Written for group logistics and enterprise architecture teams running multi-site programmes.
Common event model
Configuration register
Wave sequencing method
VDA / Odette as core
Frequently Asked Questions
How much commonality should we actually expect?
A global template typically achieves upwards of 70% of processes common across sites, with 15–30% local variation — and that variation is legitimate rather than a failure of ambition. Programmes targeting near-total standardisation either exclude the physical layer, where variation is genuine, or they succeed on paper while sites build undocumented workarounds. The number to watch is not the commonality percentage but whether the variation is registered and approved or simply happening.
Should the template come from head office?
Not necessarily, and increasingly not. Model solutions historically came from corporate headquarters, but the pattern has shifted toward selecting a particular branch to work out the model and carry the first implementation. The advantage is credibility — a template authored by a plant that has to live with it tends to survive contact with the second site, whereas one designed centrally often arrives with assumptions nobody on the floor recognises. Choose a representative site rather than an exemplary one.
How do we tell a real constraint from an inherited habit?
Ask whether the claim is about physics or about history. Yard geometry, door count, line-feed method and statutory requirements are physical or legal and belong in the local bucket. Metric definitions, exception codes and message standards are conventions, and "we have always done it this way" is not a constraint on a convention. The useful middle case is the claim that sounds structural but is actually commercial — carrier window tolerance, for instance — which should be tested against transit data before being accepted.
Do all plants need to be on the same ERP release?
No, and designing as though they do is what makes these programmes stall. Because the execution layer integrates with the system of record rather than replacing it, sites can run different ERP versions and still emit an identical event model. That decoupling is what allows plant seven to go live without waiting for a release window, and it is worth protecting explicitly in the architecture rather than assuming it will hold.
What happens when a site needs something the template doesn't cover?
Capture it into the core rather than around it. Successful multi-country programmes deliberately collect local and legal requirements so they are picked up in the core solution, with governance balancing central control against local flexibility. Practically, that means a change request against the template with a named approver, a decision recorded in the configuration register, and the change propagated to sites already live if it applies to them. Bolting the requirement on locally is faster once and expensive forever.
How many sites can run in parallel?
Two in wave two, then as many as your central capacity supports once the artefacts have proven sufficient without their authors present. The constraint is rarely the sites; it is whether the template package is complete enough that a rollout team can work from documents rather than from conversations with the original designers. Industrialised parallel rollout is achievable, but only after a wave has demonstrated the package stands alone. Our analytics and reporting layer is usually the first thing to standardise, since it consumes the event model directly.
What is the first thing to standardise?
Metric definitions and the event model, before any system work at all. They cost nothing but agreement, they immediately make cross-site conversation possible, and they expose which of your existing numbers were never comparable. Sites can continue running exactly as they do today while emitting a common event set — which means you get comparability months before you get process change, and the comparability is what makes the case for the process change.
Standardise the Model, Not the Yard
A common event set and shared definitions everywhere, one configuration register holding the parameters each site sets, genuine physical variation left alone, and waves that each prove something before the next one starts.
Sites may run different ERP releases · No plant relayout required · Site-level configuration
August 12, 2026
By Florain Wirtz
All Articles
