How to run an implementation that lands in weeks instead of dragging into an eight-month ordeal — phasing the rollout around your highest-pain workflow, running your old system in parallel until the numbers reconcile, and training the floor before the switch — so the day you go live is a quiet Tuesday, not a crisis.
Chef Diego runs a real food plant. If this page didn't get you there, tell us — a person reads every message.
After this lesson you can run an implementation that lands in weeks instead of
dragging into an eight-month ordeal — because you go live on one workflow at a
time, keep your old system running until the new one's numbers reconcile, and put
the floor through training before the switch rather than after. Done this way, the
day you change systems is a quiet Tuesday your team barely notices, not a crisis it
has to survive.
Why a rollout becomes a nightmare
The horror stories are real, and they rhyme. An onboarding quoted in weeks that
stretches into eight months. A go-live where nobody could trust the inventory
counts because practice data got mixed into the real numbers. Support that, when
the thing didn't fit, told you to figure it out yourself. A rep who demoed well and
never once understood how your operation actually runs. These are not bad luck.
Each one traces back to a choice made at the very start of the rollout, and each
has a defense you can put in place before you begin.
Four traps account for most of it:
Big-bang scope. Trying to switch everything — purchasing, receiving,
production, inventory, sales — on a single day. Every part leans on every other,
so one problem stalls the whole thing, and the go-live date keeps sliding while
the pressure climbs.
The floor was never part of it. The system was chosen and set up in the
office, and the people who actually receive, weigh, and pack were handed a new
screen on the morning it went live. The first busy hour, they reach back for the
paper sheet, and now you are running two systems by accident.
Test data bled into the real numbers. During setup, someone practiced with
made-up receipts and batches to learn the system, and those practice entries were
never cleaned out. The live inventory count is wrong from hour one, and no one can
tell which numbers are real.
The rep didn't know your business. They configured it the way it works for a
generic warehouse, not a food operation with lots, expiry, and QA holds — and
when it didn't fit the way you actually work, the help you got was thin.
The rest of this lesson is the four defenses, in the order you put them in place.
Go live on one workflow first
The single biggest change you can make is to stop treating the rollout as one event.
Instead of switching everything at once, run a . The first stage is the whole game.
Pick the workflow that hurts most to go first. You already found it: the worst seam
on the data-flow map you drew in the last lesson — the place your team wastes the
most time re-keying, or fumbles the most numbers, or gets stopped cold when it
breaks. Maybe that is receiving into inventory, maybe it is batch records that tie
lots together, maybe it is a trace you cannot run fast enough. Whatever eats the most
pain, make it the first phase, end to end, and let everything else wait.
Scoping the first phase this narrowly is what makes the timeline honest. A single
workflow can be configured, tested against your real scenarios, and switched on in
weeks. It is the everything-at-once plan that stretches to months, because there is
no point at which any of it is done until all of it is. So when a vendor lays out a
timeline, hold it to this shape: ask what the very first workflow to go live is, and
when. A well-scoped first phase measured in weeks is a fair bar to hold anyone to. A
plan that only produces something usable after months of full configuration is the
exact shape that becomes the nightmare.
Each phase also teaches you how the next one will go. The first
is where you learn what your
team stumbles on, what the vendor is slow to answer, and how long the reconciling
really takes — all on your smallest, most contained bite, where a mistake costs the
least.
Run the old system in parallel until it reconciles
Do not shut the old system off the day the new one turns on. Keep it running for the
workflow you just switched, doing the work in both places for a while. This overlap
is a , and it is the difference
between a rough patch and a real shortage on a real order.
While you run parallel, the old system is still your source of truth and the new one
is on probation. Each cycle, you : does the new inventory count match what is
actually on the shelf, does the batch that ran show the right lots consumed, does the
order that shipped draw down the right stock. When a number disagrees, you find out
why — a miskeyed unit, a step the floor skipped, a setup mistake — and you fix it
while the old system still has the right answer sitting right next to it.
That side-by-side check is also your protection against the corrupted go-live. If
practice data or a configuration error left the new count wrong, parallel running
catches it before it costs you, because the truth is right there to compare against.
Two rules make that protection hold: keep every practice and training entry out of
your live data — learn on a test copy, never on your real inventory — and do not cut
the old system off on faith. You cut over when the numbers have agreed for a full
cycle of your work, whatever a cycle is for you — a full week, a full production run,
a full order-to-ship — and when the floor reaches for the new system first without
being told to. Loading clean opening balances and open lots so the new system starts
from the truth is its own careful job, and it is the next lesson.
Train the floor before go-live, not after
Adoption is not a memo sent the morning of the switch. The people who do the work
learn the new system before it goes live, on their own real tasks, on the one
workflow that is going live — the receiver receiving, the batch lead running a batch,
the shipper picking an order, all on the test copy, before it counts. A generic tour
of every screen teaches them nothing; running their own job in the new system teaches
them everything.
Buy-in comes from two places, and you can build both. The first is being part of the
choice — the requirements list you circulated back at the start of this course was
the floor telling you what the system had to do, and a team that helped pick a tool
defends it instead of dodging it. The second is the first phase being a genuine
relief rather than one more chore stacked on the job. Choose the highest-pain
workflow to go first for exactly this reason: the floor feels the win in the same
week, and a system that made a bad day better sells itself. The lesson on
getting the floor to actually adopt a system
goes deeper on how habits change on a working line.
One more thing carries a go-live: name a person on the floor who has learned the new
system well enough to answer the small questions in the first days — where does this
go, what do I do when the scale reads short, why won't it let me ship this lot. That
is the help a rep who does not know your operation can never give you, and having it
in the room is often what keeps the paper sheet in the drawer.
A calm go-live, and what you carry in
Put the four defenses together and the nightmare has nowhere to start. One workflow
goes live, not the whole operation. It is the one that hurt the most, so the win is
immediate. The old system runs alongside it until the numbers reconcile for a full
cycle, so a wrong count is caught instead of shipped. And the floor trained on it
before the switch, so the new screen is familiar the first busy hour. That is a
go-live that feels like a quiet Tuesday. Then you add the next phase the same way,
and the one after that, each easier than the last because you have done it before.
One thing decides whether even a well-phased go-live starts clean or starts crooked:
the data you carry into the new system. Duplicate items, units that do not match,
opening balances that never tied out, open lots you cannot account for — bring those
in untouched and you have built the new system on sand, no matter how careful the
rollout. How to move your items, recipes, lots, and balances in cleanly, and how to
keep a way back if the load goes wrong, is the next lesson.
