Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

IT's dumb fight over intelligent part numbers

David Taber | June 8, 2015
In a battle as old as ERP itself, users demand intelligent numbers that the IT team bucks against. The battle pits “intelligent” numbering systems that embed key identifying information against generic numbers that are easier to manage, remember and communicate. In this argument, it's the IT pros who are wrong.

confusing vs intelligent part numbers

We've seen it all before:  Whether it's a part number, an account number, an order number or an identifying number for nearly any real object, the users ask for a number that isn't abstract, arbitrary and essentially meaningless. They ask for numbers that are short, significant and "intuitive" for the business user. Because they ask for the wrong thing, the IT pros always give them the wrong answer. That's the inevitable outcome of asking the wrong question. 

Now it's not as if the cloud has somehow invalidated the laws of physics or part numbers. Numbering and naming of things is one of the few IT topics that has remained true over decades.

What has changed is the cost of storage and computation: redundancy and denormalization is essentially free, as long as it's automatically maintained. 

The beauty of human-optimized numbers 
Given that magnificent (and continuing) declining cost curve, we can now afford to have it both ways. We'll keep with the impossibly long (and hard to remember) identifying numbers/strings that IT has already built, and those will be used as the foreign keys for all the tech. But now we can add a number designed just for humans, and which all areas of our tech are told to ignore. 

So what are the characteristics of these human-optimized numbers?

  • They need to be short enough to remember, at least for the length of a phone call
  • They need to be easy enough to read into the phone, and to copy down correctly even with a crummy phone connection. This means "case insensitive."
  • They should not use punctuation, and they should be impervious to extra spaces. So "300 452" should be the same as "300-452" or "300.452".
  • The non-numeric part of the string shouldn't be arbitrary characters, to minimize the effect of dyslexia and typos. The characters in the string should be from defined lists, if possible.
  • The strings should try to avoid characters that are easily confused in case of bad handwriting. So "5" shouldn't be intermingled with "S," "1" with "I," "0" with "O" or "2" with "Z" (unless you live in a country that crosses the zed).
  • The good news is that they can be of variable length, because humans aren't picky parsers. So you can suppress all the leading zeroes. 

More good news:  the human-optimized numbers don't have to be persistent for more than a quarterly cycle. Numbers also don't have to be unique across all time (i.e., they can be recycled if needed). Why?  Because in most of the use cases, the number is used only in the present tense. It's rare that it even needs to be printed out. So if one of those numbers change, the humans won't remember the old one anyway. And they always have the IT-mandated persistent numbers for cross-referencing. 


1  2  Next Page 

Sign up for Computerworld eNewsletters.