How's My Accuracy?

When I worked for Quantum Services, every so often they would publish a newsletter internally for all of it's employees. One month they devoted a small section to the notion of accuracy. They wrote:

"Quantum Services is paid by our clients to account for all merchandise at the client locations. Quantum Services' employees must physically count all merchandise in the client locations. All employees are required to maintain an accuracy level of 99%."

Interesting how quickly they go from the hard absolute concept of 'all' to the notion of 99% and the wiggle room that comes with it. But if 99% accurate is Quantum's goal, the question is how would they go about measuring and monitoring one's accuracy to ensure that a counter is in compliance. At any one particular time is an inventory service able to say that a certain counter is accurate at a certain percentage. How does this statistic get captured?

In pretty much every scanning inventory I've done for RGIS, counters will record a piece count for each section they do. In some stores, store employees will verify behind the inventory count to ensure accuracy. In this type of scenerio one could keep track of all the discrepancies that take place, record how big it was and who the counter was, and as a result could possibly tally an accuracy percentage for that counter. Although, I've yet to work for an inventory service that ever did this. For financial inventories arriving at an accuracy percentage is a little tougher, and honestly I doubt that anybody really does anything to capture exactly how accurate any counter is. If you asked an employee of an inventory service how accurate someone was, they probably wouldn't answer you by citing an exact number. If they did they're probably making that number up. However even in financial inventories, there are some tools used in determining or in gauging how accurate somebody is. Below are some of the most common tools used.

Current-to-Previous Comparasions
In this method the inventory totals from the current count are simply compared to the totals from the previous count. This will provide a view of what sections in the store are "up" and "down" when compared to the last count that was done. Generally totals should be consistent from count to count, but the main problem here is that there is going to exist some variation from count to count. No one would expect the exact same totals each time a count is done, natural variation will occur, the question though is how much variation should we expect, and what factors would cause some variation. The day of the week a count is conducted on could create some variation into the count. Most vendors will deliver merchandise to c-stores on a weekly basis, so catching a store at a different time in the vender cycles will cause a good deal of variation. For instance if a store had their main grocery delivery on a Wednedsay, and a Tuesday count was being compared to a Thursday count. The Tuesday count totals should be lower, especially in the areas most affected by this vendor, like candy and tobacco. So if the one candy side is down $200 from last time, that might seem reasonable. But what if it was down $300, or $450, then you get into 'maybe' territory, and that's generally not a good place to be if where's trying to guage how accurate the count is. Store resets are another big problem that creates huge amounts of variations. After some resets, you end up comparing counts from 2 completely different store configurations, and these comparasions wind up being pretty worthless, especialy if you're trying to gauge accuracy. These Current-to-Previous comparasions can be useful in some cases however. Once during my days when I was working internally, I had counted $10,000 worth of candy on one of the gondolas in a c-store. The count last time was only about $5,000. I decided to recount that section and the recount came up with a number that was more in-line with the previous count. I used this recount and thankfully kept myself from inadvertently inflating the inventory by roughly $5,000. Current-to-Previous comparasions are great for judging the 'feasablilty' of a count, but as for the accuracy of it, there do exists some limitations and obstacles.

Audit-to-Book Comparasions
Perhaps the biggest misconception in inventory counting is the notion that if there's a large variance between the book figures and the count, then the count must be wrong. Granted an inaccurate count could create a large variance between the audit counts and the book values, but there's a lot of things that can create such a variance. The notion that a perfectly counted inventory will never result in a large variance is simply not true. Let's consider what all goes into the store's book inventory. To clarify a book inventory figure at any point in time is based on the past inventory counts, sales from the last inventory audit, deliveries from the last inventory audit, store transfers, store credits and write-offs, and retail inventory adjustments that are necessary for items sold at a markup or markdown price, or for price changes. If anyone of these are inaccurate or missing, then the book inventory is going to be off. Thankfully modern technology has enabled automation for some of these factors like sales, and adjustments for markups and markdowns, but other factors like entering in delivery invoices, doing write-offs, and price changes still require human effort, usually from a store manager or their underlings. In the end, both the inventory count and the book figures wind up being products of human effort, and both are prone to error. Thus when we compare the inventory counts to the book numbers, you have one set of numbers that's prone to error being compared to another set of numbers that's prone to error. Trying to determining which side of the equation is responsible for a variance is not going to be immediately transparent, which will require further investigation. One thought that comes to mind is that when one side of this deal is extremely accurate and bulletproof, it will probably expose the inadequancies of the other side. Managers who are always on top of their paperwork, and who keep their book inventories in good order will have better insight into the accuracy of a counter when the time comes for audit-to-book comparasions to be made. The problem though is that store managers exist at many different levels of experience and talent, and much like inventory counters it is a profession that has its share of turnover. Also my 'bulletproof' axiom can work in the opposite way as well. A highly accurate counter can expose an inexperienced manager. So when there is a sizable descrepancy between the book and the count, naturally it's human nature for one side to look to the other side for the explanation, as an inventory counter I've been both a victim and an offender to this mindset. And if this weren't enough we can complicate things even more by adding the notion that an actual theft could create a variance. In this case there may be nothing wrong with the inventory count nor with the manner in which store paperwork is processed. When you consider all the things that can affect the audit-to-book variances, this is probably going to be one of the worst ways to judge counter accuracy.

