Rolling revisions up the tree 101: When, how and why
Over the years, I’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 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. (Bijan Dastmalchi of Symphony Consulting introduced me 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.
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 to 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.
In my next post, I’ll suggest a couple of simple rules for rolling revisions up the tree. Stay tuned.