A global template rollout has a quiet assumption inside it: that the people who built the design will be around when the first shift finds the first problem. In a global template programme landing in Australia, that assumption fails every day of the week, because the build team is in Europe and the floor is not. Hypercare plans written at head office often show a support roster with the right names on it and no honest picture of what time those people are awake.
The clock, done honestly.
Brisbane is UTC+10 all year, with no daylight saving. Germany is UTC+1 in winter and UTC+2 in summer. That puts the gap at nine hours when Germany is on winter time and eight when it is on summer time. Sydney and Melbourne move to daylight saving in the southern summer, which stretches the gap to ten hours to Germany's winter time. The two clocks do not shift on the same dates, so the gap changes twice a year, and a go-live date can land in a stretch where it has just changed.
The practical result is the same everywhere. The Australian morning shift starts while Europe is asleep. The first pick waves are released, the first trucks are at the dock and the first scanner problems turn up in the hours when nobody in the build team is at a desk. The overlap is the Australian late afternoon and evening, which is the European morning. That window is short, it falls at the end of the Australian day when the floor is tired, and it is the only time the two teams can talk live.
Plan hypercare around that shape. Anything that needs the build team, and is not an emergency, will wait until the overlap. So the question for the first shifts is simple: what has to be fixed before the overlap, and who is in the building who can do it?
What fails in the first hours.
The failures that hit a new site early are rarely exotic. They are physical and ordinary, and they are the ones that stop work.
- Labels that print at the wrong size, in the wrong place, or not at all, because a printer queue points at the wrong device.
- Printers that were tested on the day shift in UAT and fail on the first real run.
- RF screens that freeze, time out or drop a session in a dead spot of the building.
- A queue that stops moving, so tasks sit unassigned while operators stand at the rack with nothing to do.
- A delivery that will not post, with a truck waiting at the dock and a driver who has somewhere else to be.
Each of these needs a person who can look at it in the first few minutes. The test for your hypercare plan is to take that list and put a name against every line, for every shift, with a mobile number. If the answer for the early shift is "the build team, when they wake up", the plan has a gap. Our note on what to do when the floor cannot scan goes further into the RF side of this.
Decision rights the local team needs.
Distance turns a technical problem into a permission problem. The local IT lead can usually see what is wrong. What they often cannot do is act, because the template belongs to a global process owner and every change goes through a gate designed for a calmer day than this one.
So settle, in writing and before go-live, what the local team may do without waiting. A workable split looks like this. The local team may restart a stuck process, reprint labels, re-point a printer, reset a device, clear a blocked queue by following the documented steps, and run a manual workaround that has been agreed in advance. They may not change configuration, edit template objects or add custom code. Anything in between is named on a list, with an owner and a time limit for the answer.
The point is to stop an operator standing idle while Europe sleeps because nobody local was sure they were allowed to press a button. A restart that is permitted and documented costs a minute. The same restart held for approval can cost a shift.
A written triage: fix it here or escalate.
When the pressure is on, people decide by instinct, and instinct varies by person and by hour. A one-page triage removes the guessing. It sorts every problem into one of two paths and says what happens next on each.
Fix locally
Problems with a known cause and a documented step: a label reprint, a device reset, a restart, a queue that clears with the standard procedure. The local team fixes it, logs it with the time and what was done, and carries on. No call, no ticket waiting on Europe.
Escalate
Anything that stops outbound or inbound and has no documented fix, anything that touches stock accuracy or financial postings, and anything the local team has tried once and failed. These go to the build team on a defined route, with a clear severity, and the triage names who answers out of hours. A stopped dock is an overnight call. A cosmetic screen issue is not.
Keep the page short enough to read at the dock, and review it with the key users in the week before go-live. A triage nobody has read is no better than none.
The handover in the overlap.
The overlap window is the one live conversation of the day, so it should not be spent discovering what happened. Run it as a handover from a clean list. By the end of the Australian shift, the local lead has a single issues list for the day: what failed, when, what was done, what is still open, and what the build team is being asked to decide or fix.
That list goes to Europe before the call, not during it. Then the call is a decision meeting. The European team arrives in its morning with the list already read, answers the open items, and names who will work on each before the Australian site is next at work. What the build team does in its day becomes what the floor finds working the next morning.
Keep one list and one owner for it. Several lists across several email threads is how an issue gets reported twice and fixed never.
The build team does not need to be awake when the floor starts. The floor needs somebody awake who is allowed to act.
Key users and the workaround list.
Key users on the first shifts are the cheapest cover you can buy. They know the template from training, they know the floor, and they are standing next to the operator when it goes wrong. Put them on the early shift and the late one, not only on days, and make sure each knows the triage page and who to call. Training against real scenarios is what makes this work. At Knauf Pinkenba, key user training ran against real scenarios with the global process owner team, so that trained users could carry the knowledge to the wider user community at go-live. That is the standard to aim for when the experts are far away.
The second discipline is the workaround list. In the first week, the floor will invent ways around problems, and some of them are sensible. A paper step, a manual re-sequence, a spreadsheet beside the scanner. Each one should be written down the day it appears, with who started it, why, and what would remove it. Otherwise the workaround quietly becomes the process, and the next person inherits it without knowing it was meant to be temporary. It is the same pattern we describe in hypercare that ends too early: temporary things that nobody removes. Review the list at each overlap call and close items as fixes land.
When Europe should be on site.
Remote support has limits. Some things are better seen than described, and a design that looks right on a screen in Frankfurt can look different at a dock in Pinkenba. Put build-team people physically on site at the points where seeing the floor changes the outcome: the first live days, the first peak the site experiences, and any week where the issues list stops shrinking. A short visit at the right moment is cheaper than weeks of describing a problem across eight or nine hours.
On site does not have to mean a large team. One or two people who know the design well, standing on the floor with the key users, can settle questions in an hour that would take days by email. Plan the visit at the start, in the budget and the roster, rather than asking for it after something breaks.
When the first week goes well, the work changes character. At Knauf Pinkenba, go-live was supported with quick error resolution, and with only nominal system errors, the team could refocus on small tweaks and operator-driven improvements in the second week of go-live. That is what a hypercare model working properly looks like: the emergencies thin out and the improvements begin. Who owns the system once hypercare ends is a separate decision, covered in who owns EWM in year two. The full story is in the Knauf Pinkenba case study.
If your cutover is still ahead of you, the cutover weekend runbook covers what has to be true before the first shift starts. For the wider gap between a template and a local operation, read global template, local floor.
How Luminar approaches distance.
We are independent and we do not sell the build. We sit on the site's side of the table, in your time zone, and the advice is whatever protects the floor, even when that means asking the programme for permissions, a visit or an extra person. A senior consultant spends a day on your floor, walks the first-hours failure list with your local team, tests the triage against real shifts and the real overlap window, and writes the answer in plain language with the gaps named. You get a memo in five working days, and no proposal is attached.