Two rules for rolling a revision up the tree
When incorporating a new component revision, many manufacturers struggle with the question of whether to trigger a new revision of the assembly. You don’t want to bury yourself in a pile of pointless documentation updates, but you also never know when you may need to trace a given change.
Through my personal experience and by working with Arena customers, I’ve come to find that this dilemma can be managed by applying two straightforward rules of thumb. These rules should be applied to every assembly that uses the component directly.
Two simple rules for making component changes
Rule #1: If the change represents a minor revision to the component, do not release a new revision of the parent assembly.
Rule #2: If the change represents a major revision to the component, decide whether it also represents a major revision to the parent assembly. If it does, release a new major revision of the parent. If it doesn’t, release a new minor revision of the parent.
The assemblies that contain a component directly are usually subassemblies with their own parents. If this is the case, apply the above rules to the subassemblies and repeat as necessary, all the way up the tree.
Playing out the policy
Let’s say you introduce new battery chemistry into your portable electronic device—the old version used NiMH batteries, and the new version uses Li-ion. You clearly want your field service staff to keep the batteries separate, and you’ll likely want to be able to tell at a glance which battery is used in the product, even when it’s sitting on the shelf at the store. This kind of change would be a good candidate to roll all the way up to the packaging (finished goods) level.
On the flip side, let’s imagine you’ve add a new qualified source for a resistor on the main board, with no intended change to the form, fit, function or formulation of the device. Because the new resistors are functionally and cosmetically indistinguishable, it’s fine to stock them with the old resistors, and there’s no need to track the change at the assembly level.
Now, suppose you add a new mounting hole on the main circuit board that enables a new housing design, but is also backwards compatible with the existing device (which you continue to make and sell). You need to keep the new boards and board assemblies separate from the old ones so that manufacturing does not put old board assemblies into the new housing. This is clearly a major revision to the circuit board and its direct parent, the board assembly.
But, the original device itself is unaffected by the change, so there’s no need to separate the “before” and “after” stock of that product assembly. In this case, it’s good practice to release a minor revision of the original product assembly to provide a clear historical record of the change, but there is no need to release a new revision of the packaging.
What do you think?
These recommendation are based on both personal experiences and what I’ve seen work for Arena customers—but there’s always room for discussion and disagreement on the “best” policy for releasing a new revision of an assembly when making a change to one of its components.
I’d love to hear what you think, so please share in the comments section below!