In our last blog To Rev or not to Rev, we discussed at which point a change to a BOM component, say a single part, is significant enough to warrant that it must obtain a new part number (or PIN=part identification number). The alternative to assigning a new part number, is to simply revise the component. By doing so, only the revision gets incremented, the PIN remains the same.
Let us run through an example. We have two options:
- 30001234, Rev E becomes 30001234, Rev F
versus - 30001234, Rev E becomes 30004567, Rev A
It goes without saying, that all parts in question are here in a released state.
For non-released parts, one may introduce pretty much all sorts of updates which do not trigger a formal change process. But again, even that depends on the business case.
We determined that a significant change in form, fit, function (FFF-rule) or a lack of interchangeability between old and new components should trigger a new part number, which is shown in case (2). In other situations, where modifications are less significant, a new revision as shown in case (1) may suffice.
When the component in question is an assembly, there is even a third option. (In this context, when we say “assembly”, we are merely referring to a BOM item containing lower level items. These items do not necessarily need to be physically “assembled”. E.g. it could be an assembly containing software components, adhesives etc.) Say the change to the assembly is introduced – implicitly – by a change in one of its components. Then, depending on the case, neither a new part number nor a new revision may be needed. Why so?
Explicit BoM Changes
First let us look at the situation where a change on an assembly item is required. Let us start with the assembly 20001234 in Rev B and its component 30001234:
20001234, Rev B
|—30001234, Rev E
|—…
|…
Say, a change had to be made to component 30001234 that was significant enough to warrant a new part number, in this example 30004567. The new BOM now looks like this:
20001234, Rev C
|—30004567, Rev A
|—…
|…
We have explicitly modified the BOM. Here, “old” and “new” assemblies are clearly different. The list of included items (on the first level) has changed. The least we need to do is to revise the “parent” assembly 20001234 from B to C.
Depending on the significance of the change, replacing the parent assembly with a new part number could also be the right choice: The rules about form-fit-function and interchangeability apply to assemblies just like they apply to single components.
Let us look at implicit changes.
Implicit BoM Changes
Starting from the example above, let us now assume that we made a mere revision update to our component. The resulting BOM could look like this:
20001234, Rev C
|—30001234, Rev F
|—…
|…
There are always exceptions, but in most business cases the resulting BOM has not really changed. If the change to 30001234 was “minor” enough to spare a new part number (we discussed this in our previous blog), it should not really matter if Rev E or Rev F goes into the main assembly.
So really, we should think about the BOM as being free of revisions:
20001234
|—30001234
|—…
|…
Some PLM systems implemented this idea of a revision-free BOM. E.g. in Teamcenter it is called an imprecise BOM, whereas the BOM with revisions is the precise BOM. Other systems, such as Windchill, use revision-free BOM’s per default and have a clever way to identify the correction revisions of BOM items using so-called configuration specifications or baselines.
Of course, when you come to the point of releasing a BOM, you would always look at the precise configuration including revisions. Nevertheless, this does not mean you have to rev-up and re-release the whole assembly whenever a lower level update occurs.
If you think about it for a moment, it makes sense: Assume you established the rule to always roll-up lower level changes to the upper-level item, you would wind up revving up all of your top level BOM items, whenever something deep down below wiggles. In the automotive or aerospace industry, with millions of BOM items in the final vehicle, you could not possibly keep up. And do you really have to rev up the top level BOMs of your car models, just because you changed a spring in the seat adjuster? 😉
Changes without Release Process???
Considering implicit BOM changes, you may say “Hey, wait! At some point we released Rev C of our 20001234 main assembly and its precise list of components. Now we can simply introduce changes through the backdoor by revving up components underneath???”.
Well, if you have a rigorous change management process in place, involving a thorough impact analysis, no change really occurs through the back door. A managed change process is indeed a necessity for checking upper level assemblies of affected BOM items. If the analysis shows that the change has no impact on the upper level items, there is no need to rev them up. And I would even argue that if our 30001234 has kept its part number (see our criteria from the previous blog), there should normally be no reason to roll-up the change.
Implicit BoM Changes with BoM Roll-ups
In reality, of course, BOM revisions are often rolled up for good or bad reasons:
- The change of the 30001234-subcomponent was not so minor after all and we really need to track the change in the upper level assembly. You could say, this is more a consequence of not having made the right call on the subcomponent. But this is life, not all decisions are clear cut.
- You introduce a new component that has a major impact on the final product. For example, you exchange the display on your mobile device product with an improved one, that is more durable, flexible and that has a nicer finish. Even though the new component only triggers an explicit BOM change in the next upper level – and implicit ones in the levels above – you want to make service technicians and customers aware of the update. This is a case where you roll up to the top-level final good.
- Your upper level BOM’s are so small and handy, that rolling up a component change is not that big a deal. You simply revise and re-release the whole item after every change. Like this, every single update can be tracked from your upper level BOM. How far you roll up, is up to your business and updates may even wiggle through to the top-level items.
- You decide to collect several smaller changes down below and to combine them into one larger change update of the top level BOM. So, the upper level item gets revised first and stays in a non-released state. Then you make those lower level updates and when finished, you release the whole BOM structure.
Conclusion
Apparently, there is no simple, general rule when new component revisions should roll-up the BOM. Many factors, such as regulatory compliance demands, tight integration with manufacturing etc. demand a high level of control over your product configuration. However, if you track too many changes in your top-level items, you end up spending endless of man hours just updating documentations. It really depends on your business and how accurately you want component changes to be reflected in your final products. Therefore, it is important that you define the right rules and guidelines that make sense to your business.
