Even for the most experienced CAD user, understanding Teamcenter BOM Revision Rules can be a major challenge. Without a full understanding of the logic behind Revision Rules, a particular component in an assembly can easily be configured with the wrong revision level. When confronted with a dozen rules (or “Load Options”, in the case of NX), a user typically will lean over to his/her neighbor, who says “just use this one”. Unless you understand what Teamcenter is doing, it can be like a Box of Chocolates…you really never know what you’re going to get!
Not implementing a fool proof strategy for your organization will almost always result in product or production issues, especially if Teamcenter is used by non-Engineering users!
Out Of The Box, Teamcenter has some standard revision rules configured. Without doing a little “filtering” of these, they will add to confusion and information overload. New users must deal with new terminology such as “Released”, or “Statused”, or “Vaulted”. These could mean the same thing, or something completely different depending on how Teamcenter was implemented. the OOTB rules will probably not work unless your implementation proceeds with just one valid Status for Item Revisions (such as Released). A Teamcenter Administrator can delete any unneeded rules, or modify any existing as needed.
Revision Rules can be defined in so many different ways, an organization must define a PLM Lifecycle strategy before they begin using Teamcenter. Often this is impacted by data which is imported into the system at implementation time. For example, has there always been a consistent policy regarding assignment of revision identifiers? A collection of Item Masters resulting from years of company acquisitions could have a mix of alpha, numeric, alpha/numeric, or anything else imaginable. Without a clean strategy, this could eliminate the use of just one type of rule such as “Latest Alphanumeric”. Of course if you’ve implemented a set of Statuses to control your Part Lifecycles, the Revision ID is really of no importance…except for those pesky users outside Engineering.
There are as many ways to implement Revision Rules as Carter has Pills. Item Effectivity, data ownership, data type, data read access, and lifecycle phase are just a few of the methods that can be used. Teamcenter can also let you mix and match all of these to your hearts content. The strategy certainly varies by industry, but can easily vary by Product Line or Location within one company. And of course, you can avoid Revision Rules all together by configuring your assemblies as Precise…or can you? For an “under the covers” look at how Teamcenter implements Revision Rules, look for a blog coming soon at SiOM Systems called “Revision Rules Revealed”.
How have you implemented Revision Rule? Include a brief explanation of how and why. This might get the wheels turning in somebody else’s head in regards to how they can improve their strategy.
Hello Don,
Interesting discussion. My opinion is if you leave it to the end user, they will end up with a lot of mess. For me the best way is that the business should set up rev rules per group. Some more experience users can select between some rev rules. The rest should only use there defaults.
To save an assembly (im)precise is also a nice discussion that can confuse the average user. I prefer to use a workflow to set a status and at fhe same time make the assy Precise.
I am waiting for the next blog about this topic.
Regards,
Menk Slot
I agree Menk,
Limiting on a group basis is clean and simple for casual users.
Those “experienced” users are often a challenge. That usually means the CAD folks that have worked in native all their lives. It takes some focused training and hand holding to get them up to speed.
Don
I don’t think there’s anything in Teamcenter that causes as much confusion as revision rules. They’re powerful, if you know how to use them. That’s a big if.
And for extra fun, try explaining the difference between a Precise BOM and an Imprecise one.