What are your part number schemes?

Jason_S

Hi all,

Can we get some feedback on what your ideal part number schemes look like? This includes, but is not limited to how/what numbers get assigned to:

• Parts specific to a project
• Internal parts that are reused across projects
• OTS/supplier parts
• Non-geometric parts

Also, how is this managed today? Excel/Sheets? PLM? Magic eight ball?

Thanks!

adrian_vlzkz

We have a master PN scheme for our controlled product (in PLM) that uses an established prefix per category and a sequential autogenerated portion
i.e:
MT-123456 (For material)
DWG-123456 (For Drawings)

We're allowed to manually overwrite the sequential number, with the purpose of matching the sequential # to match related items. This exception is both good and bad, because it's logical, but creates inconsistencies.

I've also implemented a more "meaningful" scheme for R&D projects (typically not released in PLM system), that uses Custom Properties to auto-rename parts and assemblies in CAD. It pulls the Project Name, Product type and a unique sequential identifier, for example:

Project: Taurus
Product type: Wearable

Part Number:

   TAUR-Wx-1234

There's a master table that defines the 4 character project and 2 letter product aliases. I wish there was a way in Onshape to build this type a scheme without code.

john_mcclary

We have a 3 part code for parts

XXXX-XXX-AXXX for assemblies
XXXX-XXX-WXXX for weldments
XXXX-XXX-DXXX for details (parts)

First 4 digits are the job#
Second 3 are unit#
Last 3 are for each item

So if a customer needs a spare part, they can give us that number and it will point to the exact folder on the server. Since our server is a bunch of nested folders that use the same number scheme. 

So there is no need for revisions or tracking. Every time we get a repeat order, we duplicate the job folder (relevant info at least) then make improvements from lessons learned. 

This allows us to stay agile and make every machine custom for that customer without them worrying about revisions either. 

I also save a link to the main Onshape assembly for each unit, so Onshape also fits comfortably next to Solidworks jobs

eric_pesty

It's boring but I've been happy with our policy of just using dumb numbers: 5 digit sequential number. Never goes wrong and we just use a shared cloud XLS to keep track of assignments...

malay_kumar

Hi, Can you also provide some insights on assigning part numbers to standard content like nuts, bolts and other purchased parts? Do you use same/similar scheme for standard content and purchased parts also? Thanks

john_mcclary

We treat all purchased parts separately. 

MFGNAME-MFG#-SHORTDESCRIPTION
fasteners we just call out generically 

So
MCMASTER-CARR - 60355K708 - 1in BALL BEARING
or
HHCS (M8x1. 25 x 25 lg) 

eric_pesty

We actually ended up setting up "Vendor" and "Vendor part number" custom properties. This also allows us to "cheat" by displaying the "vendor PN" field on BOMs (and setting ourselves as the vendor for custom rev managed parts) for different configurations of the same PN (we add a dash and extra digit when needed to the Onshape part number to denote different configurations of things that should have the same PN), or to be able to use the same number for a sheet metal part and the part+PEMs.

mike_bosscher

Hi @Jason_S,

This seems to be an issue that often solicits as many different opinions as there are people chatting about the subject - I think there are reasons for that, including historical industrial practices as well as users' varied personal experiences. There's a crowd that loves and won't let go of intelligent part numbers. They have their reasons, but I also think they often haven't been shown a better way. Typically because they aren't yet in a position to invest in the additional software required.

It seems to me that intelligent part numbers originated in the drafting board days, and for good reason. Physical drawings were stored in a filing cabinet, and appending the drawing-size letter to the numeric portion of the part number (12345A for example), empowered an employee to know which filing cabinet (A size, B size, C size, etc.) to search for a drawing in. That made perfect sense at the time. With modern CAD software systems there's no added benefit, as the drawings are no longer located in a physical cabinet. When that practice is carried over to cad software, however, it hinders the designer from swapping out to a larger drawing format when needed without first pulling a new part number. Since part numbers are generally issued on drawing creation rather than completion, and designers are hesitant to pull a new number just to get a larger drawing size, this often results in either overcrowded drawings containing annotations whose text size set too small, or unnecessary additional pages that are inherently more difficult to navigate.

In the current state-of-the-industry, I presume the intelligent-part-numbering advocates' toolset is often limited to a seat of CAD software, a file server share where they store their models and drawings, and an excel document (or three) where they list all the part numbers they've created. Since there's not a robust way - when using a windows file server share as your CAD data repository - to scroll through a directory and quickly determine which drawing is associated with which model, they often use the same identification number for both the model and the drawing, relying on the file extension to differentiate the two files (there's an argument for serializing drawings independently from their models, but that's another topic of discussion entirely..). To add to that, since windows doesn't permit an easy way to quickly scan or search for a file's metadata, engineering staff are forced to include all relevant information in the file name. Being forced to incorporate metadata into the filename seems to be the root cause of these multi-component, intelligent part-numbering schemes.

While they usually work for an indefinite period of time, the problem with intelligent part numbering systems is they result in one of two scenarios; a) they're simple enough that those who use them will eventually come across a situation where there is a part number duplication, or b) they are so unyieldingly complex that they're hard to use, hard to train on, and generally present a diminishing return the longer they're employed. To add to that, they are only as "intelligent" as the person who defined them, and are often only effective as long as that person is still employed at the company.

