Exception handling consumes a disproportionate share of time and is usually measured at the point of detection, which is the least useful place.
The categories
Stock discrepancies: expected quantity not present.
Location errors: item not where the system says.
Pick errors: wrong item or quantity, detected at check or by the customer.
Damage, discovered at any stage.
Documentation and labelling errors.
System exceptions: tasks that cannot complete for a data reason.
Each has a different origin and a different remedy, and lumping them into an error rate hides all of it.
Detection is not origin
A pick error detected at packing originated at picking, or at putaway, or at receiving.
A stock discrepancy found at count originated whenever the stock moved without a record.
Tracing origin requires the event history for the item and location, which most systems hold and few analyses use.
Report by origin stage, always. Reporting by detection stage produces improvement effort aimed at the checkers.
Measuring properly
Rate per opportunity, not per shift. A stage handling ten times the volume will show ten times the errors at the same quality.
By product characteristic: similar packaging, similar codes, small items, heavy items.
By location, which reveals slotting problems — two similar items adjacent is a predictable error source.
By time of day, which reveals fatigue and shift-change effects.
By exception type, separately.
The cost
Frequently understated because only the correction is counted.
Time to detect and resolve.
Rework of the downstream steps.
Investigation time.
Customer impact, including returns and credits.
Stock write-offs.
The cascade: an exception that stops a line costs more than the item.
Quantify one common exception type end to end, properly. The number is usually startling and it funds the prevention work.
Prevention, in order of effect
Remove the ambiguity. Similar items in adjacent locations, similar codes, similar packaging — these are design problems with design fixes.
Improve the check at the point of origin rather than adding one downstream.
Fix master data, which underlies a large share of system exceptions.
Make the correct action easier than the incorrect one.
Then train, which is where most operations start and where the least improvement is.
The reporting culture problem
The most important consideration and the one most often overlooked.
Exceptions attributed to individuals with consequences attached stop being reported.
Unreported exceptions do not stop happening; they surface later, further downstream, more expensively, with the origin now untraceable.
Report exceptions by process and location, not by person.
Treat a rise in reported exceptions after a culture change as a good sign, which it usually is: the rate did not rise, the reporting did.
Tracing an error to its origin
The analysis that makes exception data actionable, and it uses records you already hold.
Take a sample of confirmed errors.
Pull the full event history for the item and the location: receipt, putaway, replenishment, counts, previous picks.
Find the last point at which the record and reality agreed.
That is the origin, and it is frequently several stages upstream of detection.
Group the origins. A cluster at putaway is a different project from a cluster at receiving.
Twenty traced errors usually reveal the pattern, and the exercise takes a day.
Reason codes that mean something
Exception reason codes are usually three options chosen years ago, and they destroy the analysis.
Review what is actually selected, and how often the catch-all option is used.
A dominant catch-all means the codes do not fit the reality.
Rewrite them with the people who select them, which takes an hour and produces codes that distinguish what needs distinguishing.
Keep the list short, since a long list produces the first option being chosen every time.
Review annually, because the mix of problems changes.