Every warehouse has a bad moment at the pick face. The bin that should hold forty cartons holds six. The operator is on their feet, the queue behind them is growing and the order needs filling. In a well-set-up EWM system there is a way to say “this is short” and have the system do something sensible about it. On a lot of live sites, nobody uses it. This note sits in our SAP EWM health check and optimisation series, and it is about why that happens and what to do next.
The short version: an exception function that is slow, vague or risky for the operator will be avoided, and the cost of avoiding it is carried by everyone downstream.
What an exception is for.
EWM lets the operator report what went wrong at a step through an exception code, and the system can trigger a follow-up from it. That might be a count of the bin, a new destination for the pallet, or a block on the stock until someone has looked at it. What is available depends on how the site is configured and on the release, so check yours rather than ours. The principle is the same everywhere. The operator is the only person who sees the problem at the moment it happens, and the exception is how that knowledge gets into the system while it is still fresh.
When it works, a short pick becomes a recorded fact with a follow-up attached. The bin gets counted, the order is reallocated, and the record matches the rack within the hour. When it does not work, the same short pick becomes a quiet decision made by one person with a handheld and no time.
Why the floor stops using them.
Nobody avoids exceptions out of laziness. The reasons are practical, and they tend to come in a few forms.
Too many taps.
If reporting a short pick takes five screens and the pick itself took two, the operator does the sums. Our note on the RF flow as the product covers the tap economy in detail. Exceptions are where that economy is least forgiving, because they happen when the operator is already behind.
A supervisor comes running.
Some sites configure exceptions so that a supervisor has to approve or clear them. That sounds like control. On the floor it means a radio call, a wait, and a shift lead pulled off other work every time a bin is empty. After a few busy mornings the operators learn not to trigger it, and the shift lead learns not to ask.
It makes the operator look bad.
If every short pick is logged against the person who reported it, and the report feeds a performance conversation, the lesson is quick. Report nothing, and the count stays clean. Whether or not anyone intended it, the system is rewarding silence.
What happens instead is easy to recognise. The operator picks what is there and moves on. Or puts the pallet in the next bin that has room, because the system's chosen destination is full. Or writes on the pallet and leaves it for someone else. We described the same drift in four moments where operators quietly stop using EWM; avoided exceptions are the most common way the first of those moments repeats itself.
What each avoided exception costs.
The cost does not arrive at the pick face. It arrives later, in places that look unrelated.
A short pick that nobody reports leaves the system believing the bin still holds stock. The next order allocates against it, and the next picker finds it short too. A pallet put away somewhere other than where the system sent it is, as far as the system knows, in the wrong place, and the next person sent to fetch it will not find it. A damaged pallet that was never recorded as damaged gets shipped, and the customer finds the damage for you.
This is where stock accuracy after go-live often starts to slip. The counts get blamed. The cause is further upstream, in the moment an operator knew the record was wrong and the quickest option was to say nothing. Recounting the warehouse repairs the symptom and leaves the habit in place.
How to find the exceptions nobody uses.
You do not need a project for this. You need three comparisons.
Configured against used.
List the exception codes the warehouse has set up, and set that beside the ones that have actually been reported over the last few months. Your EWM team can report on which codes were used, where and how often. Codes that exist and are never used fall into two groups: ones for events that really never happen, and ones for events that happen every day and go unreported. The floor can tell you which is which in a five-minute conversation.
The busy window.
Look at reporting by time of day. A healthy site reports exceptions more when it is busy, because more goes wrong. If the count drops during the peak hours, people are not having fewer problems. They are skipping the reporting.
What supervisors fix by hand.
Ask shift leads what they correct manually: stock they move between bins, quantities they adjust, tasks they cancel and recreate. Every one of those is an exception that did not go through the system. They are also the quickest way to find the ones that matter most, because supervisors only bother fixing the ones that hurt.
Then stand at the pick face in a busy hour and watch. The handwritten note on the rack upright is an exception code the system never got.
The floor reports exceptions at the speed the system lets it, and no faster.
Designing exceptions the floor will use.
The fix is rarely more training. It is a smaller, plainer set of exceptions that cost almost nothing to report.
Keep the list short. A handful of codes that cover the real events (nothing in the bin, less than expected, damaged, wrong item, destination full) will be used. A list of twenty will not. Name them in floor language, as the operators say them out loud, not in the wording of the data model. Make each one a tap or two from the screen where the problem is found, with no second screen asking the operator to justify themselves.
Tell them what happens next. A good exception ends with a clear consequence on the handheld: “Bin will be counted. Take the next pick.” An operator who knows the system has taken the problem off their hands will report the next one. One who is left holding a half-finished task will not.
And take the blame out. If the report is attached to the operator's name in a way that reflects on them, decide deliberately what that data is for. Reporting an empty bin is not a mistake. Treat it as one, and you will stop getting reports.
What each one should trigger, and who owns it.
An exception with no follow-up is just a note. Every code on the list should answer two questions before it goes live: what does the system do next, and which person is responsible for the answer.
For a short pick, the follow-up is usually a count of that bin, and the owner is whoever runs inventory control on that shift. For a full destination bin, the follow-up is a new destination offered straight away, and the owner is the system itself, with the supervisor only seeing the pattern if it repeats. For damaged stock, the follow-up is a block on the pallet and a decision from quality or the customer service team. These are examples, not a template. What matters is that nobody discovers a week later that a follow-up task was created and sat in a queue no one watches.
Check the loop closes. Ask for the oldest open follow-up from each code. If the answer is measured in days, the operators will work out soon enough that reporting leads nowhere.
A weekly review that pays.
Exception data is one of the cheapest sources of improvement a live warehouse has, and most sites never look at it. Set a short weekly review, thirty minutes, with the shift leads and whoever owns the system. Look at which codes were used, which bins and products appear repeatedly, and which times of day show the most.
A bin that keeps coming up empty is a replenishment problem, not an operator problem. A product that keeps coming up damaged is a packaging or receiving problem. A destination that keeps being full is a storage problem. Each of those is a fix that removes a whole class of exceptions at the source. Try it for a month before deciding whether the review is worth keeping. The first two or three sessions usually produce a list of fixes the shift leads have wanted for a year.
Reading the data this way also changes what the numbers mean. A rise in reported exceptions after a clean-up is often good news: the floor is telling you more. Judge the site by what it reports and what then gets resolved, not by how quiet the screen looks.
If the exceptions are quiet because the floor has stopped trusting them, that is a design problem and it can be fixed. Our EWM rescue case study shows what a floor-first review finds when workarounds have grown up around a system that was not working for the people using it.
How Luminar approaches exceptions.
We are independent and we do not sell the build. A senior consultant spends a day on your floor, at the pick face in the busy window, watching what operators do when something goes wrong and what they quietly leave unreported. We compare that with what is configured, find the exceptions the floor has dropped, and write up what to simplify and who should own each follow-up. You get a plain-language memo in five working days. There is no proposal attached.