A model changeover is not a production event with logistics consequences. It is a logistics event that happens to involve production, and the give-away is where the risk concentrates: not in the days the line is down, but in the six weeks before and the four weeks after. Before, you are burning inventory of parts that will never be used again while still needing enough to build the last unit — and every part you over-order becomes obsolete on a specific date. After, you are ramping on new parts, new containers and new call-offs simultaneously, with suppliers who have had no volume for a fortnight and a yard full of the old pool. In the middle sits the down window, which is simultaneously the only time all year you can install anything at the gate, in the yard or on the dock, and the shortest, most contended resource on the whole programme. This is how to plan the three phases as one flow. See it on your own data against your own changeover calendar.
CHANGEOVER GUIDE · PLANT LOGISTICS
Shutdown and Model Changeover Logistics
Run-out burned to a planned residual, container pools transitioned without a double-pool crisis, install windows allocated before they are contended, and call-offs that survive the silence.
Run-outWeeks · burn down old-part stock
Down windowDays · install everything
Build-outWeeks · new parts, new pools
Most of the cost sits in the two solid bands. Most of the planning attention goes to the gap.
Three Inventory Problems, Not One
The changeover creates three distinct inventory states that overlap in time and are usually managed by different people with no shared plan.
Run-out stock
Parts for the outgoing model, with a hard expiry — the last build. Every unit above the true requirement becomes obsolete on a known date, and every unit below it stops the last build.
Fails asEither a write-off nobody forecast, or a shortage on the final units
Carry-over stock
Parts common to both models. Simple in theory, and the category where packaging or labelling frequently changes even though the part does not.
Fails asCorrect parts arriving in a container the new rack cannot accept
Build-out stock
New-model parts arriving before the line can consume them, against suppliers whose processes have not yet run at volume.
Fails asYard and rack space consumed by parts that cannot be used yet
The overlap is the hard part
For several weeks all three states exist simultaneously in the same yard, on the same racks and through the same doors. Capacity computed for steady-state operation is not capacity for a changeover, and the crunch usually arrives two to three weeks before the down window rather than during it.
Planning the Run-Out
Burning to zero is the wrong target. Burning to a defined residual you have already decided to write off is the right one, because the alternative is stopping the last build to protect a number.
1Fix the final build count firstEverything downstream derives from it. A moving final count makes every run-out calculation obsolete the moment it is made.
2Compute requirement plus scrap allowanceNot requirement alone. Scrap on the last units is real and there is no replenishment behind it.
3Decide the residual you will acceptPer part family, in advance, with a value attached. An unplanned write-off is a surprise; a planned one is a decision.
4Taper call-offs rather than stopping themA cliff-edge cancellation is exactly what the call-off standard handles worst, and it forces the conversation out of the message flow.
5Identify last-time-buy items earlyParts with long lead times or minimum order quantities have to be committed while the final count is still an estimate. Flag them first, not last.
6Plan service-part transfer at the same timeResidual stock destined for aftermarket needs a destination and a transfer order, or it occupies the yard until someone notices.
The crunch arrives before the down window, not during it.
We will run your changeover calendar against your yard, rack and container capacity, and show the week the three inventory states collide.
Container Transition
The most reliably underestimated part of a changeover. For a period, both pools exist — the old one still cycling out with run-out parts, the new one filling to support build-out — and the yard has to hold both while the supply base runs both.
← Swipe to see all columns →
Container quantity per pack almost always changes with a new pool, which means every kanban loop touching that part is mis-sized from the moment the new container arrives. Card counts derive from container quantity, so a pool change is a loop-resizing event whether or not anyone treats it as one. Recalculate before restart, not after the first shortage.
The Install Window Is the Scarcest Resource
Historically the summer shutdown was used to complete the annual model changeover, evolving into a period that also carries maintenance and vacation coverage — and in practice it is now the only block in the year when gate, yard, dock and line-side work can happen without production interference. Everyone knows this, which is precisely the problem.
Competing for the same window
Line-side rack rebuild for the new modelPreventive maintenance deferred all yearGate, barrier and camera installationYard resurfacing, marking and lane changesDock leveler and door workNetwork and handset infrastructureConveyor or tunnel modificationSystem cutover and data migration
How to allocate it
Book external vendors months ahead — shutdown weeks cluster across the industry and vendor schedules fill quicklySequence by dependency, not by requester seniorityAnything that can be done live should be, and should be done before the windowHold explicit contingency days at the end, never at the startName one window owner with authority to refuse late additionsTest the cutover before the window, not inside it
Down windows are getting less predictable
Automakers increasingly flex when down weeks are taken rather than holding a fixed annual pattern — extending closures to combine maintenance, product preparation and inventory alignment in one block, or cancelling a summer shutdown outright to chase volume. Plan the install programme so it can compress or move, because the window you scoped against may not be the window you get.
Call-Offs Across the Break
The changeover is where the quieter properties of the call-off standard become expensive. A schedule that simply stops sending is not a schedule that stopped.
Silence does not cancel
A new call-off replaces the old one, and where no new call-off is transmitted the previous one continues to apply. Going quiet over a shutdown leaves suppliers building to the last schedule they received.
Do insteadTransmit an explicit zero-requirement schedule through the down period
Full cancellation is out of band
Complete cancellation of a delivery call-off cannot be sent by remote data transmission and has to be handled outside the message flow — which at changeover means dozens of parts cancelled by email while systems still show live commitments.
Do insteadRecord each cancellation as an explicit state change with the out-of-band confirmation attached
Cumulative quantities and the reset
Goods receipt cumulatives reset at the start of a new accumulation period, and a changeover frequently sits near that boundary. Two sides resetting on different dates makes every reconciliation meaningless.
Do insteadAgree the reset date per supplier before the run-out, and reconcile before the break rather than after
Restart transmissions carry new identity
Changes go out under a new transmission identification rather than as an update, so a supplier restarting after a fortnight may hold two valid-looking schedules and process the older one.
Do insteadRequire explicit business acknowledgement of the first post-shutdown call-off before shipment
The First Week Back
Restart failures look like supplier failures and usually are not. Everything that was stable before the break is a fortnight out of practice, and several things changed while nobody was watching.
Suppliers restarting coldFirst shipments after a break carry elevated error rates — labels, quantities, sequence — because the process has not run. Tighten inbound verification for the first week deliberately.
Loops sized for the old worldContainer quantity, consumption rate and replenishment time may all have moved. Every loop is unverified until it runs.
Yard holding three generationsRun-out residual, old pool empties and new pool full containers. Positions are tightest in the week the plan assumed they would be freest.
Newly installed systems unproven at rateAnything installed in the window worked in a test, not under a shift. Keep the previous process available for the first days rather than removing it on day one.
Reset the min-max and criticality levelsClose-out is the natural moment to reset stocking parameters from real experience rather than from assumptions carried over from the old model.
Obsolete spares from equipment changeCapital work in the window invalidates legacy components, and a single equipment change can retire an entire set. Review the storeroom against what was actually installed.
What to Measure
Six figures, tracked across the whole changeover rather than by phase. Our analytics and reporting module carries the view.
Run-out residual against planValue of obsolete stock versus the residual you decided to accept. Variance in either direction is a planning miss, not just the overage.
Peak double-pool positionContainer positions occupied by both pools at the crossover. Compare against yard capacity before the date, not on it.
Old-pool recovery rateShare of the outgoing pool physically returned. Un-recovered containers are a cost that surfaces a quarter later as a purchase.
Install window adherenceTasks completed inside the window against those scoped. Overruns cascade into restart directly.
First-week inbound error rateCompared against the pre-shutdown baseline. Isolates restart effects from genuine supplier degradation.
Unacknowledged post-restart call-offsSuppliers who have not confirmed the first new schedule. The cheapest failure to catch and the most damaging to miss.
Plan the Three Phases as One Flow
Bring your changeover calendar, final build count, container pool positions and install scope. We will show the week the three inventory states collide, the peak double-pool date against your yard capacity, and where call-off discipline breaks across the break.
Run-out residual planning
Double-pool modelling
Install window allocation
Call-off continuity
Frequently Asked Questions
When does the changeover crunch actually happen?
Two to three weeks before the down window, not during it. That is when run-out stock, carry-over stock and early build-out deliveries all occupy the same yard, racks and doors simultaneously — while the outgoing container pool is still cycling and the new one is filling. Capacity computed for steady state does not describe this period. Model the overlap explicitly and you will usually find the binding week is one nobody had flagged.
Should we aim to burn run-out stock to zero?
No — aim for a defined residual you have already decided to accept. Zero is achievable only by cutting the safety margin on the final units, where there is no replenishment behind a scrap event and stopping the last build costs far more than the write-off avoided. Decide the residual per part family, attach a value, and get it approved before the run-out starts. A planned write-off is a decision; an unplanned one is a finding.
Why does the container pool cause so much trouble?
Because for several weeks both pools exist at once, and pools do not stretch. The old one is still cycling with run-out parts while the new one fills to support build-out, so yard positions, supplier storage and transport are all carrying double. On top of that, container quantity per pack almost always changes, which mis-sizes every kanban loop touching that part from the moment the new container arrives — card counts derive from container quantity. Model the peak double-pool date and resize the loops before restart.
How should call-offs be handled over the shutdown?
Transmit explicitly rather than going quiet. A new call-off replaces the old one, and where no new call-off is sent the previous one continues to apply — so silence over a shutdown leaves suppliers building to the last schedule they received. Send a zero-requirement schedule through the down period, handle full cancellations out of band but record them as explicit state changes, and require business acknowledgement of the first post-restart call-off before anyone ships against it.
How far ahead should install work be booked?
Months. Shutdown weeks cluster across the industry, so external vendor schedules fill quickly and the more notice you give the more likely a vendor can support you. Beyond booking, sequence the programme by dependency rather than by who asked first, move anything that can be done live to before the window, and hold contingency days at the end. Name one window owner with authority to refuse late additions — without that, the window fills with work that could have happened in March.
Can we rely on the shutdown dates we were given?
Less than you could historically. Automakers increasingly flex when down weeks are taken, extending closures to combine maintenance, product preparation and inventory alignment, or cancelling a summer shutdown entirely to chase volume when demand supports it. Scope the install programme in separable blocks with clear dependencies so it can compress, split or move, rather than as one monolith that only works if the window lands exactly as planned.
What should we tighten in the first week back?
Inbound verification and loop validation. Supplier processes that have not run for a fortnight produce elevated label, quantity and sequence errors on first shipments, and every kanban loop is unverified until it actually cycles under new container quantities and consumption rates. Keep the previous process available alongside anything newly installed rather than switching hard on day one, and treat the first week's error rate as a restart artefact rather than a supplier judgement. Our
integrations overview covers the verification points.
The Window Is Days. The Programme Is Months.
Run-out burned to a planned residual, both container pools modelled at their crossover, install work sequenced by dependency and booked early, call-offs transmitted explicitly across the silence, and a first week back that expects to be different.
Works alongside existing ERP and EDI · No line changes required · Site-level configuration