How to manage Document versions, revisions and Part numbers

How to manage Document versions, revisions and Part numbers

document-revisions-version-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

Share This Post

  • Steve

    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.

  • Pingback: Part and Document Management: Why is it Complex? | Daily PLM Think Tank Blog()

  • 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

  • Pingback: One Revision to Rule Them All | E(E)()

  • Henk Jan Pels

    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.

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll