<< Back to article Print this page Loading page, please wait...

IT's dumb fight over intelligent part numbers

David Taber (CIO (US))
06 June, 2015 00:39

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.

Finally, the human-optimized numbers can be automatically generated out of data already in the system, so they can be refreshed on demand. (That said, it's generally a good idea to not change existing numbers until the end of the quarter...somebody may have written it down on a sticky note somewhere.)

In a real-world example, a client uses 9-digit customer numbers as the external key for accounts. However, they only have five digit's worth of customers, and over half of them can be represented with four digits. Most of the accounts have parent-child relationships, and sales would like to be able to quickly detect some basic account characteristics without looking at detail records. So we created a formula in the CRM system that synthesizes an account number for human use only, using this format:

A typical account number might look like this:

US-1547-DIR-34320

An ultimate parent company (which by definition has no parent) looks like this:

US-34320-DIR

The same formula-driven approach works for Contacts, like this:

And for Opportunities:

Similar approaches can be used for nearly any object that humans need to confer over, such as products, shipments, cases, and payments

Exposing your identifiers

To be truly useful, these human-optimized identifiers should be available for display by sales, support and operations people across as many systems as possible. So they should be exposed to external interfaces and published on information busses, even though no business logic should use them.

One of the side-effects of using this approach is that it exposes data quality problems that were easily ignored (or even hidden from view). Every time a human uses the formula-generated number, they may spot a discrepancy that is glaringly obvious under the lens of common sense. With these formulas, even IT may be able to appreciate the value of the formally-despised intelligent number.