PDM systems (which are built on a database infrastructure rather than a NTFS directory) have introduced the ability to create an incredible amount of metadata associated with each part number. This meta data lives in "Custom Properties"/"Variables" in SolidWorks/SolidWorks PDM, or in "Properties" in Onshape. All of the data that the intelligent-part-number aficionados try to include in the filename - material, vendor, project, etc. - can be, and should be, recorded in the file's metadata rather than it's filename. This facilitates sequentially issued, strictly numeric part numbers (often 5, 6, or even 7 digits, depending on the amount of part numbers a company anticipates creating over the course of it's existence). These non-intelligent part numbers can be compared to a database table's 'primary key' - it becomes impossible to have duplicate part numbers. There's no need for any prefixes, suffixes, or any other information appended, but the key to making this approach work is to have a sufficiently defined UI the users interact with. The users need to be able to enter metadata (material, project, supplier, etc.) upon new CAD file creation, which can then be used to search for said document at a later date. Without a well designed user interface, the storage repository becomes a garbage-in-garbage-out "black box" where CAD files go to die, never to be found again by anyone, aside from maybe the user who originally created them (and happens to remember the part number).

Other CAD software companies have had to step gingerly around this topic because, as stated above, PDM is often an additional piece of software with an additional cost associated with it. Without sufficient explanation/education, many customers feel they are simply being up-sold yet another piece of software they don't really understand. Worse yet, is the fact that by the time they realize they do need some sort of PDM, they've often created a large amount of legacy data requiring complex manipulation prior to migrating to a PDM system. Additionally, the training required to facilitate a paradigm shift in their staff's thought patterns is significant...

The good news for Onshape is that you've integrated CAD and PDM into one offering and, as a result, you're in a unique position to be able to educate your customers right from the start without the fear of being perceived as up-selling something that isn't needed.

That said, the fact that input is being solicited seems to indicate that the documentation could use some polishing; hopefully this was helpful.

Mike

adrian_vlzkz

@mike_bosscher In my experience the better system is more of a hybrid one, where there's some intelligence in the "Generation" of Part Numbers, but the meaning is "soft".

Think of a cars VIN number of a car, for a casual citizen is just a long number, but for the DMV, Law enforcement, and car service industry, the meaning ads a lot of value.

Not every employee in an organization needs to be trained or has to understand the meaning if it ads no value to their function, they can treat that number just a X amount of character, just like they would a sequential numeric component. 

The simplicity of a meaningless numbers has implications downstream, many department only get a PDF of a drawing and no metadata, in order for most of them the get the custom property information, also would represent adicional software cost, and in my experience when you have 300 engineers spread over 20 different teams and multiple site, you also need a software system to generate and manage the simplest of numbering schemes.

The problem with "smart" numbers is when they are poorly designed, like in the cases you mentioned; but I wouldn'y discard a concept just because it has been poorly implemented. Any data that could "change" thru the lifecycle of part, (sheet size, mfg process, site...) should not be part of a ID number for a component.

shawn_crocker

Anything that isn't a top level product, is just a dumb number that has no meaning.  Our designers are not allowed to create part numbers for the top level product.  Our company seems to think the sales team should do that.  They have this ridiculous coding system that basically breaks all it own rules with any product that is custom built.  We designers are constantly having to go back into a product and obsolete the top level part number and change it to something else because sales messed it up.  And incredibly, every time it happens(almost every day) they truly believe, whole heartedly, that the change is completely necessary and there is know other way that could possibly be better!  And the thought is that somehow, people making stuff, who have a full suit of drawings before them, detailing everything they need to know to manufacture the thing, will somehow get confused because the part number doesn't line up with logic they are barely aware exists!  I constantly here conversations in the context of the idea, "we really need to straighten out our coding system and improve its logic".  On countless occasions I have attempted to impart a simplified logic supporting the advantage and ability to simply let part numbers be and focus on what is important.  What you want at the end of the day is to be able to logically sift through stuff and find what you need.  If you create logic in a part number, that need is still met but increases paperwork loads when something needs to be reassigned or recategorized.  You can also create that same logic in a description property or possibly create special properties that represent the categorization groups you are needing.  Then, when a change needs to be made to the categorization of an item, it is beyond the revision controlled system and can just easily be edited without having to edit a long revision managed trail.

john_mcclary

@shawn_crocker

Never let the sales team manage anything! 

The Engineering team should create and manage all parts and part numbers. If the sales team wants to create a part number that noly makes sense to them, then have them create a spreadsheet or something that points to the actual part number. 

shawn_crocker

john_mcclary said:

@shawn_crocker

Never let the sales team manage anything! 

The Engineering team should create and manage all parts and part numbers. If the sales team wants to create a part number that noly makes sense to them, then have them create a spreadsheet or something that points to the actual part number. 

Totally agree! There reasoning is that somehow there customers apparently expect to get a part number immediately which is very questionable to me.  The wild thing about how our top level part numbers are created is that even the overall dimensions of the product are included in part numbers.  So any change that is made that changes those dimensions means the part number keeps changing all through the development.  Of course, the drawing number remains the same so there is something that is tying the development together but still, it has always seemed Ludacris to me.

adrian_vlzkz

shawn_crocker said:

john_mcclary said:

@shawn_crocker

Never let the sales team manage anything! 

The Engineering team should create and manage all parts and part numbers. If the sales team wants to create a part number that noly makes sense to them, then have them create a spreadsheet or something that points to the actual part number. 

Totally agree! There reasoning is that somehow there customers apparently expect to get a part number immediately which is very questionable to me.  The wild thing about how our top level part numbers are created is that even the overall dimensions of the product are included in part numbers.  So any change that is made that changes those dimensions means the part number keeps changing all through the development.  Of course, the drawing number remains the same so there is something that is tying the development together but still, it has always seemed Ludacris to me.

Yikes!