Posted By Alex Gammelgard, May 15, 2012 at 3:52 PM, in Category: The Innovation Enterprise
At Arena, we work with a lot of high-tech electrical-hardware engineers and OEMs. In our thousands of conversations with prospects and customers, here is one of the most common questions we get - - if you revise a component used in your designs, or swap it out for a totally different component, how far up does that revision need to go?
This is sort of a tricky question to answer with some major pros and cons on either side.
On one hand, 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. Which no one loves. Plus, if you're getting notifications all the time, you'll start to tune out and 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.
Our CTO has written a piece, "To Roll or Not to Roll" which is designed to help you decide which type of changes really are worth rolling up the tree, and which ones can be looked at as minor changes.
Essentially, we think that the trade-off between traceability and cost is what counts, and you should be tracking all changes to assemblies when the benefit of traceability exceeds the inventory and documentation costs.
Thoughts? Or do you have an interesting process that you'd like to share?
Written by Alex Gammelgard