For a live SAP EWM site that has drifted, or never settled after go-live. This page covers the signs, what a health check looks at in its first week, the four levers that return the most (simplify, stabilise, optimise, adopt), and how a go-live that went badly gets recovered. It is hard, satisfying work: unpicking what was built, on short timelines, often against people who have built ivory towers around the old way.
Live system · BAU · KPI recovery
The position. A live EWM system that has drifted. The original rollout is a long way back, the people who built it have moved on, and the floor has quietly worked around the parts that never fit. This also covers recovery: a go-live that went badly and a hypercare that was wound down too early.
How we work. A short, sharp diagnostic against your real operator flow and master data, then a prioritised backlog where every item is sized by the number of taps, seconds or dollars it returns. We do not pitch a multi-month programme. We close items, we measure the result, and we move on. If a finding has no operational return, we will tell you, and you can spend the money elsewhere.
Picks per hour were fine in the first quarter and have drifted since. Nobody changed the system, and that is the problem: the range, the order profile and the people changed around it. The people who built it have moved on, and the floor has quietly worked around the parts that never fit.
Go deeper · Labour drift: the six-month signals
Notes taped to the racking, a supervisor who holds the sequence in their head, short picks nobody reports. Every workaround is a missing function with a person attached, and every unreported exception turns up later as a stock variance or a short shipment.
Go deeper · System vs reality: four moments · Exception handling the floor avoids
Counts keep correcting the same locations, finance keeps seeing write-offs, and pickers keep walking to empty bins. Stock variances have a short list of usual causes, and each one leaves a mark on the floor before it shows up in the ledger.
Go deeper · Stock accuracy after go-live
The project closed on schedule and the floor never settled. Scanning is unreliable, supervisors are back on paper, and the integrator says the system is working as designed while the floor says otherwise. This is a recovery job before it is an improvement job.
Go deeper · EWM rescue: a go-live that could not scan · Hypercare done early
Stand on the dock during the busy window. Shadow operators through a put-away, a pick and a replenishment. Count taps, time tasks, and watch what happens when something goes wrong. The configuration says what should happen; the floor shows what does.
Go deeper · What an EWM health check looks at in the first week
The warehouse monitor and its backlogs, warehouse tasks left open for days, which exception codes get used and which are avoided, how inventory differences are cleared, whether dimensions, weights and packaging specifications are complete, what the custom code does and why it exists, and which interfaces and background jobs fail quietly.
Go deeper · Z code is an arrogance tax
Who are the key users now, on which shifts, and how much of the original training survived staff turnover? Who fixes things at 4am, and how fast? Who owns the master data? A system with nobody accountable for it decays, however well it was built.
Go deeper · Who owns EWM in year two
Most live sites carry RF screens, confirmation steps and custom transactions that made sense to someone in a design workshop and cost seconds on every task since. Taking them out is the cheapest gain available, and operators notice it on the first shift.
Go deeper · The RF flow is the product · Exception handling the floor avoids
Scanning that fails, stock that does not match, interfaces that stall. Stabilising comes before optimising, because a faster process on an unreliable system just produces errors faster. The rescue reference started here: the floor could not read its own labels.
Go deeper · When the floor cannot scan · Stock accuracy after go-live
Fixed bins, replenishment quantities and pick-face locations were set for the range of go-live year. Re-slotting the fast movers and resetting replenishment against today's order profile often returns more walking time than any new feature. Some optimisation functions sit in the separately licensed advanced scope, so check the contract before anything is switched on.
Go deeper · Slotting and replenishment · Basic or advanced EWM
Training decays with every new starter. Key users leave and are not replaced. Adoption work is unglamorous: refresher sessions written from the shift, a key user on every shift, and exceptions that operators are not punished for reporting.
Go deeper · Readiness is not training
The integrator has gone and the business owns a live EWM it did not design. Before changing anything, find out what is configured against what was documented, why each piece of custom code exists, and what breaks every week and who fixes it today. Then separate what was built wrong from what was built right for a business that has since changed.
Go deeper · Taking over an EWM system someone else built
An application management contract, an in-house team, or a mix with key users on the floor. Whichever it is, response times have to match shift patterns rather than office hours, and the improvement backlog has to live somewhere other than the incident queue.
Go deeper · Who owns EWM in year two
A national operation went live on SAP EWM with another team and the floor could not scan. Wrong barcode symbology, hardware tethered to fixed points, and a reflective cover over the labels. Luminar came in after go-live, stabilised the operation within 90 days and improved scalability by roughly 70%.
Because the team carried real warehouse experience, it supported the whole operation from the first day, with none of the usual weeks of a new team learning the floor before it could make a decision.
A short, senior diagnostic of a live EWM site. It starts on the floor, watching the real operator flow through the busy window, then reads the system: warehouse monitor backlogs, exception usage, inventory differences, master data, custom code and interfaces. Then it looks at the people and the support model. The output is a prioritised list of fixes, each sized by the taps, seconds or dollars it returns, including the ones not worth making.
The Floor Audit is one day on your floor and a plain-language memo within five working days, with no proposal attached. If that day shows a deeper look across more shifts or sites is worth it, we scope that separately and say why.
Because the design was signed off against the operation of go-live year, and the floor is measured against this week's shift. When the KPIs slide and the configuration is behaving as designed, the gap is usually a changed operation, a set of workarounds, or hardware. An independent read from someone who does not sell the build or the support contract can say that plainly.
Usually not first. Most gains on a live site come from what is already there: exception handling, RF flows, master data, replenishment settings and scanning. Some functions, such as labour management, slotting and direct automation control, sit in the separately licensed advanced scope, which varies by release and contract. Check before switching anything on: an advanced feature activated on a basic licence can surface in an SAP audit as backdated licence costs from go-live.
Our reference is a national operation whose floor could not scan after going live with another team. It was stabilised within 90 days, scalability improved by roughly 70%, and the business had a costed path forward. Recovery starts on the floor: find what actually stops the work, fix that first, then plan the rest.
Someone has to own the system: an application management partner, an in-house team, or a mix with key users on every shift. We help choose the model and set up the handover so the knowledge stays in the business, and we say plainly which option suits the size and shape of your operation.
Beside them, on your side of the table. We do not sell the build or the support contract, so we can read the backlog, the defects and the floor against each other and say what matters most in plain language.
One day on your floor and a five-day memo will tell you where the taps, seconds and dollars are leaking, and which fixes are worth making first. No proposal attached.