LUMINAR // EXECUTION LAYERFIELD NOTESYSTEM LIVE · BRISBANE
Luminar/Field notes/Hypercare done early
Field note · 04

Hypercare done early.

Hypercare that ends because the calendar says so, not because the floor has stabilised, is the most expensive false economy in a rollout. The bill arrives six months later as labour drift, and by then the people who could have explained it have rolled off to the next project.

An empty warehouse outbound aisle at early-morning shift change, long shadows across the floor and a single forklift parked and still.
Field note Hypercare done early

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.

Who signs the exit, and on what evidence.

The exit should be signed by the person who will own the warehouse once the senior people leave, usually the operations or site manager, and not by the integrator whose milestone payment depends on it. The integrator brings the evidence. The business reads it against the criteria agreed before go-live and decides.

The evidence is a short pack, the same every week: the criteria with this week's number beside each one, the trend since go-live, the open defects with an owner and a date, and a list of the responsibilities that have been handed to the floor team and the ones that have not. If a criterion is not met, the pack says what would meet it and when. A sign-off on that basis takes ten minutes. A sign-off without it is a guess, and the go-live readiness work that came before deserves better than that. It also sets up the next decision, which is who owns EWM in year two.

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 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.

Second OpinionNot sure your hypercare is ending on stability or on a contract date? Get a read before you sign the exit off.

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 exception nobody has seen before 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.

Floor AuditSix months post go-live and the overtime is creeping back? A floor audit will tell you where the drift started.

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.

QuestionsQuestions we get about hypercare
Q. 01

What are hypercare exit criteria?

Measures the floor has to meet before the senior go-live support steps back, each with a number and a threshold: labour per pallet back within an agreed margin of the pre-go-live baseline, peaks running without overtime, operator-reported defects falling week on week, integrator tickets falling rather than flat, and no master data corrections waiting for an owner.

Q. 02

How long should hypercare last after an SAP EWM go-live?

Until the exit criteria are met, not for a fixed number of weeks. Most plans say four to eight weeks because that is what went into the contract. Whatever the estimate, it should cover the first month-end close and the first real peak, because that is where the hard problems surface.

Q. 03

Who should sign off the end of hypercare?

The operations lead who will own the warehouse afterwards, against evidence from the floor. The integrator should present the evidence, but the business signs, because the business carries the cost if hypercare ended too early.

Q. 04

What if the contract date arrives before the criteria are met?

Decide that before go-live, not in week six. The usual answers are a short extension on the responsibilities that have not been handed over, a named person on your side taking each open item, or a support arrangement that starts early. Ending on the date and hoping is the option that shows up later as labour drift.

Part of the go-live seriesHypercare · 7 of 11
Part of the greenfield build seriesAfter · 19 of 21
Part of the wm migration seriesAfter · 13 of 15
Part of the ewm health check seriesRecover · 10 of 13
Second opinion

Catch the drift before it compounds.

The Luminar Floor Audit reads the six-month signals a green go-live hides. One day on your floor, a five-day memo you can take to your integrator, your internal team, or to us.