How to manage Document versions, revisions and Part numbers

Identifications, Part Numbers, Documents, Revisions. Despite initial simplicity these terms are often create confusion in organizations and lead to additional misunderstanding. Design and Motion blog post When a version is just a version and a revision is more made me think again about differences between document revisions / version and part lifecycle. In my earlier post – BOM 101: 5 “Don’ts” for Bill of Materials Management, I’ve been talking about differences between Part Numbers and Document Numbers. One of my “don’t” recommendation was not to use the same numbers for documents and parts. Design and Motion article gives a good explanation why it is important. Every PDM system (article speaks about Autodesk Vault, but it will be similar for other PDMs) is allowing to use revisions and versions for CAD and other documents. Here is passage explaining the difference

A version is an iteration, something that is different than before.When programmers develop software a version is typically a minor software update, something that addresses issues in the the original release but does not contain enough to warrant a major release of the software. A revision is a controlled version. Webster’s dictionary describes a “revision” as the act of revising, which is to make a new, amended, improved, or up-to-date version. Back to the software analogy, a revision is seen as a major release of the software. Something that introduces new features and functionality, as well as fixing bugs. In the engineering world we use revisions to document the changes so that anyone can understand what was changed. Versions are usually temporary, revisions are permanent. What I mean by this is that during the design phase I will quickly build up versions of the design, however 5-years from now I will only care about one version, the one that was released.

So, typical document (e.g CAD assembly or drawing) will have document number and additional version / revision. One of the common mistakes (especially in small companies) to use document number as identification for parts. This is wrong. The right identification for parts is Part Number. Parts have no versions and revisions. The lifecycle schema for parts can contain revision as a property as well as reference to document (including document revision). In order to manage differences between part and lifecycle, companies are using interchangeability model. Usually, unique part number is identifying part until both parts can be mixed in the same bin location. As soon as next design or other change will make a change, new part number will be assigned to the part. Two parts can be considered as “interchangeable”. It means the functional and physical properties are equivalent in performance, reliability and maintainability. Based on that, two parts can be used without requiring special procedures (such as selecting for fit or performance) and without altering the part itself or any other part. In addition to Part Number, lifecycle status can be applied to the part to identify the level of maturity. Typical examples of lifecycle statuses are – pre-release, production, last time buy, obsolete and some others.

Management part lifecycle is completely different document versions and revisions. These are separate processes. The alignment between them can be set by assignment of specific document revision to be related to design of a specific Part (Part Number). This relation can be set inside of PDM/PLM system (in case system manage both documents and parts). In case part lifecycle managed by another system (e.g. ERP), that system will be responsible to establish relationships between released documents (drawing) representing a specific Part number.

What is my conclusion? Despite visible simplicity, it is absolutely important to separate document and part lifecycle in every PDM / PLM implementation. Document number and Part number cannot be identical. The special mechanism allowing linking between specific Part (number) and released document (including revision) should be implemented. It is important to set this rules from the early beginning to prevent future part / documents management mess. Just my thoughts…

Best, Oleg

Share This Post

I’ve always liked to think of it as a “version” is just an iterative change, whereas a “revision” is generally more of a formalized change. As you said, one major product release to another usually involves a “revision” of the documents which apply to it. Those documents then go through as series of iterations (versions) until they are frozen (or “released”), at which time there are generally no more changes allowed unless a totally new revision is created. However, there can be exceptions.

beyondplm

I think most of implementations doing well with versions/revisions concept. However, when it comes to Document numbers and Part Numbers things are getting complicated. In my view, it is important to understand the different and not to mismanage it. Part Numbers stay separate. Any “naming” connection between PN and Document leads to complexity. However, PDM systems that capable to manage them separately are complicated too. Just my opinion… Oleg

Maher Rai

I agree with you, however, the PLM tools (e.g.DS and Wind-chill) have a required
field for the revision on the part number object which leads to
confusion. Especially when you have two objects (drawing and part) which have separate revisions?
For an internal manufacturing site, which would you follow and build? Furthermore, you created a purchase order to allow a supplier to build part number xxx with revision y per drawing ZZZ with revision C. Do we need a legal
advisor to solve the issue if there was nonconforming…? Maher

beyondplm

Maher, you are right, these things are confusing. I’ve seen different practices of PN usage together with revision. The most consistent assumed that PN is so-called “base part number” and Rev used for uniqueness when interchangeable PN produced. Most of these practices are coming from before-computers ages. I think today, most of usages are in situation when company is using two non-integrated systems.

Parts can be revised – but only if the revision is interchangeable from a form, fit, and function standpoint. That means revisions can be comingled in the same supply bin and it won’t matter. Keep in mind that another reason revisions exist for parts is the part *record* might need to change (meta data for example) even though the part itself has not.

In Maher’s example, from a legal standpoint every revision of Part number xxx is the same, if that’s not the case – then one of those revisions is *not* interchangeable and someone messed up. The PO would only specify the part, not its revision.

Where things get confused, is manufacturing types, being human, often try to match revisions of documentation and parts, which doesn’t buy you anything because they aren’t really related.

