If you do a little searching around the net, there are many discussions on the subject of internal company part numbers. Many of the discussions center around the great debate of intelligent part numbers vs. unintelligent part numbers. I’ll dive into that discussion a little later on. One of the interesting things I have found is that the term “Part Numbers” often is used as a general term for internal numbers representing both parts AND documents. Depending on your perspective, they can be quite different.
In many companies with more traditional number systems in place, the drawing number and “part number” are shared. The difference between the instances are often “dash” numbers added to the end of the unique identifying number. For example, a drawing number would be 200345 and the part number for the item detailed in the drawing is 200345-001. To add another flavor to the mix, variants of the part itself are often detailed on the same drawing. 200345-001 might represent the part with a blue paint applied and 200345-003 might represent a green painted part. This no doubt can be handy in that changes to either part can be quickly made through a single drawing. This makes a lot of sense when you have “families” of parts that are similar and the design of these parts are tied together.
When you take traditional approaches such as this and introduce the data into a PLM system, this is where things can get interesting. The process I mentioned above has been in use in various forms at the company I work for for many years. Currently I am working on defining how our SolidWorks data will be stored in our soon to be implemented PLM system. SolidWorks Enterprise PDM (EPDM) will also play a role in this process, but will mainly be used as the MCAD data vault whose sole responsibility is to track the versions of the CAD data only. One of the things I am interested to know from some of you our there is how you are doing this. Our current train of thought would be to name the SolidWorks model (part or assembly) by the unique identifying number. Examples would be 200345.sldprt and 200345.slddrw. The variants (if used) would then be stored as configurations inside the Part or Assembly model.
In more traditional systems, a revision to the Drawing would be considered a revision to the part. When you organize your data simply from a CAD standpoint there are many situations where this would make sense. A “side effect” of this though is that if you have variants for the model (i.e. 200345-001 & 200345-003), BOTH variants are often considered “revised” even if the change to the Drawing only effects one variant and not the other. This is where the PLM system can add some capability in that it has the ability to track revisions of items, yet treat the CAD data as “reference” data used to build or manufacture a part. Essentially, it can track the part itself and the CAD data for the part SEPARATELY. In our example noted above, the PLM system can have separate entries for the variants (200345-001 & 200345-003). If a change is made to 200345-003 (lets just say a color change in the paint) that doesn’t effect the 200345-001, then the CAD data (200345.sldprt and 200345.slddrw) would be revised with CAD revisions synced for both model and drawing. The revision to the items (separately stored) in PLM does not have to be incremented for the part that did not change. (200345-001 would still be at the original revision). The upside to this is that handling the disposition of any parts in production or on the shelf is much easier in that you don’t have to make unnecessary revisions to components that have NOT changed. The downside to this is that if someone picks up a drawing and sees a “Revision A” on the drawing, they can no longer assume that each variant (200345-001 & 200345-003) in the form of a final “part” is at the same revision. In this case, the documentation has been revised but only one of the the two items in PLM have received a revision as a result to changes in the documentation. Notation CAN however be put on the drawing to indicate this, but the biggest difference is that the PLM system will have to be the controlling authority on revisions of the component itself. This is can be a big change for anyone that touches a component during the manufacturing process. The biggest hurdle often is training people to separate items or “parts” from the documentation used to create them. CAD data whether it is a 3D model or a drawing is still documentation used to create the final item.
So…after this long winded explanation…I get to one of the points of this post. I’d like to hear how some of you have dealt with this when taking your data from the CAD/PDM world into the PLM world. In particular, are you using configurations for part variations or do you treat variants as separate part files? I’ve read where some companies get rid of variants altogether when using PLM. (Personally, I think we would be giving up a lot of flexibility if we did this.) I’ve even seen scenarios where CAD data is stored as a completely separate unique number altogether. (Although it may sound foreign to some, I can see how this could work.)
So now…I turn it over to you. I’d like to hear some of your experiences in this area if you have the time to share it.
Stay tuned…more to come!