Almost every SAP EWM hypercare plan I have seen ends on a date. Four weeks, six weeks, eight if the sponsor was cautious. The date goes into the statement of work months before anyone has scanned a single live pallet, and then it gets treated as a fact about the warehouse rather than a line in a contract. When the date arrives, the senior people leave, the integrator invoices the final milestone, and everyone agrees the rollout is stable. The trouble is that a rollout is not stable because it is Friday.
The date mistake.
Hypercare exit should be a set of measurable criteria the floor has actually met, not a square on a calendar. Those two things drift apart quietly. A go-live in the first week of the month can look calm simply because volume is light and everyone is still being careful. The date says week six is the finish line, the numbers say nothing of the sort, and nobody stops to check which one is telling the truth. Exit-by-date is comfortable because it needs no argument. Exit-by-criteria is uncomfortable because it can tell you the answer you did not want.
The fix is not complicated, it is just inconvenient. You define what “stable” means in numbers before go-live, you measure against it every week, and you do not release the senior team until the numbers clear the bar. The date becomes an estimate of when that will happen, not the trigger itself.
What proper exit criteria look like
Real exit criteria are boring and specific, which is exactly why they work. Labour-per-pallet back within a defined percentage of the pre-go-live baseline. Outbound peaks running above plan with no overtime propping them up. Operator-reported defects below an agreed count per shift, trending down rather than holding flat. Integrator ticket volume falling week on week, not plateauing. No open master-data corrections sitting in a queue waiting for someone to own them. If you cannot put a number and a threshold on it, it is not an exit criterion, it is a feeling.
Hypercare that ends on a Friday is usually hypercare that ended too early. The floor does not read the project calendar.
Why teams leave anyway.
Everyone knows this, and teams still leave early, for three reasons that all feel reasonable in the room. The first is commercial: the senior resources are expensive and billable elsewhere, and the pressure to release them starts the moment go-live week looks quiet. The second is optimism: a clean first week feels like proof, when it is really just light load and heightened attention. The third is the one that costs the most, and it is a matter of timing. The genuinely hard problems do not surface in week one. They surface at the first month-end close and the first real peak, which almost never fall inside a six-week window.
So the exit is signed off during the calm before the warehouse has been asked a hard question. The first month-end throws up a settlement mismatch nobody rehearsed. The first genuine peak stacks the outbound staging area past what the wave design assumed. By then the people who built the solution are three projects away.
Tapering too fast.
Even teams that hold the exit date sometimes get the shape wrong. They pull the senior floor presence away in one drop instead of tapering it, and the first genuinely novel exception lands on a team that has not yet been trained to own it. There is a difference between an operator who has seen a problem solved and an operator who has solved it themselves under supervision. Hypercare is where you move people across that line, and you can only do it while the exceptions are still arriving.
Taper against handover criteria, not against a date. The senior presence steps back one responsibility at a time, and each step is earned: the floor team demonstrates it can run the wave, clear the exception queue, and handle the month-end tasks without a hand on the shoulder. If they cannot, the senior person stays on that responsibility a little longer. A drop-on-a-date handover assumes readiness. A tapered one proves it.
The baseline nobody captured.
Here is the failure that makes every other one un-winnable to argue. If you did not measure labour-per-pallet and exception rates before go-live, you cannot prove drift afterwards. Six months on, when the overtime bill is climbing, the conversation becomes a contest of anecdotes. Operations says the system is slower. The integrator says operations is not following process. Nobody has a number from before, so nobody can settle it, and the meeting ends with everyone defending their own memory.
Capture the baseline while the old process is still running. Pick a small set of measures you can take cleanly, labour-per-pallet on the busiest outbound line, exceptions per thousand lines, average pick travel, and record them for a couple of representative weeks. It is not a big study. It is the difference between managing drift with evidence and arguing about it without any.
The six-month tell.
Drift announces itself in the same three ways every time, and none of them show up on the go-live dashboard that was signed off as green. Overtime creeps back onto the roster, first on peak days, then on ordinary ones. Workarounds spread: a spreadsheet next to the RF gun, a manual re-sequence at the pack bench, a supervisor who quietly reallocates work the system was meant to direct. And the ticket mix shifts. Early hypercare tickets are bugs. Six-month tickets are how-do-I questions, which means the knowledge that should have been trained into the floor during hypercare never landed, because hypercare ended before the training could be tested against real exceptions.
None of these are dramatic on any single day. That is precisely why they are expensive. By the time the labour number is bad enough to force a review, the drift has been compounding for months and the people who could have named its cause have gone. The cheapest moment to fix all of this was the week you were deciding whether hypercare was really finished.