Today’s discussion involves one of the most seemingly intractable arguments in Product Lifecycle Management (PLM): the ageless battle between part numbering philosophies. In one camp you have intelligent part numbering schemes begat by the first ones since time immemorial, where identifying information is compacted into part ID’s. The other faction champions coldly efficient, and generally arbitrary system-generated numbering.
Some consider this particular argument a dead horse, but like many topics in the PLM space, I’d consider this one more of a zombie horse. It keeps coming back to life, and if you’re not careful it will eat your brains. Not a day goes by without me reading a compelling argument about system generated part numbers in the morning, only to read about someone desperately customizing a system to handle complex part numbering schemes in the afternoon. Why does this happen?
Often, the disparity is dismissed as collateral damage from political and cultural backlash commonly associated with PLM implementation. However, that’s something I refuse to accept. Rather, a central flaw in this dichotomy is that it is a battle of absolutes.
The proponents of arbitrary system-assigned ID’s make a solid argument:
Part numbers are irrelevant. Resistance is futile. We will add your biological and technological distinctiveness as metadata.
System architects take the accurate stance that PLM systems are relational to the core, and that a part identifier has no significance because particular parts can be located and referred to by the attribute data and classifications that define them. A further argument is that users creating new parts often do not have the information nor the time to ensure their new part correctly complies with an established part numbering scheme. Finally, there is also the tendency for even the most carefully crafted intelligent numbering scheme to breakdown over time, as new part categories, classifications, and differentiating attributes are introduced.
The intelligent-numbering camp responds:
I’m a human being for crying out loud and not a bucket of circuits, if I’m holding something in my hand or I’m in the middle of a meeting I need to have some idea what the hell it is!
Proponents of intelligent numbering argue that it’s not about mapping the life history of something to its part number, but rather making the part easily and readily identifiable. They argue that finding parts on attributes alone is a perfectly sound concept… for a utopian pipedream. They add that real implementations don’t have easily accessible information at all times – especially when multiple systems are involved. Even for someone already logged in and with hands at the keyboard, the tools themselves tend to have rather terrible search interfaces that require switching screens or otherwise moving away from the task at hand. Google this is not. Not to mention many parts share very similar attributes. Do you really feel like sorting through all of them every time you need to tell these parts apart? And when you have to finally communicate with a human – do I hand you this part or that one – was that 5667767 or 5667667?
So how does this translate to actual practice? Most implementations initially start with the notion that part numbers should be system generated, but culture and legacy process often overcomes that notion. Before anyone realizes it, they are soaking in a customization nightmare on object creation that leaves users perplexed, and system admins constantly cleaning up one mess after another. Often it’s a legacy part numbering system that gets jammed in there.
The problem becomes amplified thanks to the fact that:
- The object creation interfaces are terrible. Yep.
- Changing P/N’s is often a huge hassle. Root canals tend to be preferable.
- Everyone is pressed for time. And angry. Especially that last part.
So once a critical mass of botched part numbers is reached, then the pendulum swings in the other direction, and structured part numbers are wholly abandoned for sequential numbers. Users just deal with the fact they’re going to be doing a lot of searching and attribute filtering. It’s all for the better – it’s the wave of the future, after all. Oh and arbitrary system-generated part numbers is commonly quoted as best practice by this and that, so what could possibly be wrong with that? Silly engineer, significant part numbers are for kids! And besides, the new mobile solution will fix everything (including global warming)! Heard this before?
I always laugh when so called best practice for a business problem is framed squarely in the limitation of existing tools. Let’s focus on the problem. How do we create easily identifiable and significant numbers without front loading the process with so much hassle and confusion?
Easy. Don’t bother with defining a P/N at creation. At all. Wait, what?
That’s right… let the users just get started generically – they may not know what they’re ending up with anyway. Let the data types and attribute information define the part number based on set rules over time as the data develops. Let part numbers evolve. Ultimately the identifier shouldn’t matter to a db, the object is tied to everything via relationships anyway. Then at a glance – during approval you can quickly tell if a part is fully cooked yet – surely that helps. In the end you end up with all the intelligence and none of the hassle.
The catch is such an approach is mostly impossible with most PLM systems because they demand part numbers up front and changing P/N’s multiple times is all too painful. But don’t let such a limitation sour future innovation.