There is a moment in almost every blueprint workshop where someone asks for a Z. A custom screen, a custom table, a custom logic step bolted onto a standard process. It always sounds reasonable in the room. The standard transaction is one field short, or the flow does not match the way the old system worked, so we write a little code to close the gap. Nobody prices what that little code will cost over the next ten years, and that is the problem. Z code is not a one-off line on a build estimate. It is a recurring charge you keep paying long after the consultants have gone home.
Why Z code is a tax you pay forever.
Standard SAP EWM is maintained by SAP. When a support package lands, when an S/4HANA upgrade comes through, when a patch fixes a defect in wave management or in the RF framework, the standard code is regression-tested by SAP before it reaches you. Your Z code is not. Every custom object you own has to be re-tested by your team at every upgrade, every support pack, every patch, because SAP has no idea it exists and takes no responsibility for it. A modification to a standard user exit that was fine in one release can quietly break in the next, and you will only find out when the floor finds out.
The second cost is subtler. Custom code is invisible to SAP's roadmap. When SAP ships a new capability that does the thing your Z was written to do, you do not get it for free. You are now maintaining a private version of a feature that has become standard, and someone has to notice that, argue for retiring the custom object, and pay to unwind it. Most organisations never do. The Z sits there, quietly diverging from the product, for years.
The 85/15 rule and where effort actually belongs.
Roughly eighty-five per cent of any warehouse is not special. Goods receipt, putaway, replenishment, picking, packing, staging, loading: these are solved problems. SAP has spent decades encoding how thousands of warehouses run these processes, and it keeps patching and evolving that code. Running that eighty-five per cent on standard EWM is not a compromise. It is the whole reason you bought a product instead of writing your own.
The other fifteen per cent is where your operation is genuinely different, and where custom effort can be justified. A bonded storage rule no competitor handles, a serialisation requirement tied to a regulator, a slotting logic that protects a throughput number you win contracts on. That is the fifteen per cent worth defending in code. The mistake is spending the custom budget on the eighty-five per cent because it feels quicker in the workshop, and then having nothing left, financially or politically, for the fifteen per cent that actually matters.
What good looks like
A well-run blueprint treats standard as the default and forces every proposed Z to earn its place. The question is never “can we build this?” because in SAP you almost always can. The question is “should this be custom, and what does it cost us every year we own it?” A team that asks the second question ends up with a short, deliberate list of custom objects, each tied to a genuine differentiator, and a large body of process running on code SAP keeps healthy for them.
Real differentiation versus vanity.
The hard part is telling the two apart, because vanity always arrives dressed as necessity. A simple test cuts through most of it. Does a customer ever feel this? Does it protect a margin or a throughput number that no competitor can match? Or is it just how the last system did it, preserved out of habit? If the honest answer to the first two is no, you are not looking at differentiation. You are looking at a preference, and preferences do not deserve a custom object with a ten-year maintenance liability attached.
Real differentiation is usually narrow and specific. It is one rule, one constraint, one piece of logic tied to something commercially real. When someone describes a proposed Z and cannot name the customer who feels it or the number it protects, that is the tell. Standard EWM, configured properly, covers the vast majority of what teams reach for custom code to do. Most of the time the field they think is missing is already there, on a screen variant they have not been shown, or reachable through configuration nobody explored because writing a Z was easier than reading the standard.
The three bad reasons everyone uses.
The first is “we have always done it this way.” This is not a requirement, it is inertia, and it is the single most expensive sentence in a blueprint. A new system is precisely the moment to retire a process that only existed because the old software forced it. Rebuilding the old system's quirks in Z code means you paid for a new platform and kept all the constraints of the old one.
The second is “the standard screen has one field too few.” Sometimes true, rarely worth a custom development once you count the cost. A single missing field almost never justifies owning a Z screen forever. Screen variants, configuration, and a proper look at what standard already offers close most of these gaps without a line of custom code.
The third is the quiet one: the integrator bills more for custom. Custom code is billable hours on the build and billable hours on every upgrade after it. A firm whose revenue depends on the size of the codebase has no incentive to steer you toward standard. That is not a conspiracy, it is just an interest worth naming out loud when you read a design that is heavier on Z than the operation warrants.
Your competitive advantage is about fifteen per cent of the system. The other eighty-five per cent is a solved problem, and every hour you spend re-solving it in custom code is an hour SAP would have maintained for you for free.
The costs nobody prices at blueprint.
Four costs land after go-live, and none of them appear on the build estimate. First, upgrade regression: every custom object has to be re-tested at every upgrade and support pack, and that testing effort scales with the size of your Z footprint, not with the value it delivers. Second, key-person risk: the more custom logic you own, the more your operation depends on the handful of people who understand it.
Third, documentation debt. Custom code is only ever documented as well as the pressure of go-live allowed, which is to say rarely, and the gap between what the code does and what the document says widens every year. Fourth, and most dangerous, the day the one developer who understood the Z leaves. Now you own logic your business depends on that nobody currently working can safely change. That is not a hypothetical. It is the reason plenty of warehouses are running Z code today that no one dares touch.
What to ask a firm that leads with custom.
When a firm reaches for custom development early, put three questions to them. Show me the standard process you rejected, and tell me exactly why it does not fit. What does this Z cost us to own at every upgrade for the next ten years? And if SAP ships this as standard in two releases, what is our plan to retire what you are building now? A firm that leads with code will struggle with the second and third.
A specialist answers differently, because a specialist looks for the standard path first and defends it. The instinct is not “what can we build?” but “what has SAP already solved, and how do we configure our way to it?” The custom list that survives that instinct is short, deliberate, and every item on it earns its maintenance cost. That is not a firm doing less for you. That is a firm handing you a system that stays cheap to own long after the project is closed.