Lessons · Lesson 2 of 3
A way of not typing
Measure your own keying error rate, work out which of those errors your code scheme catches and which it lets through, and price what a scanner does and does not remove.
Lesson 2 of 3 · 40 min
What a barcode is really for
Typing a code is the cheapest thing in a warehouse and one of the most expensive. It takes a few seconds. Some of the time it is wrong, and the wrong ones do not announce themselves. This lesson puts a rate and a price on that, and then asks what a scanner actually buys.
The usual argument for scanning is speed. It is not the main one, and this lesson shows by how much it is not.
Measuring the rate on your own floor
Tafoukt keys 42,600 movement lines a year that carry both a location code and an item code. For one year Naima Mekouar kept every rejected entry and every entry later found to be wrong. The store did not sample. It counted.
A mis-key is a code typed wrongly. The terminal is the screen the storeman types it into.
| Field | Mis-keyed | Refused at the terminal | Accepted, and wrong | Detection |
|---|---|---|---|---|
| Location code | 249 | 178 | 71 | 71.49% |
| Item code | 96 | 92 | 4 | 95.83% |
| Quantity | 152 | 0 | 152 | 0.00% |
| All three | 497 | 270 | 227 | 54.33% |
That is 497 mis-keys in 42,600 lines, or 1.17% of lines. Read it as one error in 86 lines. It is not a shocking rate, and it is not meant to be. The interesting numbers are in the last two columns.
Quantity has no detection at all, and it cannot have any. A location code can be checked against a list of places that exist. An item code can carry a check character. A quantity of 340 is as valid as a quantity of 34, and the system has nothing to compare it with. Every quantity mis-key at Tafoukt went straight into the record.
What a code scheme actually catches
Tafoukt's rack codes look like BK-03-12-C-1: a two-letter zone, a two-digit run, a two-digit bay, a level letter and a position digit. A run is an aisle of racking, a bay is one section of it, the level is the shelf height and the position is left or right within the bay. Eight characters get keyed. There are 8 runs, 21 bays, 4 levels and 2 positions, so 1,344 rack locations.
Here is the argument people make, and it sounds convincing. The eight characters can be arranged into 6 x 8 x 21 x 4 x 2 = 8,064 well-shaped codes, and only 1,344 of them are real. So five sixths of a mis-key lands on nothing and gets refused.
That argument assumes a mis-key is a random code, and it is not. A mis-key is usually one character changed, which lands next door rather than anywhere. So enumerate it instead. Enumerating means listing every case rather than reasoning about it. Take all 1,344 real codes, change one character at a time to every other letter or digit that field allows, and count how many of the results are also real locations.
| Field mis-keyed | Wrong strings it can produce | Of those, a real location | Share landing somewhere real |
|---|---|---|---|
| Zone, two letters | 67,200 | 0 | 0.00% |
| Run, two digits | 24,192 | 9,408 | 38.89% |
| Bay, two digits | 24,192 | 12,032 | 49.74% |
| Level, one letter | 33,600 | 4,032 | 12.00% |
| Position, one digit | 12,096 | 1,344 | 11.11% |
| All eight characters | 161,280 | 26,816 | 16.63% |
The bottom row says 83.37% of single mis-keys are refused, which is almost exactly what the loose argument claimed. That agreement is a coincidence, and it hides the real answer.
Look at the zone row. Every wrong zone is refused, because no other zone uses the rack format at all. But the zone on a putaway slip is always BK, so nobody mis-keys it. Those 67,200 strings are counting a mistake that does not happen, and they are 41.7% of the table.
drop the zone characters
strings possible 161,280 - 67,200 = 94,080
landing on a real place 26,816
share landing somewhere real 28.50%
refused 71.50%The honest detection rate is 71.50%, not 83.37%. Now compare it with the measurement at the top of this lesson. Tafoukt's terminal refused 178 of 249 location mis-keys, which is 71.49%. The enumeration predicted the floor to within one hundredth of a percentage point. Two completely separate methods, one from the code scheme and one from a year of slips, and they agree.
The bay field is the one to worry about. Half of all bay mis-keys land on a real bay, because bays run from 01 to 21 with no gaps. A dense field is a field with no room to be wrong in.
Swapping two neighbouring characters is a different and kinder error. Of the 9,248 swaps of two unlike neighbours, only 416 produce another real location, so 95.50% are refused.
The one extra character
Tafoukt's item codes already carry a check character and its location codes do not. That is the whole reason item detection is 95.83% and location detection is 71.49%. A check character is one more character on the label, worked out from the others. If a single character in the code is wrong, the code no longer adds up, and the system refuses it.
Naima looked at all 71 accepted-but-wrong location entries and judged each one. 64 of them were single mis-keys that a check character would have refused. The other 7 were correct codes for the wrong place: the operator read the line above the one he wanted. No check character can ever catch that, because nothing is wrong with the code.
Those 64 include 7 of the 8 mis-keys that stopped a line.
reprint 1,402 location labels at EUR 0.42 = EUR 588.84, once
line time those 7 stoppages cost = EUR 1,639.10 a year
payback about 4.3 monthsThat is the cheapest intervention in this entire course, it needs no software, and almost nobody does it.
What being wrong costs
Detection is only half the question. The other half is what the survivors cost, and the answer is not proportional to how many there are.
| Class | Wrong records | What they cost | Cost |
|---|---|---|---|
| Location | 71 | 47 found within two days, 18 min each | 48.22 |
| Location | 15 found late, 52 min of searching each | 44.46 | |
| Location | 8 stopped a line, 19.4 hours at EUR 96.56 | 1,873.26 | |
| Location | 1 never found, interlining re-bought | 181.70 | |
| Item code | 4 | 214 fronts fused with the wrong interlining at EUR 2.06 | 440.84 |
| Item code | 2 found at the next count, 1 caught at despatch | 6.61 | |
| Item code | plus 92 refusals re-keyed at the terminal | 3.06 | |
| Quantity | 152 | 119 corrected at the next count, 14 min each | 94.96 |
| Quantity | 12 shortages that stopped work, 13.1 hours | 1,264.94 | |
| Quantity | 15 over-issues to the floor, never returned | 1,104.60 | |
| Quantity | 6 emergency purchases, premium over the standing price | 668.40 | |
| Total | 227 | 5,731.06 |
Now put the two things side by side.
| Class | Share of the 497 mis-keys | Share of the EUR 5,731.06 |
|---|---|---|
| Location | 50.10% | 37.47% |
| Item code | 19.32% | 7.86% |
| Quantity | 30.58% | 54.67% |
Quantity is under a third of the errors and over half the money. It is also the only one of the three a barcode cannot touch.
What a scanner removes
A scanner reads a field instead of the storeman typing it. That works for a location code and for an item code, because both are printed on something. It does nothing for a quantity, because nobody prints a quantity on a shelf.
errors a scanner can reach 345 of 497 = 69.42%
money a scanner can reach EUR 2,598.16 of EUR 5,731.06 = 45.33%Seven errors in ten and four euros in ten. Anyone who sells you a scanner will quote the first number.
Two honest deductions before the money is claimed. First, scanning is not perfect either. An operator can scan the label on the bay next door, or the roll beside the one he took. Tafoukt has never scanned, so its own rate for that is unknown, and no allowance is made for it here. The EUR 2,598.16 is therefore a ceiling, not an expectation. Second, EUR 92.68 of it is search labour that already sits inside the 968 searching hours of lesson 1, so it must be taken out or it is counted twice.
| Line | Amount |
|---|---|
| Errors removed, less the double count | 2,505.48 |
| Keying time, 42,600 lines at 29 seconds saved | 1,173.63 |
| Counting time, 22% of 456 hours | 343.09 |
| Benefit a year | 4,022.20 |
| Labels, 1,402 at EUR 0.42 | 588.84 |
| Four rugged handhelds at EUR 640 | 2,560.00 |
| Wireless coverage, four access points and cabling | 2,310.00 |
| Scanning module on the ledger | 3,180.00 |
| To put in | 8,638.84 |
| Module support, a year | 780.00 |
| Labelling goods that arrive unlabelled | 176.58 |
| To run, a year | 956.58 |
Net is 4,022.20 - 956.58 = EUR 3,065.62 a year, so 8,638.84 / 3,065.62 = 2.818 years, or 33.8 months. That is slower than the register and ledger of lesson 1, which paid back in 21.0 months, and it is the right order to buy them in.
Split the benefit and the usual argument comes apart.
being wrong 2,505.48 62.29%
speed 1,173.63 29.18%
counting 343.09 8.53%Speed is under a third of it. The saying that a barcode is not about speed is two thirds true rather than wholly true, and two thirds is worth saying accurately.
Check yourselfA supplier offers to send every delivery with its own barcode already on the carton, at no charge. Tafoukt currently labels 3,864 incoming units a year itself. Is this worth having, and what would you check first?Show the answer
The direct saving is the labelling line. 3,864 labels at 26 seconds each is 27.9 hours, and with consumables the whole line is EUR 176.58 a year. That is small, and it is not the reason to say yes. The reason is that a supplier label arrives before the goods do, so receiving can be checked against the advance paperwork rather than copied out of it, which removes a keying step this lesson has not priced. The thing to check first is what the code actually identifies. A supplier code that names the supplier's own part number is only useful if Tafoukt can map it to its own item code, and somebody has to maintain that map. If the supplier changes his part numbering and nobody tells the store, every scan then resolves to the wrong item. That is the wrong-but-valid error again, and it is the one nothing catches. So the answer is yes, with a cross-reference table that somebody owns and a rule for what happens to an unknown code.
Check yourselfSalma Sqalli asks why the store should not simply require a second person to check every keyed entry, which costs nothing to set up. Answer her with the figures in this lesson.Show the answer
It costs nothing to set up and a great deal to run. Checking 42,600 lines a second time is a second full keying. At the 44 seconds a line this lesson uses, that is 520.7 hours, or EUR 1,780.68 a year, every year, against EUR 8,638.84 once for scanning. It also does not work as well as it sounds. Double checking catches the errors the checker notices. A checker reads a slip and a screen. When the two agree he passes the entry, even where the location code is real and wrong, and that is exactly the class that costs the money. What double checking does catch is the quantity, because a second person can count. So the honest answer is not no. It is that a second check should be aimed at quantities on high-value movements only, which is where the EUR 3,132.90 is, and that scanning should carry the codes.
Prompt · Measure my own keying error rate, and what my codes catch
Before buying scanners, and any time somebody argues that a code scheme is safe because most wrong codes do not exist.
Help me measure how often my store keys a code wrongly, work out which of those errors my own code scheme catches, and price the ones that get through. Start with a count and not a sample. Ask me for a year of rejected entries and of entries later found to be wrong, split by field: location, item and quantity. For each field give me the mis-key count, the number refused at the terminal and the number accepted while wrong, and work out a detection rate for each. Tell me plainly that quantity will have no detection at all, and say why: nothing in the system has anything to compare a quantity with. Then enumerate my code scheme rather than reasoning about it. Ask me for the exact format of my location code, field by field, and how many real values each field has. Then, for every real code, change one character at a time to every other value that field allows, and count how many of the results are also real locations. Give me the share per field and overall. Then tell me which fields of my code a person actually mis-keys. Drop the fields that never vary in practice and work it out again, because counting a mistake nobody makes flatters the answer. Compare that second figure with my measured refusal rate, and tell me whether the two methods agree. Then do the same for a swap of two neighbouring characters, which is a different and usually kinder error. Then price what got through. Ask me to sort every accepted-but-wrong entry of the year by what it actually cost: minutes of searching, a stopped line at my own line rate, a wrong material consumed, a shortage, a rushed purchase. Show me each class as a share of the errors and as a share of the money, side by side, and say out loud when those two orders disagree. Then tell me what a scanner reaches, expressed both ways, and warn me that a scanner has its own error rate that I have not measured, so my benefit is a ceiling rather than an expectation. Check for double counting against any searching hours I have already claimed elsewhere. Finally, before any of that, price the cheapest fix: adding a check character to my location codes. Ask how many of my accepted-but-wrong entries were single mis-keys, tell me a check character would have refused those and nothing else, and give me the cost of reprinting my labels against the line time those errors cost.
AI can make mistakes — check anything you act on.