Amazon's Robot Rollout Cut Jobs — Here's What That Actually Means for EWM Implementations

Amazon just made headlines again — this time for linking warehouse robot expansion directly to workforce reductions. That's not a new story in principle, but the scale and the directness of the admission is worth sitting with.

For most of us working in SAP EWM, we're not building Amazon's fulfillment network. But the pressure that's driving their decisions — reduce labor dependency, increase throughput, justify the capital spend — is the same pressure showing up in the automotive plants and discrete manufacturing sites where EWM actually gets deployed.

So let me share what I'm seeing on the ground, and where I think this lands for real EWM projects.

The Automation Gap Between Vision and Configuration

Every implementation I've been part of starts with a slide deck showing autonomous mobile robots, conveyor integration, and real-time inventory accuracy. Then we open the system and start mapping actual warehouse tasks to warehouse process types, and the gap becomes obvious fast.

The vision assumes a clean physical environment, standardized handling units, and a WMS that can speak fluently to whatever robot vendor was selected — sometimes two weeks before go-live. EWM has solid integration architecture. The EWM-MFS (Material Flow System) layer is genuinely capable. But getting it to behave reliably with third-party automation systems takes time, clear interface specs, and someone who has done it before.

That combination is rarer than the slide decks imply.

Where SAP EWM Scoring Fits In (and Why It Fails)

One thing that comes up repeatedly in automated warehouse designs is task interleaving and resource assignment — essentially, how the system decides which resource gets which task, in what order.

In EWM, this goes through the work center and resource management layer, combined with queue assignment and — when you dig deeper — scoring rules configured in labor management or task prioritization logic. In theory, scoring lets you weight tasks by distance, urgency, resource type, and other factors. In practice, the scoring configuration is one of the first things that breaks under real warehouse conditions.

Why? Because the scoring model was designed in a meeting room with clean assumptions. The warehouse has mixed-height racking, shared aisles between automated and manual zones, and handling units that didn't scan correctly on arrival. The system scores perfectly against a model that no longer matches reality.

This isn't a criticism of EWM — it's a reminder that scoring logic is only as good as the data feeding it. When automation is added to the mix, those data dependencies multiply fast.

Amazon's Problem Is Not SAP's Problem — But the Lesson Transfers

Amazon built their own systems. They're not running EWM. But the core challenge they're publicly wrestling with — how do you integrate physical automation with the software layer managing warehouse execution, while keeping labor costs predictable — is exactly what mid-market manufacturers are trying to solve with SAP.

The difference is that Amazon can absorb the cost of getting it wrong. A single-site automotive plant doing a greenfield EWM rollout with conveyor integration cannot.

This is where I think the honest answer for EWM consultants is: slow down the automation ambition in phase one. Get transfer orders, warehouse tasks, and handling unit management working cleanly in the manual zones first. Prove the data quality. Then bring in the automated equipment with a system that's already stable.

What Labour Management Data Actually Tells You

If you have EWM Labour Management active, you have access to something Amazon spends billions trying to approximate: granular, task-level time data per resource, per warehouse area, per shift.

Most implementations I've seen have it switched on and then mostly ignored past go-live. That's a missed opportunity. The standard time data in labour management — even roughly calibrated — gives you the baseline you need to evaluate whether an automation investment is actually going to move the needle, or whether the bottleneck is upstream in goods receipt or putaway strategy.

Before the conversation becomes "should we add robots," the data question should be: where are the tasks actually taking longer than expected, and why?

Key Takeaways

• Automation ambition needs to match data maturity. Scoring logic, resource assignment, and MFS integration all depend on clean master data and stable physical flows — fix those first.
• EWM Labour Management is underused. If it's live, the time data is already there. Use it to make the automation business case honestly, not just aspirationally.
• Amazon's experience is a leading indicator. The pressure to automate is real and it's coming to mid-market manufacturing. EWM projects that build in flexibility now — clean interfaces, modular process types — will be easier to extend later.

If you're working through automation integration in an EWM project and hitting walls with scoring or MFS config, I'd be curious what you're seeing. Drop a comment or find me at markus-mildner.com.