PartNumbersInSpace

Part Numbers Are Dead, Long Live the Part Numbers!

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:

  1. The object creation interfaces are terrible.  Yep.
  2. Changing P/N’s is often a huge hassle.  Root canals tend to be preferable.
  3. 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.

  • jan takke

    Your proposal replaces dogma by reason…. I’m with you!

  • Ross Bernheim

    PLM can indeed be a wondrous thing. But by the time a company decides to implement a PLM system. They already have parts and a part numbering system.

    So you need to work with the hand you are dealt. It is easy to end up having to deal with multiple different part numbering systems at the same time.

    • Well said Ross, often the die is cast and systems must adapt!

  • Ross Bernheim

    Number systems can be quite useful if thought out ahead of time and people stick to the system. This means controlling who can add new numbers and having a predetermined organization as well as keeping it simple enough that everyone can understand and use it.

    The problem comes in creating a system that can easily be sorted correctly.

    An example is a PO numbering system that holds more than just a sequence number. Encode the date, taxable and what PO of the day. M1022-P-01 would be the date with M being the 13th year of the alphabet, P is for parts for resale (no tax), and 01 the first PO of the day.

    A part numbering system that is both people friendly and computer friendly is difficult. People don’t do well with long strings of numbers and or letters .The phone number is a system that encodes different information in its form. 3 digits for the exchange and 4 for the individual phone in that exchange. A number for the country code followed by a 3 digit area code then the standard 7 digit code. String the numbers all together without the format and it is very difficult to remember as a single string of digits.

  • Your evolving-part-number proposal is interesting. In concept it’s not altogether different than the create the part with a dummy ID and then change it later or save-as to a new ID that I’ve seen implemented. It really shouldn’t be that difficult of a technical challenge. I know in Teamcenter (the only system I’m qualified to comment on) that the ID isn’t the actual primary key in the underlying database table. There’s actually a UID field that you never get to see under normal circumstances that uniquely distinguishes each object.

    If you’re going to have evolving part numbers you should probably have the possibility of evolving object type as well.

    There is a subtle way that Teamcenter, and I imagine most of the PLM systems, encourage generic part numbers. When you create a new item you have to first select the type of item you want to create, and then based on that you get to either enter or generate a part number that conforms to the rules for that type. Someone who is using a “magic” part number that carries identifying information in itself is first forced to think about what item type will give him the ability to generate or enter the number he has in mind. A more natural way to work with those type of numbers would be to enter the number you want first and then let the system figure out what item type is correct for that number. Picking the type first lends itself more naturally to auto-generating the next number for that type.

    • Now you’re playing with power, Scott. A malleable object type would go hand in hand with a malleable part number. It’s certainly not rocket science, but specific implementations of current platforms have made doing so much more difficult than it should be.

      For example, it is true that UID underneath is the real unique identifier in TC, but the system behaves poorly with respect to either collisions of the user facing part number, or operations seeking to frequently change that number. That’s mostly because the original design intent was rather Borg-like. We’ll see if Multi-Field Key (MFK) alleviates some of that, but the TC Engineering roots of Unified shows true here.

      There are internal and external tools for changing item types, but they have their limitations and are unwieldy. A change in type should be as transparent to a user as a change in a hashtag.