Recounts
If a particular number doesn't look good, one of the most popular methods of dealing with it is to have a counter recount that particular section. If the recount comes back with a similar total this will seem to confirm the accuracy of the count. But what if the second count is vastly different? That's the thing about a recount, you're essentially repeating the same process that might have failed initially. A recount is as much prone to error as the originial count was. Also if recounts are done some time after the initial count, and the store remains open during the inventory there may be some variance between counts. Although the variance here should be fairly small, much like count-to-previous comparasions there's going to be some 'maybe' territory when judging a recount against the orginial. A recount that comes out higher than the original though should raise an eyebrow or too, unless merchandise was stocked in-between counts. In some cases a recount is merely a 'second opinion', a chance to see if someone else would come up with something different? If 2 people count a section and come up with the same thing this would seem to validate the work of both counters. If a counter recounts a section that they counted originally, you have to wonder if you're getting a measure of their consistency or their accuracy. Ultimately what can we infer from 2 counts that are wildy different? You could argue that one count is right and one wrong, or to complicate matters that neither are correct. In this case you would need a third count to judge which one is right, whether it'd be from another recount or from a past count. From these scenerios what can we say about a counter's accuracy? If a recount is wrong, do we infer that the recounter is inaccurate, and what does this say about the original count? anything? And by how much do we say that they were inaccurate. If both counts are wrong how do we arrive at a measure of inaccuracy for either counter? With each count being prone to error, and with the presence of some 'maybe' territory, it's hard to arrive at an accuracy level from a recount. In general a recount seems better designed to confirm someone's count, rather then to offer proof against it. As for the magic measure, it's even more ill-designed to do that as well.

Keystroke Detail
This method involves examining the keystrokes that comprise the counts themselves and verifying them against the product on the shelf. Keystroke detail allows you to see how an inventory count for any section is constructed, and allows one to see whether or not it's right when held up to the items in the section itself. This method probably offers the best view of how accurate a counter is. What makes this method different from the rest is the fact that we're comparing the counts up against the actual merchandise itself. When we think about counter accuracy what should come to mind is how well a count reflects what is physically present in a store. It would make sense then that to measure accuracy that's what we would want to look at , what is actually there, not what someone else counted or what the book inventory says should be there. Keystroke detail also gives you far more certainy as to whether or not the physical count was correct. For instance say I accidently count a few boxes of candy at $8.99/piece instead of $.89 because of a keystroke error. Comparing my count to last time may reveal that candy is up, but it could be viewed as within normal levels of variance especially if I consider a factor like vendor cycles. A recount, done properly, would result in a smaller count but it could still fall in the land of 'maybe', and if it didn't it wouldn't necessarily give much insight as to whether my original count was incorrect. Looking at the keystroke detail, I'm going to know that $8.99 is not correct, and I'm going to know that the this count is not accurate, and even better, I'm going to know exactly what needs to be done to correct the mistake. The level of certainty you get from this method can result in greater accuracy in the end. Granted you probably wouldn't want to review every single keystroke in an entire inventory, but this is a great tool for zeroing in on a certain portion of the count. This can be used for the 'further investigation' I mentioned earlier. With keystroke detail you're sort of putting a slice of an inventory count under the microscope for a more intense review of one's accuracy.

But more importantly the certainty that this method brings can allow us an opportunity to measure a person's accuracy. When we find a mistake we'll know the value of the mistake and the value of the section when correct. We could use these two values to arrive at an accuracy percentage. The only problem here is going out and collecting the data. To obtain this measure someone has to review keystroke detail up against the physical merchandise itself, if not the counter themselves ( a scenerio that might present some issues) then who? Keystroke detail most of the time is used to 'obtain' accuracy not to measure it. I honestly can't think of anything that any inventory service does to literally measure and record a person's accuracy. It seems odd for an inventory service to uphold a standard of excellence in regards to accuracy when there seems to be no internal mechanism present to monitor and measure it. There probably isn't an answer to the question of how accurate a given counter is. Nor would there be an answer to the question of "exactly how much is very?"