What is a Revision?
A revision refers to a deliberate and documented change to or evolution of the design and specification of a product, part and component. Revisions are typically tracked using a revision control system, which assigns a unique identifier to each revision.
Do Parts have Revisions?
Strictly speaking parts do not have revisions. Physical parts are identified by their part number and the location where they are stored in inventory. And both are ignorant of the revision. Any part received and accepted will be stocked in the inventory location identified only by its part number, irrespective of its current revision. Anyone picking a part from that inventory location would not know if they get the current revision or a previous one that had not been used or discarded and thus remained in inventory. If a part has to be traceable to a specific design change or evolution, it must receive a different part number (see also PLM Insight “PLM and Configuration Management Best Practices: Part Numbers”).
So if a part doesn’t have a revision, what does have a revision? Only the documentation that specifies the part has revisions. The 3D CAD model, the 2D CAD drawing, the 3D visualization representation, the 2D PDF drawing, STEP and/or IGES models of the part, every document that uniquely describes or defines the design evolution of a part has a revision, and that allows distinguishing the documents defining the different revisions. That means that all documents defining a certain design evolution of the part should also have the same revision (to make it easier and avoid confusion and mistakes, not for technical reasons, but I get to that later).
Following the principle that parts do not have revisions allows for an elegant and low effort solution to BOM changes. As described in a previous PLM Insight “Change Management and BOMs (Form, Fit and Function, Part III)”, if a part is revised, the higher levels of the BOM(s) where the part is used do not need to be revised. That means nothing needs to be done (!!!) other than ensuring that only the latest released revision of all related documents of that part are being used by all affected parties (this can easily be automated with a PLM system).
In most PLM systems though parts do have revisions to be able to logically distinguish the different design evolutions of that part and any associated documents. However, that can potentially create a significant amount of work because once a BOM is released, it cannot be changed anymore. If a released BOM is configured in a way that it points to a specific revision of a part, all higher levels of all BOMs where that part is used must be revised if that part is revised. Therefore it is highly recommended to investigate how a specific PLM system handles such a scenario and define clear business practices and procedures.
Are Revisions Interchangeable?
Yes, that is a requirement defined in many standards (ISO, MIL-STD, ASME, EN, DIN, etc) and often also represented in the configuration management principle of “form, fit and function” (see PLM Insight “Form, Fit & Function”). Specifically, MIL-STD-3046 – Configuration Management and ANSI/EIA-649B provide that the “product identifier shall be changed whenever a non-interchangeable condition is created”, implying that a part (or more specifically, its documentation) can be revised as long as an interchangeable condition is maintained.
Should the Revision Indicate Design Confidence or a Lifecycle Phase?
Many companies today use numerical revisions (00, 01, 02, etc) for prototype parts and alpha revisions (A, B, C, etc) for production parts. The main reason, the argument goes, is that this makes it easy to distinguish the lifecycle phase a part is in, i.e. prototype or production and thus apply different business rules and make decisions as to what can be done with a part and what should not. For example prototype parts should not be used in a released production assembly, they should not be ordered in large quantities, they should not be inventoried along with production parts, etc.
These are all seemingly good reasons for using different revision schemas for parts in different lifecycle phases. And frankly, before PLM, all these reasons made some sense because there was no other mechanism to indicate the lifecycle phase of a part. Sure, one could have written “Prototype” on a drawing, but in order to change the text “Prototype” to say “Production”, the drawing would have to be revised, so why not just use the revision letter to indicate the lifecycle phase?
With PLM though this approach does not make much sense anymore. Not that it is fundamentally wrong, there are just better and more flexible ways to accomplish the same.
First, this approach only allows distinguishing between two lifecycle phases and set of business rules. However, most companies have more than two phases, such as “Development”, “Prototype”, “Pre-Production”, “Production”, etc.
Second, to change the lifecycle phase and with that the revision from numeric to alpha, for example from “03” to “A”, a part has to be revised, meaning it has to go through an engineering change process, even though there may be no modification to the design of the part or the related documentation. That creates potentially a lot of unnecessary effort, as presumably most parts will go from one phase to another and therefore will have to be changed from a numerical revision schema to an alpha revision schema.
Best practice in today’s age of information technology and PLM is to use only one revision schema with letters (A, B, C, etc) and avoid using the revision to indicate design confidence or a lifecycle phase. Many PLM systems have out-of-the-box functionality that allows indicating in which lifecycle phase a part or document is and apply respective business rules independent of the revision. The revision should only be used to indicate the design evolution and changes.
What is the Best Revision Format?
Given that part numbers should consist only of numbers, revisions should only consist of letters to clearly distinguish the part number from the revision. It is common to start with one letter (A, B, C, etc) and if required continue with a double letter format (AA, AB, AC, etc). Most PLM systems support this revision schema out of the box.
When Should the Revision be Increased?
When a part is first created, best practice is to start with revision “A” in a working state, i.e. the part can be designed and specified. Typically the part would initially be in the “Development” lifecycle phase, but depending on part type and business processes, it could be assigned directly a later lifecycle phase as well, i.e. “Prototype”, “Pre-Production” or “Production”.
As long as the part is in a working state, i.e. it is not released, it can be modified. Once the design and specification is complete, the part would usually go through a release process for review and approval. Once that process is complete, the part would be released with revision “A” in the respective lifecycle phase in which it was created. Once the part is released, it is locked and should not (be able to) be modified.
If the part now has to be changed, an impact analysis done as part of an engineering change request (ECR) should determine whether the part remains fully interchangeable after the change, i.e. form, fit and function remain the same. If the answer is yes, the part would go through an engineering change process, or more specifically, an engineering change order (ECO) process to implement the change. This typically includes creating a new revision “B” of the part (or again, of its documentation), making the required modifications, reviewing and approving it and then releasing it as revision “B”. At the same time the previous revision (in this case “A”) should be made obsolete as there should never be two released revisions of the same part (documentation). The topic of obsolescence will be addressed in more detail in a future PLM Insight.
If the part is not interchangeable after the change, i.e. if form, fit and function are not maintained, it should not be revised but a part with a different part number should be created.
Changing the lifecycle of a part, i.e. promoting it from “Design” to “Prototype” for example, should also not change the revision as the design or specification of the part does not change. Just because we make a business decision to now test or produce the part should have no bearing on its design, specification and documentation, and hence not require a revision change.
Neither should the lifecycle phase of the part change as part of creating a new revision. Revision and lifecycles changes have different business rules and should consequently be done using different business processes. This will be the topic of a future PLM Insight.
Andreas Lindenthal, the author, is the founder and managing partner of PLMadvisors. He is a passionate thought leader and recognized industry expert with over 25 years international, hands-on experience in innovation, new product development (NPD), and product lifecycle management (PLM). He has served a large number of leading global companies across various industries to sustainably improve their business results by helping them to drive innovation, increase productivity, shorten time-to-market, reduce costs, ensure compliance and improve product quality through the definition, evaluation, implementation and operation of best-in-class innovation, NPD and PLM strategies, practices, processes and technologies.