How a business decides to identify data is often a topic for much debate. Over the years we at OnePLM have gained experience through discussing this with our prospects and customers and also aligning the configuration of Siemens Teamcenter PLM to meet their needs.
Initially, typically the business thinks that they should have “Intelligent” part numbering. This is where at least a section of the part number identifies something about it. Typical requests are things like “Project ID”, “Part Type” or maybe “Machine Section”. Some section of the number will always be a clock count of some sort, so we may end up with something like “X123-024-13-00542”. This may indicate, to someone in the know, that this particular part is used on project X123, is of type 024 (which, say, means it’s a Hydraulic Cylinder), on machine section 13 (which, say, means front dozer) and 00542 is just a generic count.
This all seems well and good at first glance. However, as already indicated, this is fine to someone who knows what it means. To new starters, your suppliers and the outside world it is probably meaningless. What’s more, if a part is accidentally given the wrong category, e.g. Part Type or Machine Section, then it’s too late, that number is for life. I’ve seen it myself where a particular combination of code would give the pressure rating of a hose, and yet taking a sample of hoses found that several effectively had the wrong part number. This led or could have led to confusion, misuse and even possibly performance or safety related issues.
Having the Project as part of the part number is a very typical requirement. But again, that component or assembly may eventually get used on multiple assemblies in multiple projects, so it really ends up being a “Project first used on” and how much use is this really?
All that said, of course Teamcenter can be configured to facilitate these requirements to some extent, if that’s what the Business really wants. Using the Intelligent ID Generator, various runtime properties can be combined along with a clock count to provide a concatenated part number. In the example below, we can see how the use can select from a set of drop-downs that contribute to the part number.
Having populated the codes, along with any other required attributes, Teamcenter then concatenates these along with any other rules or counters to form the part number. So using this example…
May result in the following Item in Teamcenter…
There are limitations that the reader should be aware of, mainly that the properties are just runtime, i.e. are not persistent, and also a separate concatenation rule is required for each clock count combination required which can mean a lot of configuration. The other big limitations are that this is not supported in the SaveAs process and also is not available in the CAD integrations, which means parts have to first be created in the Teamcenter client prior to working in CAD
We recommend that best practice is to just have a generic number count. This could include some fixed text if required, so something like ACME000542. If different part types (eg Manufactured, Purchased, Standard, Document, etc.) are required, then it’s fine for these to have a different pattern, e.g. PUR000542, MAN000542, etc. By having a longer generic count the business has the ability to iterate designs by creating as many parts as required without the fear of “wasting part numbers” within a shorter intelligent range.
Here is an example of selecting from multiple patterns…
Having multiple patterns is also supported in operations such as SaveAs and also works with the CAD integrations, now including NX at version NX12.
By using fairly generic patterns like this, the room for error, misuse or mis-information is reduced. Instead then, the part information can be enriched with other Teamcenter attributes. Individual properties can easily be reused downstream, in searching, reporting, or drawing border population. They can of course be changed under revision control through the lifecycle of the part. Regarding Projects, through the use of Teamcenter My Projects, parts can be associated with none, one, or more projects, not only giving visibility and flexibility but also allowing access control permissions to be applied. Thirdly, through the use of Teamcenter Classification, parts can be “pigeon holed” into a class and given attribute values pertinent to that class, so for our Hydraulic Ram example above this might be Bore Diameter, Rod Diameter, Stroke, etc. This promotes design reuse through better searching, and as the cost associated with each duplicate part number for its design, detailing, costing, manufacturing, storage and service is typically estimated at up to £10,000, it soon pays for itself.
So to summarise whilst Teamcenter can, with a few caveats, be configured to cater for most part numbering requirements, it is definitely best practice to use a relatively “dumb” number sequence enriched with attributes, projects and classification.