Precise vs Imprecise BoM Structures

Lionel Grealou Data, Engineering Leave a Comment


Siemens PLM’s Teamcenter uses a concept of precise/imprecise Bills of Materials (BoMs) structures. There are fundamental differences between the two approaches and one should understand their purpose and how to utilize them effectively. Both descriptions apply to BoM view revisions, defining which components are used specific contexts. Precise and imprecise structures differ by the type of parent-child relationship (‘relative occurrence’):

  • Precise BoMs: the components are ‘precisely‘ selected Item Revisions, in context of a specific approved or released structure, including important contextual historical information – aka BoMs which are ‘frozen‘, fixed or ‘static‘ structures of developed products to be manufactured. Precise BoMs have all functionality of imprecise BoMs, and some revision rules can also be applied for sub-component filtering.

Precise assemblies are useful in situations where a user wants to control the configuration carefully, for example, during the product design phase or in aerospace manufacturing environments. When the parent assemblies are released and consequently can no longer be modified, any change can have a significant impact on the revisions of related assemblies.

  • Imprecise BoMs: the components are Items, with underneath them all existing Item Revisions, i.e. no specific Item Revisions are selected – aka BoMs which can be filtered using configuration or change rules. This relates to the concept of 150% configured BoMs… Revision rules can be applied to imprecise BoM structures to visualize specific CAD structures or BoM components in a ‘dynamic‘ way (e.g. with the ability to overload different components). Imprecise structures do not hold product development history and are no use for manufacturing – what are they used for then? Some argue that they are easy to manage like a collection of work iterations, but have no or little business use and traceability.

An imprecise product structure is automatically reconfigured when any user releases a part, creates a new part, or performs any other action that affects the view. Therefore, the user need not make a copy of the product structure and manually update it each time.

As per the book, it is recommended to:

  • Use imprecise assemblies if a user wants to provide many views of the same structuredata.
  • Use precise assemblies to control the configuration of the structure closely.
  • Introduce revision rules when users are familiar with the system.
  • Create baselines sparingly as each baseline request creates a completely released structure and (potentially) many new item revisions and copies of the associated data and CAD models.
  • Create intermediate views to capture the exact state of all referenced data, not only the relevant configuration of the product.

This sounds logical and sustainable… It is also suggested that swapping between precise and imprecise structures (and vice versa) can be a useful approach to refresh assemblies when they reach a different stage in their life-cycle, i.e. when releasing a structure from Engineering to Manufacturing. This will require the appropriate revision rules to be defined in order to tack specific contextual requirements – while disposing of other Engineering historical information which is not relevant for Manufacturing. This will obviously depend on contextual business processes and associated business rules; if that’s the case, one would assume that there could be ‘simpler‘ ways to transfer and maintain EBoM and MBoM associativity and alignment… 

Precise BoM seems more suited for EBoM management, while imprecise appears to relate more to design and CAD structures. It is however doubtful that swapping between the two approaches is actually used when products are getting mature as it would imply a massive amount of rework and re-engineering of the revision rules and the BoM content… potentially associated with a heavy migraine or series of pains in the neck 🙂

What are your thoughts?


This post was originally published on LinkedIn on 26 August 2015.