Why Product Variety Creates a BOM Problem
Manufacturers rarely build only one fixed version of a product. A single product family may have different motors, seats, lighting packages, tyres, colors, mast heights, regional requirements, customer options, and manufacturing constraints.
The simplest response is often to create a separate BOM for every variant. That approach works while the number of variants is small. As product choice grows, however, copied BOMs create more repeated data, more manual updates, and more opportunities for the structures to drift apart.
A change to one shared component may need to be repeated across dozens of variant BOMs. An option may be valid for one model but not another. A market rule may change. A product revision may affect several configurations at once.
Configuration and variant management provides a different approach: define the reusable product logic once, then resolve the exact BOM needed for each valid product configuration.
What Is a 150% BOM?
A 150% BOM, often called a Super BOM or overloaded BOM, is a configurable product structure that contains the common parts plus the possible options and variant parts for a product family.
It is not intended to represent one buildable product. Instead, it represents the broader set of possibilities from which valid product configurations can be derived.
A 150% BOM can include:
- components that appear in every product
- optional assemblies and features
- alternative parts
- model-specific content
- market-specific content
- customer-specific options
- date, unit, revision, or other effectivity conditions
- dependencies and exclusions between options
What Is a 100% BOM?
A 100% BOM is the resolved product structure for a specific valid configuration. It contains the common content plus only the options and components that apply to the selected model, order, customer, market, or other configuration criteria.
In simple terms, the 150% BOM represents the available product choices. The 100% BOM represents the exact product that is intended to be built, planned, sourced, or released downstream.
150% BOM vs 100% BOM
Area | 150% BOM | 100% BOM |
Purpose | Represent all valid product possibilities | Represent one selected product configuration |
Content | Common parts plus optional and variant content | Only the parts required for the selected outcome |
Rules | Contains or references configuration logic | Result of applying that logic |
Use | Product family and variant definition | Manufacturing, procurement, planning, service, or order execution |
Change impact | Shared logic can reveal affected configurations | Shows the exact released product structure |
Duplication | One reusable structure supports many variants | Generated or resolved as needed for a specific configuration |
How Configuration Rules Turn 150% Into 100%
A 150% BOM becomes useful when product options are controlled by configuration rules. Those rules determine which combinations are valid and which parts belong in the final configured structure.
- Define the product family: Organize shared platforms, models, modules, features, and options.
- Build the 150% BOM: Maintain the full reusable product structure containing common and variant content.
- Define configuration rules: Control dependencies, exclusions, compatibility, option requirements, and valid combinations.
- Apply effectivity: Use conditions such as model, market, date, unit, revision, customer, or manufacturing context where needed.
- Select the required configuration: Choose the options that define the specific product outcome.
- Resolve the 100% BOM: Filter the shared structure so only the valid parts and options remain.
- Release downstream: Provide the exact structure needed by manufacturing, procurement, planning, service, or delivery.
Why Separate BOMs Become Difficult to Maintain
The alternative to a configurable structure is usually copy-and-edit. A base BOM is copied for a new model, region, or customer, and then modified until it matches the new product.
Over time, that creates several problems:
- shared parts are repeated across many BOMs
- the same change must be applied to multiple structures
- teams may forget which BOM contains the latest product logic
- invalid option combinations can reach downstream teams
- variant differences become difficult to compare
- engineering change impact becomes harder to understand
- spreadsheets or manual option lists become part of the configuration process
- manufacturing and procurement may receive inconsistent structures
A configurable BOM model reduces this duplication by separating shared product definition from the rules that determine the final product outcome.
Industrial Forklift Example: One Product Family, Two Variants
Consider a forklift product family with an Economy Variant and a Premium Warehouse Model. Both products may share the same core platform, but they differ in seating, lighting, tyres, roof finish, fork options, and mast configuration.
Feature | Economy Variant | Premium Warehouse Model |
Seat | Low seat | High seat |
Lighting | Basic lighting | LED package |
Tyres | Standard tyres | Premium extended tyres |
Roof | Standard finish | Coated blue roof |
Fork | Standard fork | Extended fork |
Mast | Standard mast | Triple mast |
Instead of creating and maintaining two unrelated product structures, the product family can be represented in one 150% BOM. Rules determine which option is valid for each model, and the configured 100% BOM contains only the content required for the selected forklift.
Configuration Rules Matter as Much as the BOM
A Super BOM alone does not prevent invalid products. The rules around the structure are what make configuration repeatable and safe.
Rule type | Example |
Required | Premium Warehouse Model requires the high seat. |
Exclusion | Basic lighting cannot be selected with the premium model. |
Dependency | Extended fork requires the heavy-duty mast. |
Market availability | A lighting package is available only in selected regions. |
Date effectivity | A new tyre becomes valid after a defined release date. |
Revision effectivity | A component option applies only from a specific product revision. |
Manufacturing constraint | A plant can build only configurations supported by its process or tooling. |
How Variant Management Helps Engineering Changes
Variant management becomes especially valuable when shared content changes. If a common component is revised, teams need to understand which configurations are affected and which are not.
In a copy-and-edit approach, that analysis may require checking multiple BOMs individually. In a controlled configuration model, shared structures, rules, selected options, revisions, and final configured outputs can remain connected.
That makes it easier to answer questions such as: Which variants use this component? Which configured BOMs are affected? Does a rule need to change? Which market-specific products require a new release?
What Different Teams Need From Product Configuration
Team | What configuration management should provide |
Reusable product structures, valid option logic, revision control, and change impact visibility. | |
The exact buildable BOM for the required model, order, or plant context. | |
Procurement | The precise parts and assemblies that need to be sourced for the selected configuration. |
Planning | A controlled product structure aligned to the order, market, configuration, and release state. |
Quality | Traceability from the released variant back to options, rules, revisions, and changes. |
Clear control of product families, models, features, option availability, and variant strategy. |
150% BOMs, Effectivity, and Variant Management
A 150% BOM and variant management are closely related, but they are not exactly the same thing.
The 150% BOM is the configurable structure. Variant management provides the broader logic for organizing product families, features, options, models, and valid combinations. Effectivity adds conditions that determine when a component or option applies.
Together, these concepts allow teams to manage product variety without treating every configuration as an entirely separate product definition.
When a 150% BOM Approach Is Most Useful
A configurable BOM model is especially useful when products share a common platform but vary by:
- model or performance level
- customer-selected options
- market or regional requirements
- electrical or voltage variants
- engine, motor, or powertrain choices
- equipment attachments
- materials or finishes
- supplier alternatives
- plant or manufacturing context
- date, serial, or revision effectivity
Typical examples include industrial machinery, material handling equipment, automotive products, configurable electronics, appliances, and engineered equipment.
How Nora IPLM Supports Configuration and Variant Management
Nora IPLM brings configuration logic into the controlled product lifecycle environment so product families, BOMs, options, rules, revisions, documents, CAD references, and engineering changes remain connected.
Teams can maintain a reusable 150% BOM, define dependencies and exclusions, apply effectivity conditions, select the required configuration, and generate the corresponding 100% BOM for downstream use.
Because the configured output remains connected to its source structure, selected options, rules, revisions, and changes, teams can trace how a specific variant was created and understand how future changes affect related configurations.
Key capabilities include:
- product family, model, feature, and option management
- 150% BOM / Super BOM management
- rule-based dependencies and exclusions
- effectivity control
- 100% configured BOM generation
- variant comparison and traceability
- revision and engineering change control
- connected product data for engineering, manufacturing, procurement, and quality
Best Practices for Managing Configurable BOMs
Keep common content truly common: Avoid duplicating shared parts or modules simply because a new variant is introduced.
Separate product logic from individual outcomes: Manage options and rules centrally instead of embedding inconsistent logic in copied BOMs.
Validate rules before release: Dependencies and exclusions should prevent invalid product combinations before they reach manufacturing.
Use effectivity deliberately: Define clear conditions for when components, options, or revisions apply.
Keep configuration connected to change: When a shared part or rule changes, evaluate the affected product variants before release.
Preserve traceability: The configured BOM should remain traceable to the source structure, selected options, rules, revisions, and approvals.
From More Variants to Less Repeated Work
Product variety does not have to mean product-data duplication.
A 150% BOM gives manufacturers a reusable structure for the full range of product possibilities. Configuration rules and effectivity determine which choices are valid. The resulting 100% BOM gives downstream teams the exact product definition they need.
The value is not simply fewer BOM files. It is a more controlled way to scale product choice while keeping engineering, manufacturing, procurement, planning, and quality aligned around the same product family.
Frequently Asked Questions
What is a 150% BOM?
A 150% BOM, also called a Super BOM, contains the common parts plus the possible option and variant content for a product family. It represents a configurable structure rather than one specific buildable product.
What is a 100% BOM?
A 100% BOM is the resolved structure for a specific product configuration. It contains only the parts and options that apply to that model, order, customer, market, or other selected criteria.
Why is it called a 150% BOM?
The term is used to describe an overloaded structure that contains more content than any one final product will use. The exact percentage is conceptual rather than a literal measurement.
What is the difference between a 150% BOM and a Super BOM?
They are commonly used as equivalent terms. Both describe a configurable structure that holds the broader set of product possibilities before rules resolve it into a specific product configuration.
How does a 150% BOM reduce BOM duplication?
Instead of maintaining a separate copied BOM for every product variant, teams maintain one reusable structure and apply configuration rules to generate the required output.
What is effectivity in BOM configuration?
Effectivity defines the conditions under which a component, option, or rule applies. Conditions may include model, market, date, unit, revision, customer, or manufacturing context.
How do configuration rules prevent invalid variants?
Rules define dependencies, exclusions, requirements, compatibility, and availability so only approved combinations can be selected.
Can a 150% BOM support manufacturing and procurement?
Yes. Once the structure is resolved into the correct 100% BOM, the configured output can provide manufacturing, procurement, planning, service, and other downstream teams with the exact product definition they need.
See the consequence before you commit to the change
Discover how Nora IPLM Knowledge Thread turns connected product data into a traceable AI Change Impact Simulation, from qualified evidence and visual propagation to alternate-item, carbon, and AI-assisted analysis.
