Key takeaways
- A total shortage figure carries almost no diagnostic information. The same $10,000 means something different once it is split by location, period, shift and product category.
- Test the stated explanation against the shape of the data: a system-wide calculation error spreads across sites, shifts and categories, while loss from misconduct concentrates in compact, high-value items on particular shifts.
- Ten complaints are not ten failures. An alert without context adds noise; a useful system shows where the anomaly sits, how much is still uncertain, and where an investigation should start.
More than twenty years ago I took a call I still think about. Roughly $10,000 missing at an inventory count, users reporting errors, and an owner who had already reached his conclusion: the system we had just rolled out did not work.
I was running a regional implementation branch at the time, and we had won a tender to automate seventeen service stations. The complaints started after go-live, and a large amount of money was gone. His reading of it was not unreasonable. The sequence of events pointed straight at us.
It was also personal in a way that contracts rarely are. I had negotiated the deal myself, and the owners had tied the project to me rather than to the company behind me. At the closing meeting they shook my hand and said, plainly, that they expected me to answer for any money the project lost them. Where I was working, a handshake like that carried roughly the weight of a signed clause.
Our first mistake was not looking at the shape of the complaints
Support had been logging incidents for weeks. Nobody had asked the obvious question about that log: were these one recurring defect, several unrelated ones, a local operating problem, or the same event reported over and over by different people?
This is a standard trap in any rollout. The system fails reliably while people work, and behaves perfectly the moment a specialist stands next to them. Left alone, that gap turns into mutual suspicion: users decide the software is broken, the implementation team decides the users are careless, and nobody is looking at the evidence.
Ask what shape the problem has, not how big it is
Before the meeting with the owner, I asked our team for something other than the total. Five questions, none of them clever:
- Where: which of the seventeen stations does the difference sit at, and how does each one compare with the others?
- When: over what period did it accumulate, and did it start before or after go-live?
- Who: which shifts, and which people were working them?
- What: which product categories, and what do those products have in common physically and commercially?
- Elsewhere: does the same pattern show up at any other site running the same version?
What the breakdown showed
Every error report came from one station, on one shift. The shortage, about $10,000 accumulated over a month, was not spread evenly across the assortment either. It sat in three categories: cigarettes, premium spirits and chocolate. Small, expensive, easy to carry out of a building without anyone noticing.
I brought the printouts to the meeting, because this was well before anyone pulled a breakdown up on a phone. Until that point the owner and I had been looking at the same total and reading two different situations out of it. He saw a failed rollout across his whole network. What the distribution showed was that, whatever this was, it lived at one site, on one shift, in a defined group of products.
The number did not change in that meeting. What changed was how much of the business it implicated, and therefore where anyone should spend the next week looking.
A later investigation confirmed the losses came from deliberate misconduct rather than a calculation error. I want to be precise about what the data did and did not do there. It did not prove anything. Proof came from documents, stock counts and conversations, which is where it belongs. What the breakdown did was point the investigation at a place where it could actually find something.
If the explanation were true, what would the data look like?
That question is the part of this story I have used most since, and not only for shortages. Take the explanation on the table, assume for a moment that it is correct, and ask what pattern it would have to leave behind:
- A system-wide calculation error should appear across locations, shifts, users and categories, because the same logic runs in all of them. It rarely confines itself to one corner of the network.
- A training or usage problem tends to follow particular people or shifts, and to fade at sites where the same version runs with an experienced team.
- A configuration error usually starts on the date something was changed, and stops at the locations where it was not.
- Loss from misconduct tends to concentrate in items that are compact, valuable and easy to move, and often in a narrow window of time.
None of these are verdicts. They are a way of deciding where an investigation should start, which is a genuinely different thing from deciding what happened. The value is in ruling out the explanations whose fingerprints are simply not there.
Ten complaints are not ten failures
The same discipline applies to everything a system flags. Ten complaints may be one defect reported ten times. An automatically generated anomaly can be statistically unusual and operationally irrelevant, while a small deviation in a sensitive category deserves attention this week. Volume is not severity, and neither is standard deviation.
This is where I have become wary of systems that raise alarms without helping anyone judge them. An alert that says a number moved leaves the reader exactly where the owner and I were before the printouts came out. The separate argument for why reporting has to move from recording what happened to guiding what to do next is one I made in From Accounting to Navigation; this piece is about the narrower, more practical question of how to read one anomaly once it appears.
What this means for the alerts your own system sends
It is the reason marql was built to answer the breakdown, not just the total. When a difference shows up in stock, margin or cash, the useful next screen is the distribution: which locations, which periods, which shifts, which categories and suppliers. It connects read-only to the POS, accounting and stock systems a chain already runs, hosted in the EU, and the follow-up question is the next message in the same conversation rather than a new request to somebody in finance — the friction I wrote about in the hidden cost of manual reporting.
The limits are worth stating as plainly as the capability. It does not establish intent, it does not replace a stock count, and it does not conduct an investigation. What it does is get an operations lead or a finance lead to the same printouts I was carrying into that meeting, in minutes rather than after a week of asking, with pricing starting from EUR 200 a month.
See it on your own data
Bring a difference you have not explained yet — a shortage, a margin drop, a site that behaves unlike the rest. We'll break it down by location, period and category on your own data and show you where it actually sits.
Talk to your business. Ask. Understand. Act.
Written by
Evan Kazakov
Co-founder, marql