Four EWM Gaps Every Manufacturing Plant Will Hit — And Why Standard Config Won't Fix Them

A Blueprint Gap Confirmation session last month surfaced four process gaps in an automotive components manufacturer's S/4 EWM deployment. None of them are exotic edge cases. Every manufacturing warehouse with racking, a supermarket area, and production supply will run into some or all of these problems. The reason they keep appearing isn't poor planning — it's that standard EWM is designed for a perfect warehouse with perfect boxes, perfect quantities, and predictable flows. Real plants are none of those things.

GAP 1: Height Check in Putaway & Replenishment

EWM knows what type of handling unit you have but will cheerfully assign it to a rack location without checking if the load physically fits the height clearance. It's like a car park system that checks your ticket but never measures whether your van will fit on the low-ceiling floor.

The obvious fix — mapping HU types to height classes — doesn't survive contact with reality. The same HU type carries wildly different load heights depending on what's packed inside. You'd need perfect master data discipline across every single packaging material, which never holds in practice.

The real fix: A BAdI that reads the actual packaging material dimensions at warehouse task creation time and checks them against a bin height field in the storage bin master data. No operator UI needed at go-live — a simple maintainable table works fine initially. Roughly 5–8 days of ABAP development. The real risk isn't IT, it's getting the plant to collect and maintain bin height data consistently.

GAP 2: Return Flow of Partial Boxes from Production

When production only uses part of a box, the remainder needs to come back to the supermarket. But EWM's standard model treats production order position confirmation as "fully consumed" — it deletes the HU and posts goods issue automatically. The physical remainder becomes a ghost: real stock with no system representation.

Here's the thing: you don't need to build a complex return flow if you reframe the problem. Instead of "take the whole box and bring back what's left," make it "pick what you actually need." If the operator only picks the quantity required, the remainder never leaves EWM stock in the first place. No custom return flow needed.

This only works if the plant process supports partial picking. That needs validating with the plant immediately, not assumed in the design room. If they can't change the process, you're back to needing a BAdI to intercept the auto-PGI job, and the timeline tightens.

GAP 3: Kitting Process for Component Supply

The plant supplies production through kitting — assembling sets of components with variable quantities per production order. EWM has no standard kitting process. An external system currently does this job, completely disconnected from EWM.

The proposal on the table was to build an ABAP report that generates warehouse tasks based on production demand. That works for creating the tasks, but you lose kit completion visibility, exception handling, and any sensible operator interaction for variable quantities.

Go-live recommendation: Defer. The solution hadn't been fully designed at the point of the session. Keep the external system running in parallel initially. This is the anchor gap for a longer-term BTP solution — more on that below.

GAP 4: Component Rework and Return to Supermarket

Defective parts go to a recovery zone where they're physically reworked to extract a reusable component, which then returns to the supermarket rack. EWM can handle the movements but has no concept of the transformation step — the material changes during rework, and EWM can't represent that natively.

The cleanest approach: a PP rework order handles the material transformation (defective component in, usable part out), and EWM handles the putaway back to supermarket as a normal replenishment. But that requires PP team involvement and clarifying whether defect identification lives in QM, PP, or just on paper.

Go-live recommendation: Defer or manual workaround. Short term, someone manually changes the stock type after physical rework, then a standard warehouse task handles the return movement.

The Reuse Case That Changes the Business Case

All four gaps share the same infrastructure needs: warehouse operator interaction, EWM API calls, and a confirmation/scan flow. That means the CAP backend and EWM API connectivity gets built once and reused across all modules.

More importantly — these aren't site-specific problems. Height constraints, partial returns, kitting, and rework loops are standard manufacturing warehouse operations. Any multi-site manufacturer running S/4 EWM will hit the same gaps.

That reframes the business case entirely. Instead of justifying one app for one plant, you're justifying a reusable group-wide asset. Each new plant onboards through configuration, not a new build. The development cost gets amortized across potentially dozens of plants globally.

Key Takeaways

• EWM's gaps aren't bugs — they're design assumptions that don't survive contact with real manufacturing variability
• The temptation to solve everything through configuration always breaks against variable real-world data
• The right go-live scope is ruthless: only what's stable and low-risk ships first, everything else defers to Phase 2
• The strongest argument for BTP isn't technical — it's the multi-site reuse case

The partial pick reframe for the return flow is the most elegant insight here: solve returns by never needing a return in the first place. Sometimes the best custom development is the one you don't build.

---

Running into similar gaps on your EWM rollout? I'd be interested to hear what you're seeing — markus-mildner.com

#SAPEWM #S4HANA #SAPBTP #WarehouseManagement #SupplyChain #Manufacturing #SAPConsulting #SAPCommunity #DigitalTransformation #Logistics #ProcessImprovement #SAPFiori #AutomotiveManufacturing #LessonsLearned #SAPImplementation