Most of the attention on an SAP EWM programme goes to the build and the go-live. The part that lasts ten years gets a paragraph in the statement of work. Once hypercare closes, the team that knew every corner of the design moves to its next client, and from that day the system is only as good as whoever looks after it. This note sits in our EWM health check and optimisation series, and it covers the decision that quietly shapes every other one in it.
What actually rolls off.
When the integrator leaves, three things go with them. The first is the people who can read the configuration and tell you why a putaway strategy or a storage control step was built the way it was. The second is the habit of fixing things straight away, because during hypercare a floor problem has a named person and a fast answer. The third is the list of small improvements that everyone agreed on in the last workshop and nobody owns.
None of this shows up on handover day. The system works, the documents are signed, and the calendar says the project is done. It shows up months later, when a supervisor lives with a scanner prompt for three weeks because raising a ticket felt like more trouble than the prompt. If you have already inherited a system in that state, our note on taking over an EWM system covers the first weeks. This one is about not getting there.
Three models in plain terms.
An application management contract with a partner.
An application management service (AMS) hands day-to-day support to an outside firm under a contract. It is good at breadth and cover: a pool of people, a ticketing process, someone to call who is not on leave. It is weaker at knowing your floor. The person who picks up the ticket is often working from the ticket text and the documentation, and a warehouse problem described by a night shift leader at the end of a long shift does not always survive being typed into a queue. An AMS also tends to be tuned to keep the system running, not to make it better, unless improvement work is written into the contract and paid for separately.
An in-house EWM team.
A small internal team keeps the knowledge in the building. They know the floor, they know the supervisors by name, and they can walk to the dock when something is wrong. The weaknesses are real ones. EWM skills are scarce, a team of two is a team of zero when one is on leave, and the experienced person you hired is also the person a recruiter will call. A small team also sees one warehouse, so it can go years without meeting a better way of doing something.
A mix, with key users on the floor.
The arrangement that tends to hold up best is a blend. A partner provides depth and out-of-hours cover for the hard faults, a small internal owner holds the knowledge and the priorities, and trained key users on each shift handle the small things at the dock. It costs more coordination than either pure option, and it only works if the boundaries are written down: who fixes what, who decides, who gets woken up.
What a warehouse needs that an office system does not.
Support models are usually sold on the experience of finance and procurement systems, where an outage means a delayed report. A warehouse fails differently, and the arrangement has to fit.
Cover that follows the shifts.
A dock that cannot scan at 4am is a priority one incident. The trucks are booked, the drivers are waiting, and the pickers on the next shift will stand idle in an hour. If your support hours are office hours, that incident sits untouched until someone logs in at eight. Match response times and after-hours cover to the real shift pattern, including weekends and the peak weeks, and be clear about what counts as priority one before the first night it happens.
Someone who understands both the configuration and the floor.
A scanner screen that stalls can be a configuration fault, a master data fault, a wireless dead spot or an operator who has found a faster route that the system does not like. The person triaging has to be able to tell which, and that takes time on the floor as well as time in the system. Our note on why the RF flow is the product explains why the scanner experience is where most support calls start.
Key users on every shift.
Pick one or two people per shift who are trained to fix the small things (a bin that needs unblocking, a handling unit that needs correcting) and, just as important, to know when to stop and escalate. Without them every small thing becomes a ticket, or worse, a workaround that outlives the problem. They need recognition and a little protected time, or the role quietly disappears after the first busy season.
The four jobs nobody writes down.
Master data ownership.
After go-live, someone has to maintain packaging specifications, bin definitions and product dimensions as new products arrive and old ones change. If that person is not named, the data drifts, and the system starts making putaway and picking decisions on numbers that were true last year. We covered the shape of the problem in master data for a new warehouse; the ownership question does not go away after go-live, it gets harder.
A backlog separate from the incident queue.
Incidents are things that are broken. Improvements are things that could be better. Put them in one queue and the urgent always beats the useful, so nothing improves. Keep a separate, ranked list of improvements with a named owner on the business side, review it on a regular rhythm, and agree how much support capacity is reserved for working through it.
Releases tested against the RF flows.
SAP delivers updates and support packs on a schedule you do not control, and a change that looks harmless in a technical test can alter a scanner prompt or a task sequence. Before any update reaches the floor, someone needs to run the real RF flows in a test system with real devices: receive, put away, pick, replenish and the exceptions. Decide who does it, on what environment, and who can say no.
Knowledge kept in the business.
If the only person who understands why the system behaves a certain way is one contractor, you have a single point of failure with an invoice. Design decisions, workarounds and the reasons for them should live in documents the business owns and in the heads of at least two of its own people.
A support contract buys you answers. Whether the system gets better depends on who in the business owns the questions.
Signs the current model is not working.
You rarely need an audit to see it. Look for these:
- Supervisors keep their own spreadsheets or paper lists to get round something the system should handle.
- The same incidents come back after being closed, because the ticket was fixed and the cause was not.
- Night and weekend problems wait for the morning, or get solved by phoning a former project member.
- Nobody can say who approved the last change to a storage or picking setting, or why.
- The improvement list is empty, or it is a list nobody has opened since hypercare.
- An update was applied and the floor found the problem before the support team did.
- Operators describe the system as something that happens to them.
Any one of these is a conversation. Three or more together usually means the model is keeping the system alive without improving it. If it has gone further and the floor is struggling to run at all, our EWM rescue case study shows what recovery after go-live looks like.
Questions to ask before you sign.
We will not quote response times or costs here, because the right numbers depend on your shifts, your volumes and your contract, and anyone who hands you a standard figure has not seen your dock. Ask these instead, of a partner or of your own team.
- What is priority one on our site, in our words, and who agreed it?
- What response and resolution times apply on a Sunday night, and what happens if they are missed?
- Who triages a scanner fault, and have they stood on our floor?
- Which of these are included: improvement work, release testing, master data support, training of new key users?
- Who on our side is named as owner for master data, for the improvement backlog and for release sign-off?
- Where is the design knowledge written down, and who other than the contractor can read it?
- What happens to all of this if the key person leaves, on either side?
- If part of the system depends on licensed advanced functions, who confirms scope? (It varies by release and contract; see basic or advanced EWM.)
Write the answers down before hypercare ends, while the integrator is still in the room and still has a reason to answer properly.
How Luminar approaches support.
We are independent and we do not sell the build or an application management contract, so the advice does not tilt toward a service we would like you to buy. A senior consultant spends a day on your floor, including a quiet stretch of the night shift if that is where the risk sits, and looks at how incidents really reach whoever fixes them. You get a plain-language memo in five working days: which model you are running in practice, where the gaps are, and what to put in front of your partner or your own team. No proposal attached.