ewm · testing · s4hana · automation · project-management · 2026
What a Tobacco Company's Testing Setup Taught Me About EWM Rollouts
Reusable test automation for global S/4HANA projects and why I'm thinking about this for EWM implementations
I just read about Scandinavian Tobacco Group automating their SAP testing across 24 countries, and it made me stop and think about how we're handling testing on our current EWM rollouts.
The problem I keep running into
We're rolling out SAP EWM at multiple plants in the German automotive industry. Every site has the same core processes goods receipt, putaway, picking, packing, shipping but each one has variations. Different conveyor systems, different RF device setups, different integration points with MES or production systems.
The testing cycle at each site feels like starting from scratch. We adapt test scripts from the previous rollout, but it's manual work. Someone has to walk through each step with an RF scanner. Someone else checks if the expected warehouse task was created. Then we do it again for the next material type, the next storage type, the next exception case.
It works, but it doesn't scale well when you're looking at five or six more plants over the next two years.
What Scandinavian Tobacco Group did differently
STG automated their testing across a global S/4HANA rollout. They built reusable test scripts that could be deployed across different country rollouts without starting over each time.
The part that caught my attention: they didn't just automate the happy path. They automated regression testing and edge cases the kind of scenarios that usually get deprioritized when you're under time pressure at a site cutover.
They're not in logistics. Their implementation is finance, procurement, master data. But the pattern applies.
Why this matters for EWM implementations
EWM testing is different from standard S/4HANA modules in a few ways:
Physical dependency — you can't fully test EWM without actual warehouse operations or at least a realistic simulation. You need material movements, not just transactional data entry.
Integration complexity — EWM talks to WMS handhelds, MES systems, automated conveyors, label printers. Each integration point is a potential failure mode that needs testing.
Site-specific configuration — storage types, bin structures, work centers, resource assignments. Every plant is different enough that you can't just copy-paste test scripts.
But here's what I'm thinking: the core logic doesn't change that much. Inbound processing follows the same sequence. Picking strategies follow the same decision tree. If I could automate the SAP-side validation and just handle the physical RF steps manually, that would already cut testing time significantly.
What I'm considering for the next rollout
I haven't built this yet I'm still figuring out what's realistic but here's the direction I'm leaning:
Automated backend checks — use ABAP or BTP-based scripts to validate that warehouse tasks were created correctly, stock postings happened, status updates triggered. This is the part that's identical across sites.
Modular RF test cases — keep the handheld steps manual, but structure them as reusable modules. "Goods Receipt for Engine Block" is the same process at every plant, even if the bin location and conveyor setup differ.
Regression test library — build a standard set of 20–30 core scenarios that must pass at every site. Run them at each rollout, track deviations, flag anything unexpected early.
The goal isn't full automation. That's probably overkill for EWM where physical processes matter. The goal is to stop rebuilding the same test scenarios from scratch every time we move to a new plant.
Three takeaways
Testing scales differently than configuration — you can template config, but test execution still takes time. If you're doing multi-site rollouts, you need a repeatable testing approach or you'll burn out your team.
Core logic vs. site variations — separate what's standard from what's customized. Automate or templatize the standard parts. Accept that site-specific testing will always be manual.
Start small, prove value — I'm not proposing we overhaul our entire test strategy mid-project. But picking one end-to-end process and making it reusable? That's doable, and it might save us weeks on the next rollout.
If you're doing multi-site EWM implementations and you've figured out a better approach to testing at scale, I'd be curious to hear it. Drop me a line at markus-mildner.com or let's connect if you're running into the same problem.