beyondplm

Ed, I’ve seen the confusion you mentioned between Doc and Parts many time. That’s why I’m a big believer in different PN and DN patterns. Thanks for your example! Oleg

I would like to contribute a bit to the
confusion. Of course documents and parts are different things. Everybody can
tell whether he sees a part or a document. As long as they are physical (paper
documents and iron parts) there is no problem if they are identified with the
same number, but when they are digital and virtual (the CAD model and the part
master item) they must have different ID’s to be able to manage them in the
same database. Important is that it must be possible to refer to parts in discussions and decisions
long before any physical instance has been produced.

Concerning versions and revisions: I see no
difference. The point is that design processes are iterative. As long as
intermediate results are not to be shared (as in traditional sequential
engineering) there is no problem, but with concurrent engineering and frequent
sharing of intermediate results, it is crucial to have proper identification of
those intermediate result. Version numbers are made for that. They must be
ordered to make clear which one replaces what. Versions will do, no need for
revisions.

With respect to documents and parts: both are
versioned, because both develop in an iterative way. Just new versions of documents
emerge at different point in time than new versions of the corresponding parts.
A document needs a new version when the last version has been read or used by
some parties and when a change is to be made. It must be traceable what design decisions
have been made upon what content. A part needs a new version when one or more
physical instances have been produced and a change is planned such that any
party in the life cycle must be able to distinguish old from new instances. It
needs no explanation that document versions and part versions originate at
different points in time, so they must be really different entities in the
product development discourse.

What was missing in the discussion so far is
Status. Versions have status to indicate the allowed use of the item. Documents
typically can have status InWork or Released. InWork means that the content may
contain errors and thus may only be used as indication of for comment. Released
means that the content has been verified and validated, may be used for its
full intended purpose and that the releaser is accountable for consequences of
eventual errors. It is clear that for status Released the change process is
more formal than for status InWork. There may be more statuses when concurrent processes
requires more fine tuned control.

Parts typically have status Design or
Production. When the part has status design, only prototypes may be produced
and they only may be purchased or used for test purposes. Status Production
means that the part may be produced to fulfill customer orders or may be
purchased according to planned need. Intermediate status may be defined when
more concurrency between design and production is required. The second reason that
documents and parts have different identities is that they change status at
different times.

So far no need for revisions. However, in design
chains coordination is required between different companies, who have different
version and status numbering conventions. Especially in supply networks it is
practically impossible to have one convention for all participants. Therefore
it is wise to define specific conventions per collaboration project,
independent from those of the collaboration partners. This means that the
version number (and the status codes) used in the collaboration, may be
different from those used internally in each of the partners. This is exactly
where the revision comes into the picture. Many companies use the term version
for iteration that need only be knows inside the department or company, and
revision for iterations that are made known to external parties (so after
release).

Anyhow, making distinction between documents and
parts, and not between versions and revisions, makes it much easier to
understand conventions in different companies and to compare implementation in
different PLM systems.

beyondplm

Henk Jan Pels, thanks for the contribution! You are absolutely right about different company and project conventions, which can make communication really difficult. In my practices, not messing up with Part revisions usually simplified things. Status is indeed very important. Again, thanks for your comments! Best, Oleg

Bas

Nice post, but Parts have no version/revision??? I don’t know which system works like this but it’s a system which does not support configuration management for sure!

Oleg is right – per configuration management standards parts aren’t revised unless they are fully interchangeable. But it’s true that tools are actually more flexible than that – I explore this topic a little further in my own post here: http://eng-eng.com/one-revision-to-rule-them-all/

beyondplm

It depends. As Ed mentioned, each time you break “interchangeability”, you need to assign new PN. In that case, version/rev is useless. I have to say that lots of “intermediate” solutions around that trying to apply both approaches at the same time.

Alon Shmil

How to manage drawing revisions? when i need to revise the top level or sub assembly have some rules?

beyondplm

Alon, Yes. Usually you follow rules bottom up. If you change sub-assy/part, you need to consider to revise upper level assembly. If you released assembly for production, you cannot change their parts.

Alexander Stekolschik

I think that the issue of part versioning depends heavily on the part usage or referencing. If a part is used only once for one assembly (typical for Engineering To Order) it can be versioned. The assembly / BOM has to be changed accordingly as well. Reusable parts cannot be really changed of cause

beyondplm

Alexander, thank you for brining this example! Yes, if you strictly follow FFF rule, you never revision part, but introduce a new Part Number. Engineering to order work has a tendencies just to reflect WIP activities.

An interesting post was published by Luna-Tech research about the Business Process Management redefinition. Only few years ago, PLM was very focused about Collaborative Business Processes. These days I see PLM and Business Processes are not going very often together. My take is that PLM learned BPM implementation lessons. It…

A very interesting video presenting how you can track hand motion in the virtual 3D Model. The demo prepared by Robert Y. Wang and Jovan Popović. We demonstrate real-time tracking of the 3-D pose and configuration of the hand for gestural user-input and desktop virtual reality. The only components of our system…