Every product company eventually must address the question of how to approach revision and version release management of their items, subassemblies, and assemblies. The answer is complex and depends on several factors, among them: the industry of operation, standards and regulations within that industry, the trade-off between documentation and traceability, as well as company culture.

Terminology

As a starting point and baseline, let’s define a little terminology.

• Item or Part – When we refer to an item or part, we’re referring to a record of some component or assembly in your item master. For more information, please visit our guide Mastering the Item Master.
• SKU (Stock Keeping Unit) – A SKU is a unique identifier attributed to an item to differentiate it in inventory. Since Aligni integrates both PLM and MRP functionality, item and SKU are equivalent because there is no need for a translation layer between these two worlds. This allows the same best practices that exist in the MRP/ERP world to apply to the PLM world seamlessly.
• Revision – A revision is a noted change to an item or its BOM that does not result in the release of a new item. At any given time, an item may have multiple draft or released revisions but only one active revision. In this context, a revision is typically an identifier used internally by the organization and not communicated to customers.
• Version – A version refers to a particular iteration of a product or document that is differentiable from previous iterations. Versions a represented with different items (SKUs) and are therefore differentiable and communicated to customers.

The Form / Fit / Function Rule

We explain the Form / Fit / Function rule in more detail in our separate guide.

Release Approaches

There are several approaches to BOM release, revision, and version management that may be undertaken and each depends on the context, goals, and requirements. For the examples below, we’re working with a contrived partial BOM (for simplicity) of a bicycle. This BOM is hierarchical which means that the bicycle assembly contains multiple subassemblies that, themselves, are constructed from subassemblies.

Release a new (Minor) Revision

Let’s start with a simple case. Here, we’ve made a minor change to the PEDAL-ASSEMBLY item. It has been determined that the change does not affect the form, fit, or function of the pedal assembly and it is therefore released as a revision under the same item code. Because it has the same item code, it also has the same SKU in inventory. So while inventory may contain attributes like lot code and date code that distinguish them by assembly lot, the inventory is otherwise not differentiable.

During the release of this item, the organization had to make a decision of how to disposition existing inventory at Revision A. It may choose to use existing inventory as-is, scrap it, or perform rework to make it compatible. But in any case, after the release process, all inventory is considered to be at Revision B.

Finally, the instances of this item on parent BOMs are up-revved. This means that all parent BOMs simply automatically point to this new active revision without any need for engineering change orders, approvals, or documentation. In some very strict operational scenarios, this might not be acceptable, but in most, it is completely acceptable because for the form / fit / function rule.

Release a New Version and Item

Next, let’s consider a more significant change to the pedal assembly that makes this release incompatible with the previous version. In this case, our organization has decided to create a new item (PEDAL-ASSEMBLY-V2) which means that we now have two items and two separate SKUs so we can differentiate these two in inventory.

With this new item, we’ve had to update the parent item (CRANK-ASSEMBLY) but, in this case, the new crank assembly is F/F/F compatible with the previous one, so we’re just going to release revision B.

Release a New Version and Parent Versions

If the changes to our pedal assembly are significant enough to affect the entire BOM hierarchy, we might want to propagate those changes with new item code releases. This might be the case, for example, if our new pedal assembly has a technology change that gives it some additional value in the marketplace and enough to justify releasing a new version (or model year) of the bicycle.

In this approach, there’s obviously more impact to the BOM hierarchy and operations. There might be additional review procedures or engineering change orders for each level of the BOM that is updated. Production departments need to be updated with new documentation or procedures for the new item codes.

Release a New (Minor) Revision and Roll Revisions (Not Suggested)

Finally, let’s briefly discuss one approach which is generally not preferred. This is the case where the changes are released as a new revision (Revision B) and, notably, not released as a new item code. The implication of this is that the changes are form/fit/function compatible with the previous revision. Some organizations are tempted to require this change to be “rolled up” through the hierarchy for documentation purposes.

If the team is following best practices regarding item codes, revisions, versions, and the form/fit/function rule, this is rarely justified. It needlessly creates extra “paperwork”. If the pedal assembly is used on multiple bicycles, there could be a large number of BOM updates that complicate or confuse production with a change that, by definition, should not be impactful to them.

Electrical Assemblies (PCBAs)

Aligni’s integrated PLM and MRP approach is a great fit for many product industries, including company manufacturing electronics assemblies. These companies make extensive use of off-the-shelf and commodity electrical components such as resistors, capacitors, and inductors.

For a number of reasons, there may be many BOM changes over the lifetime of a product that are related to logistics, in particular to supply chain logistics. One manufacturer might offer better pricing on a particular commodity component. Or one manufacturer’s supply issues might require that the company find another source. These can lead to BOM changes that have no risk of form/fit/function incompatibility and result in a minor revision to the BOM. Up-revving the parent BOMs in this case is completely unnecessary for many companies and simply creates additional documentation and may even create confusion.

Aligni defaults to up-revving parent BOMs under the assumption that any revision changes are form/fit/function compatible with the previous revision. However, the option to keep the revision is still available. With this option, you would need to visit each parent assembly and make the appropriate updates and releases, as desired.

Similarly, existing inventory is dispositioned to remain in inventory and is assumed to become the latest revision (although this concept is a bit unnecessary because inventory isn’t revisioned). The inventory disposition option is really to support removal of inventory if that must be performed.

BOM and Inventory Disposition on Release

When a new revision for an item is released and made the active revision, you need to consider the matter of inventory and BOM disposition.

Note that you may release a revision without making it the active revision. This process is not subject to inventory and BOM disposition.

Inventory Disposition

Since revision information is not directly tracked in inventory (although it may be tracked indirectly via lot code or date code), your organization needs to decide what to do with existing inventory when a revision is released. There are generally two options:

• Dispose – If existing inventory cannot be used or brought current, then it needs to be disposed. For most cases where the inventory is form/fit/function compatible, this is not likely to be the case. However, there are some situations where inventory that is still F/F/F compatible is justifiably disposed.
• Keep (up-rev) – If existing inventory is still usable, it is simply kept. You may separately choose to run that inventory through another process to rework or otherwise bring it up to date, if required. For example, if markings may need to be updated on it.

BOM Disposition

Based on the discussion above, this is how parent BOMs (that is, those that include an entry for the newly revisioned item) are handled. Two options are available:

• Up-Rev – This is the default and recommended operation. When this option is selected, the parent BOM will be silently updated with the new revision.
• Keep – When this option is selected, the parent BOM will not be updated and will keep its reference to the previous revision.

The “keep” option is not desirable as it creates an inconsistency in what the active revision is (and what current inventory is expected to be) and which revisions active BOMs reference.