Best Of

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