Clean Core in SAP EWM – Modernize warehouses without dismantling the standard
Logistics departments are under immense pressure: more and more locations, growing shipment volumes, increasing automation rates – and yet projects are expected to be implemented faster, more securely, and more cost-effectively. At the heart of the matter is an uncomfortable question: How can SAP EWM be extended in such a way that business units remain flexible without releases, migrations, and maintenance spiraling out of control? The answer? Clean Core.
Many SAP customers have customized their EWM systems extensively over the years – with custom code, special logic, and isolated workarounds. What was pragmatic back then now blocks any modernization.
The clean-core approach addresses this very point: It consistently separates a stable core system from specifically designed extensions.
Looking back: How EWM solutions became complex, unique products
Historically, SAP EWM was often implemented with one clear goal: to make the warehouse operate exactly as the organization was used to. The standard was the foundation; everything else was customized to fit.
Over the years, typical patterns have crept into many EWM systems: old user exits, direct modifications to the standard, copied SAP programs with custom adaptations, fixed values in the code for specific warehouses or customers, and custom-built interfaces without a clear concept. This was usually well-intentioned and pragmatic: the main thing was to get it going live, to make the special cases work, to make the warehouse function. In the short term, this approach worked perfectly in many projects.
With some distance, however, the disadvantages become apparent. Every change to the system can trigger something unexpected because no one knows exactly where all the modifications were made. If performance drops or the system becomes unstable, troubleshooting is tedious. Cloud or S/4HANA projects become significantly more complex and expensive because this web of customizations must first be analyzed, evaluated, and thoroughly cleaned up. The flexibility of the past has now become a technical burden, hindering further development.
What Clean Core in SAP EWM really means
Clean Core doesn't mean that extensions are no longer allowed. It means that the SAP standard is maintained and only supplemented where absolutely necessary. In SAP EWM, the most important processes such as goods receipt, putaway, replenishment, picking, and goods issue should continue to be based on the standard EWM functions and strategies.
If you deviate from this, the reason should be clear, and it should be well-documented so that you can understand what was changed later. Custom logic isn't simply "built in" anywhere, but rather integrated through the designated points in the system.
This includes, for example, BAdIs in the EWM process, official interfaces, CDS views, and services for evaluations and integrations. Custom functions are packaged into clean ABAP classes and not hidden in legacy FORM routines. This keeps the code clear and makes it easier to find, test, and modify as needed.
Functions that don't necessarily need to run directly within EWM should be outsourced, for example to the SAP Business Technology Platform. Dashboards, control centers, planning and optimization logic, or specialized apps for inventory and quality assurance can be implemented there. This keeps the core EWM system leaner and more stable, while allowing new ideas to be tested and further developed in a separate environment.
Clean Code in ABAP: Craftsmanship for a stable EWM core
A clean core stands or falls on the quality of the custom code. If the individual code is messy, slow, or has grown organically over time, even the best architectural diagram is useless.
Good ABAP code goes far beyond simply "running without errors." It should be understandable, easy to maintain, and not slow down the systems.
Clearly named objects instead of guesswork: Variables, methods, and classes should clearly indicate their purpose. lv_target_bin_id says significantly more than lv_x1, zcl_ewm_putaway_decision explains more than zcl_helper. Anyone reading the code must be able to recognize the underlying technical task without guesswork.
Small, manageable methods: Methods that record goods receipts, create warehouse tasks, print labels, and log errors are difficult to maintain. Clean EWM extensions consist of compact methods with exactly one task, clearly described inputs and return values, and a central helper logic that is reused multiple times instead of being copied.
Configuration instead of hardcoding: Fixed values in the code are a frequent cause of later problems. Customizing tables and configuration objects, control via parameters per site or process, and storing threshold values in a central configuration are preferable. This way, adjustments remain in the customizing settings and don't end up in the development environment.
Comments with added value: Comments should provide background information, not recite the source code line by line. Helpful are explanations of the technical reasoning behind certain decisions, so that even a new team member can understand why a particular logic was implemented in a certain way.
Uniform style and modular design: A consistent programming style is not an end in itself. Uniform conventions facilitate reviews, onboarding, and collaboration. Typical EWM tasks should be encapsulated, for example, searching for and checking handling units, creating and posting warehouse tasks, or centralized error and log handling. Instead of repeatedly rebuilding this logic, it is implemented cleanly in one place and reused.
Clean Core depending on the operating model
SAP S/4HANA Cloud, Public Edition
In the public cloud, a clean core is not optional, but mandatory. Modifications to the standard are not permitted; extensions are implemented via in-app extensibility and true side-by-side applications. EWM processes must be designed from the outset to function within this framework. Anyone planning to migrate to the public edition in the medium or long term should now assess whether every new extension can be implemented in a clean core-compliant manner.
SAP S/4HANA Cloud, Private Edition
The Private Edition offers significantly more technical freedom – and therefore more scope for spontaneous modifications to the standard. Sustainable management of this freedom means allowing classic modifications only in exceptional cases and clearly documenting the associated risks. New developments should consistently be implemented via approved extension points, and clean core guidelines should be binding for internal teams and external partners.
S/4HANA On-Premise and decentralized EWM
Many productive EWM systems still run on-premises or as decentralized instances. In these scenarios, Clean Core is primarily a gradual change process. First, existing customizations must be identified and evaluated; then, technical debt is gradually reduced. Every new solution should be designed so that it can be easily migrated to a future architecture.
Conclusion and Outlook
Clean Core in SAP EWM means building the system in such a way that the most important processes remain stable, traceable and easily updatable, while extensions are only implemented according to clear rules.
Clean code in ABAP is not an option, but a fundamental requirement. Only understandable, modular, and well-tested code can be maintained, adapted, and ported to new platforms in the long term.
Companies that consistently align their EWM landscape with these principles reduce technical debt, shorten project and release cycles, and gain the freedom to use new SAP functions and automation solutions without slowing down the warehouse.
In short: A clean core and clean code make EWM not a rigid, specialized solution, but a platform that can adapt to changes and pick up speed.
Lilian Vinel, SAP Consultant
Contact & Exchange
A little about me: I'm Lilian Vinel, an SAP consultant specializing in SAP EWM and S/4HANA. Currently, I'm involved in projects focused on clean-core strategies for warehouses and how to cleanly map individual processes using standard features and extensions.
How do you assess the topic of Clean Core and Clean Code in your EWM landscape? Feel free to share your thoughts and experiences in the comments – I look forward to an open exchange.
Leave a Reply