The email usually arrives as a date and a name. The group SAP EWM template is coming to the Australian site, a build team will visit in a quarter or two, and the local operation is asked to nominate someone for the kickoff. That is a thin brief for a project that will change how every pick, putaway and dispatch is done on your floor. If you are on the receiving end of a global template rollout, the window between that email and the first workshop is the cheapest time you will ever get to influence it.
The build team is not hiding anything. They work from a standard kit and a programme plan, and they assume the local site will tell them what is different. Sites that do not know what to ask for, or what to have ready, spend the first month discovering it in workshops.
The documents to request.
Ask for these in writing, before kickoff. Some will exist only as a slide deck, and that is a useful finding on its own.
What the template covers.
The process scope: which inbound, storage, outbound and inventory processes are in the template, and which are explicitly out. Out of scope is the more important list. Whatever your site does that is not on the in-scope side is either a gap to be designed or a process to be dropped, and you want to know which, early.
How the fit-gap will run.
The plan for the fit-gap or design workshops: how many, how long, who from the site is expected in each, and what the output is. Ask whether the workshops walk the template screen by screen or start from your processes. The first tends to produce a list of differences you spot on the day. The second tends to produce a list you have time to think about.
The floor-facing set.
The RF transaction set, meaning the actual handheld screens and the order a picker or forklift driver moves through them. Ask to see them on a device, not in a document. Alongside it, the hardware and label standard: which scanners and mobile computers are supported, what the label formats and barcode types are, and which printers the template expects. Our note on why the RF flow is the product explains why this is the part your people will judge the whole project by.
The delivery mechanics.
The data conversion approach: which master and stock data the template needs, in what format, who cleans it, and who signs it off. The test scripts, so your key users can see what will be tested and add what is missing. The cutover playbook from a previous site, if there is one, and the hypercare model: who answers a call at the dock on the first Monday, and in which time zone.
The deviation process.
How a local change request is raised, who assesses it, who decides, how long a decision takes and whether the answer can be appealed. If the process exists only as “talk to the project manager”, treat that as a risk and say so. We cover how to run the triage itself in global template, local floor; the point here is to know the door exists, and who holds the key, before you need it.
What the site should prepare.
Asking is half of it. The other half is arriving at the first workshop with facts the build team cannot get anywhere else.
Start with an honest map of how the floor actually runs today. Not the procedure manual, which describes how the work should go. Walk each flow with the people who do it: receiving, putaway, replenishment, picking, packing, dispatch, returns, cycle counts. Write down the workarounds, the paper that moves alongside the system, the whiteboard, the person who just knows. A workaround is usually a requirement nobody has named yet, and the template cannot cover what the workshop never hears.
Then the volumes, by hour and by peak. Daily averages hide the two hours a day when the dock decides whether the shift hits its cut-off. The build team will design for a stated volume; give them the peak and the shape of the day, plus the seasonal spike that comes round every year.
Then the building. The dock doors you actually have, the aisle widths, the ceiling height, the floor loadings, the bays that flood or the lane that cannot be used while a truck is turning. The template was drawn around another building. Yours has its own physical limits, and they are the quickest way to find a process that cannot run as designed.
Then the constraints that are not negotiable: dangerous goods rules, workplace health and safety obligations, customs or export steps, anything a regulator or insurer requires of the site. Check the specifics with the relevant authority or your compliance lead; the job here is to list them so none is first discovered in testing.
And finally, people. Key users are the colleagues who will test, train others and carry the answers on the floor after go-live. A key user who is also running a full roster will give the project their leftover hours, and it shows. Release real time for them now, which usually means backfill, and decide who it is before the build team asks.
The questions about timing.
A build team based in another hemisphere brings its own working day. Ask how much of the Australian day overlaps with theirs, and what that means for a workshop, a defect fix or an urgent call. Ask how long the team will actually be on site, and how much of the design, build and testing happens remotely. A fortnight of workshops followed by months of remote work asks different things of your people than a long on-site stay does.
Ask who is in country after go-live, by name and by week. This is the question most often left until it hurts. If the answer is that support moves to a remote desk in another time zone, plan the first weeks around that. Our note on hypercare when the build team is in Europe goes into what that takes.
The build team brings the template. The site has to bring the questions.
Name one local decision owner.
Every template project produces a steady stream of small local questions. Can we keep this label layout? Which shift tests first? Do we accept this change or ask for an exception? If nobody on the site owns those answers, they travel up and down an email chain until the build team picks the easiest option, which is usually the template as drawn.
Name one person who can say yes or no for the site, has the authority to release key users, and will be at the workshops. That person need not be technical. They need to know the operation and have the standing to stop a decision that would hurt it. When a template assumes a different building, a different labour model or a different hardware estate, someone has to say so plainly and early.
What Knauf showed.
Two details from our Knauf Pinkenba engagement bear on this list. The original hardware estate was not fit for the Knauf global standard and had to be replaced under time pressure. A hardware and label standard in hand before kickoff turns that from a scramble into a line in the plan.
The other is the brief. It started narrow: change management, readiness, translating the template for the people who had to live with it. As the build moved on and gaps emerged, the role grew into full responsibility for the EWM stream. Few sites can predict where their gaps will appear. What a site can do is make sure it has a local voice with the authority to act when they do.
How Luminar approaches the lead-in.
We are independent and we do not sell the build. That lets us read the template pack for your site alone, not for the programme's schedule. A senior consultant spends a day on your floor, maps how it really runs with your shift leads, and writes a plain-language memo within five working days: which documents to chase, which differences are likely to matter, and who on your side should own the answers. No proposal is attached. You can take the memo to your build team, your integrator or your own board, whether or not you ever talk to us again.