Somewhere in the build of a global template rollout a local team finds something the template does not do. The argument that follows is usually about whether to change the template. The better question is what happens to the fix after the site goes live, because that decides who pays for it for the next ten years.
Our earlier note on global template, local floor covered the principle: raise a genuine gap properly and feed the answer back up. This one is the practical version, for the person who has to do it.
Three ways a gap can end.
The first is a local-only deviation. Your site configures around the template, the change works, and from then on every support pack, upgrade and regression test has to carry it. Nobody else runs it, so nobody else maintains it. It survives for as long as one person at your site remembers why it exists.
The second is custom code. Our note on the Z code tax covers the cost, so here is the short form: you now own a programme the template team has never seen, and your site will be the one that breaks first on an upgrade.
The third is a change the global template absorbs. The fix is designed once, built in standard, and written into the template so the next country inherits it as a tested answer instead of a surprise. It is the best outcome for the group and for your site, because your fix becomes someone else's maintenance burden. It is also the hardest to get, and the rest of this note is about why.
A fix the template can absorb.
Knauf's Pinkenba plasterboard operation in Brisbane is the clearest example we can point to. During the build, gaps showed up between the group's GWMS template and Australian operational reality. Two were significant: goods receipt from manufacturing, and outbound shipping. Both were closed with standard SAP EWM functionality and no Z code. The solutions designed for Pinkenba were then adopted into the Knauf global template for future implementations, and the global process owner team called it the most successful GWMS rollout to date. The full account is on the Knauf Pinkenba case study.
Look at what those two gaps have in common. Both sit at the edges of the building, where the production line hands over to the warehouse and where the warehouse hands over to the truck. Those edges differ between countries more than the middle of the warehouse does, which is why a template written around one country's handovers tends to miss on another's. And both were solved in a way that a different plant, in a different country, could pick up. That is the property to design for from the first workshop.
Prove it is a requirement, not a habit.
The global team has heard “we need a change” many times and most of those requests were preferences. Your first job is to show yours is different, and the test is simple. Name the constraint: a law, a safety rule, a physical fact about the building, a customer contract. Then show what happens on the floor if the template stands as it is. A pallet that cannot be received. A truck that cannot be loaded. A document that cannot be produced.
If the honest answer is “the old system did it that way” or “the supervisors prefer it”, it is a habit. Concede it early. That costs you nothing and it buys credibility for the one you need to win. Where the constraint is regulatory, treat the rule as something to confirm with the relevant authority and put the confirmation in the paperwork, not as something your team remembers.
Our note on what a global template misses in Australia is a good place to check your list against before you raise anything.
Solve it in standard, so it can travel.
A template team can only take on what it can support everywhere. Custom code fails that test on sight. A fix built from standard SAP EWM functionality passes it, because the group already maintains that functionality at every site. The same fix that is a risk to your site as a Z code is an asset to the template as configuration.
Design for the second country while you build for the first. Ask what is specific to your site and what is general to the problem. Your dock numbers, your product codes and your shift pattern are local. The shape of the handover is general. Keep site facts in master data and parameters, and keep the logic free of them. A fix with your site hard-wired into it can only ever be a local fix.
Write it up in the template's own language.
A global team will not absorb something described in your site's vocabulary. Package it the way they package their own work. That means four things, whatever their documents are called.
The process.
What happens on the floor, step by step, in the terms the template already uses for its processes, and where the change sits against them.
The configuration.
Exactly what was set up, in enough detail that a consultant in another country can reproduce it without calling you.
The test script.
How anyone proves it works. A fix that arrives with its own test is far easier to accept than one that has to be reverse engineered.
The effect on other sites.
This is the section most local teams skip, and it is the one the template owner reads first. Does the change alter anything a site already live on the template depends on? If it is optional, how is it switched on? If the answer is “no effect”, say how you know.
A fix the template owner can read, test and switch off is a fix they can say yes to.
Find the owner and bring floor evidence.
Most template organisations have a global process owner for each process area, and a change board or equivalent that sits over them. Find out who owns the process your gap touches before you write anything. Raising it with the wrong person, or only through the project's status report, is how good requests die quietly.
Bring evidence from the floor, not an opinion. Photographs of the handover area. The volumes through it. The document the regulator or the customer actually requires. A short walk through the process with the build team standing where the work happens does more than a slide. Someone who has watched the plasterboard come off the line understands the gap faster than someone who has read about it.
This is where a local conduit earns the role. Someone who speaks both languages can put the floor fact in front of the template owner in a form they can act on.
Time it against the release cycle.
Templates change on a calendar. There are release windows, freeze periods and test cycles, and a change that arrives just after a freeze waits for the next one. Ask early when the template next opens for change, and plan your go-live around the answer. If your date comes first, you may have to run a documented local solution for a period and migrate to the template version when it lands. That is a legitimate path, provided the local solution was built in standard and recorded as temporary from the start.
Be honest about the order of events. A fix raised after your go-live has lost its best argument, which is that the site is still being built and nothing has to be unpicked.
What gets a yes, and what gets a no.
From the template owner's chair, the pattern is consistent. They say yes to a constraint they can verify, a fix built in standard, a clear statement of what changes for other sites, and a test they can run. They say yes more readily when the request arrives with a named person who will answer questions.
They say no to custom code, to a request that cannot say which other sites it affects, to a fix hard-wired to one building, and to a problem described as a complaint instead of a design option. They also say no, reasonably, when the same request comes from the same site for the sixth time that month. Pick the changes that matter and let the rest go.
Some fixes should stay local.
Not every gap belongs in the template. A rule that exists only because of one state's regulation, one customer's contract or one building's geometry may be right to keep local. The test is whether a second site would ever want it. If the honest answer is no, a documented local configuration in standard is a sound result, and trying to push it into the template wastes everyone's goodwill.
Whatever you keep local, record it. A deviation written down in the right place, with an owner and the reason, is a decision. An unwritten one is a fault waiting for the next upgrade.
How Luminar approaches the hand-up.
We are independent and we do not sell the build. That lets us say plainly when a local gap should go up to the template, when it should stay local, and when it is a habit. On a template rollout we sit between the build team and the floor, sort the gaps into those three, and where a fix can travel we design and document it so the template team can take it. That is the work that was adopted into the Knauf template.
If you want that read before you raise anything, the Floor Audit is one senior consultant on your floor for a day, and a plain-language memo in five working days listing which of your gaps are requirements. No proposal attached.