Arena Blog

Read Our Blog for the
Latest Trends and Insights

Rolling Revisions Up the Tree 101: When, How and Why

BOM Management Tree DiagramOver the years, we’ve seen many new Arena customers wrestle with the question of whether a new component revision should trigger a new revision of the assembly or assemblies that contain it.

This is a harder question than it might seem because the simplest answer just doesn’t work in the real world of manufacturing. If you always let minor changes to low-level parts trigger new revisions to your top-level product assemblies (and all the intervening sub-assemblies), you will quickly find yourself buried in a never-ending stream of meaningless documentation updates. And, with trivial updates happening all the time, you’ll lose track of really important product-level changes.

On the other hand, it’s easy to think of a component or sub-assembly change, like a new motherboard or major mechanism redesign, that should be tracked at the product level. If a major redesign of an existing component inadvertently introduces a functional, reliability, or, in the worst case, safety issue, you really want to be able to distinguish which products contain the revised component and which don’t.

To roll or not to roll?

You can’t follow a policy of always releasing a new revision of your top-level assemblies when you make a component-level change, but you also shouldn’t follow a policy of never doing so.

In general, you should release a new revision of an assembly for the same reason you release a new revision of a component—when the change is significant enough that you may need a way to easily distinguish “before” from “after.”

To get more precise, let’s talk about terminology.

Direct and indirect parents of components and subassemblies

If you have a component that appears on the first-level BOM of an assembly, then that assembly is using the component directly and you can, therefore, call it a direct parent of the component. Conversely, an indirect parent is an assembly that contains a component by way of a subassembly.

These classifications are not mutually exclusive. For heavily used components like fasteners, it’s possible for one assembly to be both a direct and indirect parent of the component.

Major and minor revisions

Major revisions are generally changes to components, subassemblies, or products that alter the Form, Fit, Function or if your product is subject to substance-based regulations like RoHS or REACH, Formulation. Symphony Consulting introduced us to the fourth “F” a few years back.) Minor revisions are changes that affect documentation or other metadata.

If you don’t know how to classify a particular change, ask yourself this simple question—would you care if the two revisions were “mixed up” in manufacturing? If you would, meaning you want the updated component or subassembly stocked separately from its predecessor, then the change is a major revision. If not, it’s a minor revision.

A helpful tip on system configuration

Because ERP and shop floor management systems can normally only track inventory by part number (and not by revision level), it’s a good practice to configure your systems so that the separate “revision” attribute is used only for minor revisions, and major revisions are tracked with a subfield of your item number.

This practice makes it easier to stock major revisions separately on the shop floor and clearly communicates when a revision affects form, fit, function or formulation.

Another useful thought experiment is to consider whether the revision could introduce new product-level problems, such as reliability or safety issues. Even if a change is completely backward compatible with the prior revision, sometimes it’s better to treat it as a major revision so that manufacturing and field service can more easily trace the change, even though major revisions incur higher inventory and documentation costs than minor revisions.

The trade-off between traceability and cost is the heart of the matter: you should only track changes to assemblies when the benefit of traceability exceeds the inventory and documentation costs. This is the change management version of the commonly accepted accounting rule that you should only measure expenses for which the benefit of knowing exceeds the cost of the measurement.

Optimizing this trade-off is a business decision that can vary from industry to industry. For example, medical device manufacturers tend to classify more changes as major revisions and roll their changes farther up the tree, due to safety and liability concerns, than their counterparts in industries that are more concerned with nimbleness and speed-to-market.

For today’s dispersed product teams and supply chains, it’s critical to have a single source of truth to manage product details and revision control effectively. For more information on BOM management, click here to learn more.