Part numbering conventions - what's the best practice in aerospace?

[chrebmo]

Hi everyone,

I was having a discussion with an aerospace partner recently about part numbering conventions in PDM systems, and it got me thinking - how do different organizations approach this challenge?
One approach I've seen is a hierarchical naming scheme that embeds mission/project context directly in the filename structure, something like:MISSION_PARTNO_NAME_REV.SUBREV
For example: PROJ-A_4301-01-00_ReactionWheels_01 or PROJ-A_32010200_PCBBottom_01.01

Where the 8-digit part numbers create a hierarchy (4000s = platform, 3200s = power, etc.) and COTS parts get handled separately.

It seems like aerospace has some unique challenges compared to other engineering sectors - the mission-critical nature, long product lifecycles, and traceability requirements. I'm wondering if this drives different approaches to part numbering than you'd see in automotive or consumer products.

What approaches have you found work best for your organizations?

Some follow-up thoughts: Do you embed project identifiers directly in part numbers, or rely on the PLM system to manage those relationships? How do you handle COTS integration? Any thoughts on hierarchical vs flat numbering schemes?

Would love to hear about your experiences, especially if you've been through PLM migrations or evolved your naming conventions over time.

Thanks!

 

[chrebmo]

Wow, this discussion has really taken off - thank you all for the additional insights!

@CWB1 - Your point about "5-6 alphanumeric, random digits is the norm" and that "smart part numbers are among the dumbest, most costly ideas" reinforces what several others have mentioned about keeping numbering simple.

@verymadmac - Your response about the "controlled data vs uncontrolled data problem" makes a lot of sense. The chopping board example shows how COTS management can get complicated, and your point about small teams needing to "do 2 things well rather than 3 things poorly" seems very practical.

@MintJulep - "The more rules you try to apply to a numbering system the more likely a future case breaking the system becomes" - this seems to capture why rigid systems often fail when requirements change.

@TugboatEng - Your point about "part number databases are instantly accessible" and keeping information out of the numbers aligns with the database-first direction this discussion is taking. The communication considerations about B's vs V's are important practical factors too.

@IRstuff - The barcode approach for removing human error sources is an interesting way to handle the reliability issue.

@RoarkS - Your frustration with "born on date" part numbers and the uniqueness problems with multiple creators highlights some real implementation challenges.

@drawoh - Your PDM setup approach is particularly relevant to me. The way you've structured descriptions like "SCR CAP BTN HD HX SCK STL ZN PL M6X1X20" to enable sorting by hierarchy, combined with your approach of "dumb numbering systems" with "intelligence in database fields," seems to align with where this discussion is heading.

I hope you don't mind me mentioning - this conversation has been really eye-opening for me as someone who's been working on software in this space. We're trying to build a system that's designed around flexible configuration, with the hope that organizations could maintain their necessary conventions while getting better search and data management capabilities.

@drawoh - Since you've set up PDM systems, your structured description approach is something we're looking at how to support more systematically. Rather than forcing one approach, we're exploring how to make different naming conventions work better within a database-first framework.

The challenges you've all described - maintaining master lists, limited search capabilities, systems that don't adapt well to changing requirements - these are areas we're trying to address while still allowing organizations to work within their existing constraints and approval requirements.

If there are people interested here, I'd be happy to share some of the concepts we're working on directly in this discussion. Would be particularly valuable to get your critique on whether we're actually addressing the issues you've raised, or if we're missing something important. It seems to me that of all the professionals out there, engineers have had the least airtime by the software developers who develop software for them - it is really incredible just how in the 90s most solutions are in.

Thanks again for such a valuable conversation! Really rewarding to geek out in such detail, key will be about deriving the essential - because it does feel that some of the underlying technologies for any PDM / PLM has much better chances to rethink some fundamentals than before.

 

[chrebmo]

Wow, this discussion has really received some great contributions here - thank you all for the additional insights.

@CWB1 - Your point about "5-6 alphanumeric, random digits is the norm" and that "smart part numbers are among the dumbest, most costly ideas" reinforces what several others have mentioned about keeping numbering simple.

@verymadmac - Your response about the "controlled data vs uncontrolled data problem" makes a lot of sense. The chopping board example shows how COTS management can get complicated, and your point about small teams needing to "do 2 things well rather than 3 things poorly" seems very practical.

@MintJulep - "The more rules you try to apply to a numbering system the more likely a future case breaking the system becomes" - this seems to capture why rigid systems often fail when requirements change.

@TugboatEng - Your point about "part number databases are instantly accessible" and keeping information out of the numbers aligns with the database-first direction this discussion is taking. The communication considerations about B's vs V's are important practical factors too.

@IRstuff - The barcode approach for removing human error sources is an interesting way to handle the reliability issue.

@RoarkS - Your frustration with "born on date" part numbers and the uniqueness problems with multiple creators highlights some real implementation challenges.

@drawoh - Your PDM setup approach is particularly relevant to me. The way you've structured descriptions like "SCR CAP BTN HD HX SCK STL ZN PL M6X1X20" to enable sorting by hierarchy, combined with your approach of "dumb numbering systems" with "intelligence in database fields," seems to align with where this discussion is heading.

I hope you don't mind me mentioning - this conversation has been really eye-opening for me as someone who's been working on software in this space. We're trying to build a system that's designed around flexible configuration, with the hope that organizations could maintain their necessary conventions while getting better search and data management capabilities.

@drawoh - Since you've set up PDM systems, your structured description approach is something we're looking at how to support more systematically. Rather than forcing one approach, we're exploring how to make different naming conventions work better within a database-first framework.

The challenges you've all described - maintaining master lists, limited search capabilities, systems that don't adapt well to changing requirements - these are areas we're trying to address while still allowing organizations to work within their existing constraints and approval requirements.

If there are people interested here, l'd be happy to share some of the concepts we're working on directly in this discussion. Would be particularly valuable to get your critique on whether we're actually addressing the issues you've raised, or if we're missing something important. It seems to me that of all the professionals out there, engineers have had the least airtime by the software developers who develop software for them - it is really incredible just how in the 90s most solutions are in.

Thanks again for such a valuable conversation! Really rewarding to geek out in such detail, key will be about deriving the essential - because it does feel that some of the underlying technologies for any PDM / PLM has much better chances to rethink some fundamentals than