For organisations designing and deploying SAP EWM from the ground up: a new distribution centre, a first true WMS, or a business that has outgrown inventory management. This page walks the build stage by stage, from operating model to hypercare, and answers the questions that come up before anyone signs anything. No legacy rule sets, no morphed workarounds: the floor and the system are designed to agree from day one.
New site · first WMS · clean sheet
The position. A new operation, or a business that has outgrown inventory management and needs a real WMS underneath it. With no legacy to protect, the prize is a rollout where standard SAP EWM carries the load and the operator finishes a shift more confident, not less.
How we work. We design the execution leg from the floor up and close gaps with standard EWM rather than custom code, because the eighty-five per cent that is not your competitive advantage should be the part SAP keeps supporting. Then a senior consultant stays on the floor through go-live and hypercare.
Everything downstream inherits this. Before a single storage type is configured, the operation needs a written answer to how goods arrive, where they wait, how they are put away, how a wave is built, how a pick is confirmed and how a truck is loaded. On a greenfield site those answers do not exist yet, which is the opportunity: nobody has to defend a habit.
We design the execution leg from the floor up, starting with the RF flow the operator will hold in their hand, and work back to the process that flow needs. Standard SAP EWM covers the great majority of what a distribution centre does. The design job is to find the small part it does not and decide, in the open, whether that gap is worth custom code or worth changing the process.
Go deeper · The RF flow is the product · Designing processes for a floor you cannot walk · Embedded or decentralised EWM for a new site · Knauf Pinkenba, designed from a clean sheet
Scope creep on a greenfield build does not look like creep. It looks like sensible requests: one more report, one more exception screen, one more Z program to handle a case that happens twice a year. Each one is defensible on its own. Together they produce a system SAP no longer supports cleanly and an upgrade path that gets more expensive every year.
Our position is that the eighty-five per cent of the warehouse that is not your competitive advantage should run on standard EWM, because that is the part SAP keeps maintaining for you. The remaining part gets argued about properly, with the cost of carrying it for ten years on the table, not just the cost of building it.
Go deeper · Z code is an arrogance tax · What an EWM rollout really costs · The business case for SAP EWM · How long a greenfield build takes
A new warehouse has no master data, and that is a problem disguised as a blank page. Storage types, bins, packaging specifications, product dimensions and weights, handling units, work centres: all of it has to be created, and most of it has to be created before the racking is bolted down, because the racking is what the bins describe.
The failure we see most is ownership. The integrator builds the structures, the business is asked to fill them, and nobody owns whether a pallet of plasterboard actually fits the bin the system thinks it is in. We set the ownership before the build starts, name the person who signs off each data object, and test the data against the physical floor as early as the floor exists.
Go deeper · Master data for a warehouse that does not exist yet
On a greenfield site the operators have often never held a scanner. That changes what testing is for. It is not only proving the system works; it is the first time the people who will run the warehouse see it, and the first impression sets whether they trust it on Monday morning or quietly route around it.
So the test scripts are written from the floor, in the order a shift runs, on the real product, with the people who will do the job. A UAT that passes on the integrator's data with the integrator's staff at the keyboard has proven nothing you need to know.
Go deeper · Readiness is not training · Testing a first WMS · The team a greenfield build needs on your side
Greenfield cutover is different from brownfield: there is no legacy to run in parallel and, usually, no stock to migrate. What there is instead is a building that may still be finishing, stock arriving for the first time, and an opening date that the business has told customers about. The runbook has to cover all three, timed, rehearsed and owned.
We rehearse the cutover end to end before it counts, because every gap found in rehearsal is one not found at three in the morning with a truck at the dock.
Go deeper · Cutover weekend: the runbook decisions · Big bang or phased for a new DC · Standing up EWM alongside the building
Training is where most greenfield budgets are spent last and cut first. A classroom session three weeks before go-live, on a training client that does not match the floor, produces people who can describe the system and cannot run it.
Training on our builds happens on the floor, on the RF device, on the product, on the scenarios that actually occur on a shift, including the exceptions. The measure is not attendance. It is whether a supervisor can take a shift through a full day without calling the project team.
Go deeper · What readiness actually means
Readiness is measured against the floor, not the plan. Four weeks out we want to know that the data is loaded and checked, the labels print, the printers are where the process needs them, the interfaces have been run with real volumes, and the supervisors have run a shift end to end. A go-live gate that only checks the project plan is a formality.
After go-live, a senior consultant stays on the floor through hypercare. The mistakes made in the first weeks, the workaround that becomes a habit, the exception nobody reports, are the ones that show up six months later as labour drift. Catching them early is cheaper than any amount of tuning afterwards.
Go deeper · Hypercare done early · Labour drift: the six-month signals
Greenfield means there is no warehouse system to protect: a new site, or a first real WMS replacing spreadsheets and ERP inventory management. Brownfield means there is a live operation with rules, data and habits that have to be migrated, restructured or unpicked. The work is different, and so is the risk. If the list on the right sounds like you, read the brownfield page instead, or ask us to tell you.
A plasterboard operation moved from no WMS to live SAP EWM (GWMS) with Luminar as the local conduit between the global template and the Queensland floor. Outbound peaks up thirty per cent, no overtime, and no Z-code workarounds.
No legacy rule set to migrate, so the floor process was designed and the template adopted together. The gap-fill solutions built for Pinkenba were taken back into the Knauf global template rather than left as local exceptions.
It depends less on the software than on three things: how settled the warehouse process design is when configuration starts, how early master data is owned and checked against the physical floor, and whether the building and the system are on the same timeline. A single-site build with those three in hand runs in months, not years. The ones that stretch are the ones where design is still moving after build has started.
The licence is rarely the biggest line. Integration effort, the custom code you decide to carry, testing, training and the internal people you have to free up are where the money goes, and the last of those is the one most business cases leave out. We have written up where the money actually lands, and how to build the case, in two field notes linked below.
For a single site on S/4HANA with no need to keep the warehouse running while ERP is down, embedded EWM is usually the simpler answer: one system, one upgrade cycle, no middleware. Decentralised earns its keep when there are several sites, heavy automation, or a hard requirement for the floor to keep moving independently of the ERP. Make the call on operational grounds, not on what the integrator has built most recently.
If the question is about quantity and value, inventory management in ERP answers it. If the question is where a pallet is, who is picking what right now, how a wave is built and how the dock is sequenced, that is warehouse execution, and inventory management does not do it. Plenty of large operations run a billion dollars of stock on inventory management and spreadsheets. It works until it does not.
An owner for the process design who can make decisions, an owner for master data who will sign off each object, supervisors released from the floor for testing and training, and someone senior enough to hold scope when the sensible requests start arriving. The integrator will not do any of those four for you, however good they are.
With no legacy system to run alongside, the usual argument for phasing disappears. What remains is a question about stock and volume: whether the site opens at full throughput on day one or ramps. If it ramps, the go-live can follow the ramp. If customers have been told a date, the cutover has to be rehearsed for that date, and the rehearsal is where you find out whether it holds.
Hypercare, on the floor, for long enough to see the operation settle into its real rhythm. The first weeks are where habits form, and a workaround that becomes a habit is what labour drift looks like six months later. We stay on site through that period and hand over to the supervisors, not to a helpdesk.
One day on site, a plain-language memo in five working days, and a clear read on what a clean-sheet EWM build should look like for your operation.