Ask what an SAP EWM rollout costs and you will get a build number: so many consultant days, so many weeks, a figure with a comfortable contingency on top. That number is real, but it is the part everyone looks at, which is exactly why it is the part least likely to hurt you. The costs that blow a warehouse programme are the ones that do not appear on the quote at all, and they are knowable in advance if you go looking.
The costs you can see.
The visible line items are the easy part of the conversation. SAP licensing or subscription for the EWM footprint. Hardware: the RF devices, the mounted terminals, the label printers and the network to run them, which on a serious operation is not a rounding error. Integrator or consultant fees, usually the largest single line. And the infrastructure to run it, whether that sits in your landscape or a hosted one. None of this is where programmes come undone, because all of it is on the page where the finance team is already looking.
The costs that never make the quote.
This is where the real bill lives, and almost none of it is in the build estimate.
Internal backfill.
Your best operators and supervisors are the ones the rollout needs in workshops, testing and training. While they are doing that, they are not running the floor, and someone has to cover it. That backfill is a real cost, and it is almost never in the vendor number because it is your people, not theirs.
Cutover and training downtime.
Go-live is not free. There is a period where the floor is learning a new system while still expected to ship, and throughput dips before it recovers. Plan for it and it is a managed cost. Ignore it and it becomes overtime, missed dispatches and a customer conversation.
Hypercare.
The weeks after go-live need senior people on the floor, not a ticket queue. Hypercare that is under-scoped to make a build number look sharper is a false economy, because the errors it would have caught turn up later as labour drift and rework, which cost more than the hypercare would have.
The custom-code tax.
Every bespoke object you agree to in the build is a line you will pay again at every upgrade for the life of the system. It is a real cost, it just arrives later. We wrote about why in Z code is an arrogance tax.
Where the money gets wasted.
Cost overruns on EWM programmes are rarely bad luck. They tend to come from the same handful of decisions: custom code where standard would have done, so you pay to build it and then pay to maintain it; junior or generalist consultants learning your operation at your expense; offshore rework, where a cheaper day rate is eaten by the cost of the same problem being solved twice across a time-zone gap; and a compressed readiness line, where the cheapest item to squeeze in the plan becomes the most expensive item in hypercare.
How to read a build estimate.
You do not need to be technical to pressure-test a quote. Ask what proportion of the build is standard SAP EWM versus custom, and why any custom is justified. Ask who is actually named on the engagement, and how senior they are. Ask how hypercare tapers, and against what criteria, rather than on what calendar date. Ask what the estimate assumes about your master data and hardware readiness, because those assumptions are usually where the contingency quietly hides. The answers tell you as much about the firm as the number does.
The cheapest build estimate and the cheapest rollout are rarely the same thing. The gap between them is everything the quote did not mention.
How Luminar approaches cost.
We do not sell you the build, so we have no reason to inflate it or to bury a maintenance liability in it. Our role is to shape the project before delivery: to name the real costs early, to hold standard SAP EWM as the default so you are not paying to rebuild what SAP already maintains, and to give you an honest readiness view so the cheap-to-fix problems are fixed while they are still cheap. The point is not the smallest number on the page. It is the smallest total cost by the time the floor is running.