The go-live went well. The numbers moved the right way through hypercare, the integrator packed up, and everyone moved on to the next thing on the roadmap. Six months later the shift supervisor is asking for overtime again and nobody can explain why. That is the most common shape of an EWM rollout that is quietly regressing, and almost none of it shows up in a status report. Luminar gets called into a lot of these. The pattern is consistent enough to be worth instrumenting so you catch it as a trend, not a crisis. Here are the five signals we look at first.
What labour drift actually is.
Drift is the slow erosion of the gains you booked at go-live once hypercare ends and attention moves elsewhere. It is not a bug, not an outage, not a single bad decision. It is the sum of a hundred small accommodations the floor makes when the system stops matching the way work has changed underneath it.
What makes it dangerous is that it is invisible day to day and obvious in a year. No single shift is bad enough to raise a flag, but stack twelve months of quarter-percent slippage and you are running a warehouse that costs materially more than the business case promised. By the time it is obvious it is a project to fix, not a tweak.
Signal one: labour-per-pallet creeping.
This is the single most honest number you have. Total picking and putaway labour hours divided by pallets moved, tracked weekly. Everything else on this page is a symptom. Labour-per-pallet is the disease, expressed in dollars.
The catch is the one nobody wants to hear. If you did not baseline it in the last clean week of hypercare, you cannot see the drift, because you have nothing to measure the creep against. A number that is 6 percent worse than go-live looks fine in isolation. It only screams once you can lay it next to the day the system was behaving exactly as designed.
Baseline it even if you think it is late
If you are at month five with no baseline, take one now anyway. A late baseline still gives you a slope. You lose the first few months of visibility but gain every month after, and a slope you can see is worth far more than a number you cannot interpret.
Signal two: overtime returning.
Overtime is the pressure-relief valve for a system that has quietly stopped keeping up. It is the first thing a supervisor reaches for when the work is not clearing inside the shift, because it is the lever they control without asking anyone. That is exactly what makes it dangerous as a signal: it hides the problem it is relieving.
It comes back one shift at a time. A Thursday here, a month-end push there, then a standing two hours on the outbound dock because “that is just how busy we are now”. Nobody decided to add overtime back. It accreted, got normalised into the roster, and now reads as capacity rather than the alarm it is. Track overtime as a share of paid hours, weekly, and watch the floor of that line, not the peaks.
Signal three: exceptions that plateau.
A healthy operation sees exceptions fall in the months after go-live. Master data gets cleaned, people stop fat-fingering the same three transactions, and the queue trends down. So a flat line is the tell. If exception volume stops falling around month four and just sits there, it usually does not mean the exceptions were resolved. It means workarounds absorbed them. The stock discrepancy still happens, but the floor has a manual dance that clears it without ever raising a ticket, so the system looks calm while the labour cost of the dance sits off the books.
A rollout is not judged at go-live. It is judged at the one-year mark, and drift is what happens in between when nobody is measuring.
Signal four: workarounds that spread.
Every rollout leaves a few workarounds behind. That is normal. The signal is not their existence, it is their travel. The paper sheet taped to the pack bench, the side spreadsheet a team lead maintains, the night shift that has quietly developed its own way of sequencing putaway. On go-live day there were maybe three of these. The question is how far they have travelled since.
Workarounds spread the way habits spread: by being taught. A new starter learns the paper sheet on day one because it is faster to show than the correct transaction is to explain. Six months on, the paper sheet is the process and the system field it was meant to replace is stale. Walk the floor and count them. If the count is higher than it was at go-live, the system is losing ground to the paper, one bench at a time.
Map where each one lives
Do not just count workarounds, locate them. One confined to an obscure returns process is noise. The same workaround on three benches across two shifts is a design gap the system is not covering, and it will keep spreading until someone closes it in the configuration rather than on paper.
Signal five: tickets shifting from bugs to questions.
Look at the mix of your support tickets, not just the count. Early in a rollout the queue is mostly defects: this transaction errors, that print job fails, this determination picks the wrong bin. As the build stabilises, defects should thin out. What you do not want is the mix sliding toward “how do I”. When tickets move from bugs to basic how-do-I questions, training has decayed. The people who went through go-live enablement have moved on, and the new starters replacing them were never trained on the system, they were trained on the workaround by whoever sat next to them. That is a knowledge problem wearing a support costume, and it feeds every other signal on this page.
How to instrument it cheaply.
None of this needs a business intelligence project. Four of the five signals come from data you already hold: labour-per-pallet is timesheet hours over movement counts, overtime share is payroll, and exception trend and ticket mix come out of the systems that already log them. The only manual input is the workaround walk, one person with a clipboard for an hour a quarter.
Run a quarterly floor check
Put the four numbers on one page and refresh them every quarter, alongside a physical walk of the floor to count and locate workarounds. Fifteen minutes a quarter reviewing a single trend line is the difference between catching drift as a slope you can act on and inheriting it as a crisis you have to fund.
Drift is not a failure of the rollout. It is what happens to any rollout that stops being measured. The operations that hold their go-live gains are not the ones with the cleanest build, they are the ones that kept looking at the numbers after everyone else stopped.