IT's dumb fight over intelligent part numbers
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.
[Related: How cloud-based ERP can give your business a boost ]
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
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.
[Related: 9 tips for selecting and implementing an ERP system ]
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:
<CountryCode>-<Truncated Acct#>-<ChannelType>-<UltimateParent Truncated Acct#>
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:
<CountryCode>-<Truncated Contact#>-<CompanyType>-<Truncated Acct#>
And for Opportunities:
<CountryCode>-<Truncated Oppty#>-<Transaction Type>-<Truncated Acct#>
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.
[Related: Quick and dirty is a sure way to fail at social CRM ]
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.