150% BOM and Variant Management: Configurable Product Architecture in PLM

A manufacturer that sells a tractor in two drivetrains, two cab grades, two regions and a handful of other options does not have eight products. It has eight today, thirty-odd a year later, and a spreadsheet nobody trusts after that. The usual failure is not a lack of data. It is that every variant was cloned from the last one, so each carries its own copy of the frame, the wiring and the safety documentation, and every engineering change must be made in many places and is missed in at least one.

The 150% BOM is the structural answer: one superset bill of materials that contains every part any variant might use, with each usage line carrying a rule that says when it applies. A resolver then derives the “100% BOM” for one buildable product. This article explains the model precisely, the rule languages and effectivity types around it, the resolution algorithm with runnable code, the combinatorial arithmetic that makes the approach necessary, and how PLM, a configurator and ERP divide the work.

What this covers: the 150% versus 100% BOM distinction, option families and rule languages, effectivity, a reference architecture across PLM, CPQ and ERP, a tested Python resolver, rule validation, change impact, failure modes and a decision matrix.

Context and Background

The terminology is looser in practice than in textbooks, so fix it first. A 100% BOM lists exactly the parts of one specific, buildable product. A 150% BOM, also called a superset, overloaded or maximal BOM, lists every part of every variant in one structure. The percentage is a convention rather than a measurement: it says “more than one product’s worth of parts”. The structure is only meaningful together with the logic that selects subsets of it.

Vendors name the idea differently. PTC’s Windchill documentation describes an “overloaded product structure” that holds all possible designs, which a Configure action reduces to a valid design stored as a variant part structure. SAP calls it a super BOM: its variant configuration documentation describes creating one configurable material that covers all variants, with a super BOM and super routing holding the components and operations for every variant, selected by dependencies. Siemens positions Teamcenter Product Configurator as variability management with a single definition of features, rules and product content, and with feature effectivity by date or unit. Treat those as vendor descriptions of their own products; the page text I checked for Teamcenter does not use the term “150% BOM” at all, so the label is a community convention rather than a product keyword.

The idea has a long academic lineage under other names. Software product-line engineering models the same problem as feature models, and Don Batory showed in 2005 that a feature model maps to a propositional formula, which is why SAT solvers can validate product configuration rules (see Further Reading). Mechanical PLM arrived at the same structure from the other direction: parts catalogues needed one drawing set, not hundreds.

A 150% BOM does not replace the other BOM views. The engineering BOM, the manufacturing BOM and the service BOM are still different structural views of the same product, and the transformation between them is covered in our eBOM to mBOM transformation article. The 150% dimension is orthogonal: you can have a 150% eBOM that resolves to a 100% eBOM, which then transforms into a 100% mBOM, or you can carry variability downstream into a 150% mBOM when plants need it. Which of those two placements you choose is one of the largest architectural decisions in this space, and we return to it below.

Core Architecture: Superset Structure, Rules and a Resolver

Direct answer: A 150% BOM architecture has four parts: option families that name the choices, a superset product structure whose lines carry usage expressions, a constraint set that rejects impossible combinations, and a resolver that takes a configuration plus an effectivity context and emits a frozen 100% BOM. Everything else is integration around those four.

Figure 1: The four building blocks of a 150% BOM architecture and the single output the resolver produces.

Figure 1 shows the dependency direction. The superset structure and the rules are authored data. The order configuration, the date and the unit number are runtime inputs. The resolver is a pure function of those inputs, which is the property that makes the whole design testable: same inputs, same 100% BOM, byte for byte.

Option families and choices

An option family is a named dimension of variation with a closed set of choices. In the tractor example, DRIVE has ELEC and DIESEL, CAB has STD and COMFORT, and REGION has EU and US. The word differs by vendor (characteristic and value in SAP, option and choice in Windchill, feature and option in many configurators), but the semantics are the same: a finite, discrete domain.

Two refinements matter. First, families are reused across products. Windchill’s documentation notes that option definitions can be reused across families and grouped into option sets, and the reuse is the point: a REGION family defined once keeps lighting rules consistent across every product that uses it. Second, not every input is discrete. Cooling capacity or a pipe length is a continuous parameter. Windchill models these separately as parameters that feed constraints and case tables, and SAP characteristics can carry numeric values with intervals. A real design therefore needs both discrete families, which drive structure selection, and parameters, which drive dimensions and calculated attributes.

Usage expressions on structure lines

Each line of the superset structure, meaning each parent-to-child usage, carries a Boolean expression over the option families. A line with no expression always applies. Windchill describes this as expressions assigned to product structure items, and SAP describes selection conditions that pick components per variant. The expression language is deliberately small: equality tests on family values joined by AND, OR and NOT. A small language is a feature, because it keeps expressions analysable and keeps the resolver trivial.

There are two alternatives to per-line expressions that you will meet. One is the module approach, where the structure contains configurable modules (a “cab” placeholder) and each module has a few alternative designs, with the choice resolved at the module rather than at each leaf. The other is filter-based variants, where a saved filter selects a view of the structure for display and does not generate any new object. Both are legitimate. The first reduces the number of expressions you must author. The second suits engineering review but does not by itself give manufacturing a frozen BOM.

The constraint set

Usage expressions say what a configuration contains. Option rules (constraints) say which configurations may exist. The tractor cannot ship as a diesel, EU, standard-cab unit if the regional noise regulation demands the comfort cab’s insulation; that is encoded as a rule that forbids the combination. SAP’s documentation describes dependencies that “control which option combinations are allowed, for technical or marketing reasons” and also select the correct BOM components, which is the same split into constraints and selection logic.

Keep the two kinds of rule separate in your own model. Constraints are global and are the business of the configurator. Usage expressions are local to a line and are the business of the BOM. Mixing them, for example by using a usage expression to silently exclude a line in an invalid configuration, produces BOMs that look valid but are missing parts, and the failure is only found at assembly.

Effectivity: the time and unit dimension

Effectivity states when a line, a rule or a whole revision is valid, as opposed to which options select it. The common types are date effectivity (valid from and to a calendar date), unit or serial effectivity (valid from unit number N, or for a serial range), lot or batch effectivity, and for some industries milestone effectivity tied to a program event. Siemens describes feature effectivity by start and end date or by unit, with obsolescence to retire features in a controlled way.

Effectivity is not an option. An option is chosen per order by a customer or salesperson. Effectivity is decided per engineering change by the design authority, and the customer never sees it. Conflating them is the single most common modelling error I see, and it has a predictable consequence: the sales catalogue grows an option called “new HVAC” that nobody wants to choose, because customers just want the product that is current at the build date.

The distinction also determines how you resolve. Unit effectivity needs the unit number, which often does not exist at quoting time and is assigned at production scheduling. A BOM resolved at quote time with a date but no unit is therefore provisional, and the architecture must say so explicitly, by labelling the output as “quoted” versus “as planned” versus “as built”.

Deeper Analysis: Combinatorics, Resolution and Rule Validation

Why the arithmetic forces a superset

The worked numbers below are illustrative, not from a real product. Suppose a machine has eight option families with 4, 3, 5, 6, 3, 2, 4 and 3 choices. The raw configuration space is the product: 4 x 3 x 5 x 6 x 3 x 2 x 4 x 3 = 25,920 combinations. The number of choices to maintain is the sum: 30. A 150% BOM with per-choice usage expressions scales with the sum; one BOM per variant scales with the product.

Real rules prune the space, but rarely by orders of magnitude. If constraints remove 40 percent of combinations you still have about 15,500 valid configurations, and no company releases 15,500 BOMs by hand. More importantly, a change behaves like the product rather than the sum if variants are cloned. A fastener change on a shared frame touches the frame in every clone. In a superset it touches one line. That is the maintenance argument, and it is stronger than the storage argument.

The same arithmetic shows the limit. Most of those 25,920 combinations will never be ordered, so you should not pre-generate them. You resolve on demand and persist only what is ordered or built. The 150% BOM is the master, and the 100% BOM is a cached, frozen consequence of an order.

Figure 2: The resolution loop. Rules gate the request, usage expressions and effectivity gate each line, and quantities multiply down the tree.

The resolution algorithm

Resolution is a filtered tree walk with quantity multiplication. Given a configuration, an effectivity date and a unit number, it first verifies the configuration against the constraints, then visits the root’s children, keeps those whose usage expression is true and whose effectivity window contains the date and unit, multiplies quantities down the path, and recurses. If a kept line is a subassembly, its own children go through the same test.

Two properties matter. Pruning is top-down: if a subassembly line is excluded, everything beneath it vanishes without evaluation, so inactive branches cost nothing. And the output is a flattened, quantity-resolved list that also keeps the hierarchy, which is what ERP needs for planning.

The code below is a complete, runnable version. It uses only the Python standard library, restricts rule expressions to a safe subset of the Python grammar through the ast module (never call plain eval on rule text from a database), models date and unit effectivity, and rejects invalid configurations before resolving. I ran it with Python 3 and it prints the output shown after it.

"""Resolve a 150% BOM into a 100% BOM. Stdlib only."""
from dataclasses import dataclass
from itertools import product
import ast, datetime as dt

FAMILIES = {                      # option family -> allowed choices
    "DRIVE": ["ELEC", "DIESEL"],
    "CAB":   ["STD", "COMFORT"],
    "REGION": ["EU", "US"],
}
RULES = [                         # constraints every valid config must satisfy
    "not (DRIVE == 'DIESEL' and REGION == 'EU' and CAB == 'STD')",
    "not (DRIVE == 'ELEC' and CAB == 'COMFORT' and REGION == 'US')",
]

@dataclass
class Line:
    parent: str; part: str; qty: int
    expr: str = "True"            # Boolean usage rule over option families
    start: dt.date = dt.date.min  # date effectivity (inclusive)
    end: dt.date = dt.date.max    # exclusive
    unit_from: int = 0            # unit effectivity
    unit_to: int = 10**9

BOM150 = [
    Line("TRACTOR", "FRAME", 1),
    Line("TRACTOR", "MOTOR-E", 1, "DRIVE == 'ELEC'"),
    Line("TRACTOR", "ENGINE-D", 1, "DRIVE == 'DIESEL'"),
    Line("TRACTOR", "CAB-STD", 1, "CAB == 'STD'"),
    Line("TRACTOR", "CAB-COMF", 1, "CAB == 'COMFORT'"),
    Line("CAB-COMF", "HVAC-2", 1, "True", dt.date(2026, 3, 1)),
    Line("CAB-COMF", "HVAC-1", 1, "True", dt.date.min, dt.date(2026, 3, 1)),
    Line("TRACTOR", "LIGHTS-EU", 4, "REGION == 'EU'"),
    Line("TRACTOR", "LIGHTS-US", 2, "REGION == 'US'"),
    Line("TRACTOR", "BATTERY", 1, "DRIVE == 'ELEC'", unit_from=1000),
]

def evaluate(expr, cfg):
    tree = ast.parse(expr, mode="eval")
    allowed = (ast.Expression, ast.BoolOp, ast.And, ast.Or, ast.UnaryOp, ast.Not,
               ast.Compare, ast.Eq, ast.NotEq, ast.In, ast.Name, ast.Load,
               ast.Constant, ast.Tuple)
    for n in ast.walk(tree):
        if not isinstance(n, allowed):
            raise ValueError(f"disallowed syntax: {type(n).__name__}")
    return bool(eval(compile(tree, "<rule>", "eval"),
                     {"__builtins__": {}}, dict(cfg)))

def all_configs():
    names = list(FAMILIES)
    for combo in product(*(FAMILIES[n] for n in names)):
        yield dict(zip(names, combo))

def valid(cfg):
    return all(evaluate(r, cfg) for r in RULES)

def resolve(cfg, on, unit):
    if not valid(cfg):
        raise ValueError(f"invalid configuration: {cfg}")
    def active(l):
        return (evaluate(l.expr, cfg) and l.start <= on < l.end
                and l.unit_from <= unit < l.unit_to)
    out, stack = [], [("TRACTOR", 1, 0)]
    while stack:
        parent, mult, depth = stack.pop()
        for l in BOM150:
            if l.parent == parent and active(l):
                out.append((depth + 1, l.part, mult * l.qty))
                stack.append((l.part, mult * l.qty, depth + 1))
    return sorted(out)

if __name__ == "__main__":
    ok = [c for c in all_configs() if valid(c)]
    print(f"{len(ok)} valid of {sum(1 for _ in all_configs())} combinations")
    cfg = {"DRIVE": "ELEC", "CAB": "COMFORT", "REGION": "EU"}
    for depth, part, qty in resolve(cfg, dt.date(2026, 10, 10), unit=1200):
        print("  " * depth, part, "x", qty)

Running it prints 6 valid of 8 combinations and then a 100% BOM containing the battery (unit 1200 is past the unit-1000 cut-in), the comfort cab with the newer HVAC-2 (the date is after 1 March 2026), the electric motor, the frame and four EU light units. Change the unit to 900 and the battery disappears; change the date to February and HVAC-1 replaces HVAC-2. That single script demonstrates all three selection mechanisms: option expressions, date effectivity and unit effectivity.

The resolve function scans the whole line list for every parent, which is quadratic and fine for a demonstration. A production resolver indexes lines by parent, compiles each expression once into a bytecode or a bitmask evaluator, and caches results keyed by the tuple of configuration, date bucket and unit bucket. Bitmasks are worth knowing: if each choice is assigned a bit, a usage expression in disjunctive normal form becomes a few AND and compare operations per line, and evaluating a 50,000-line structure takes milliseconds in a compiled language.

Validating the rules themselves

Resolving a BOM proves nothing about whether the rules are correct. Three classes of defect are common, and each is machine-checkable because the option space is finite.

• Dead lines. A usage expression that is false in every valid configuration. The part is carried in the master for no reason, or, worse, someone believes it ships.
• Missing coverage. A valid configuration in which a mutually exclusive slot (the cab) selects zero or two parts. The product would have no cab or two.
• Contradictory constraints. A rule set that admits no valid configuration at all, or one that silently removes a configuration the business wants to sell.

For small spaces, enumerate. The following lint, which I also ran against the example, checks dead lines and slot coverage by brute force over valid configurations:

from bom import BOM150, all_configs, valid, evaluate

def lint():
    ok = [c for c in all_configs() if valid(c)]
    for l in BOM150:
        hits = sum(evaluate(l.expr, c) for c in ok)
        if hits == 0:
            print("DEAD LINE  ", l.parent, "->", l.part)
    for c in ok:
        n = sum(evaluate(l.expr, c) for l in BOM150
                if l.part in ("CAB-STD", "CAB-COMF"))
        assert n == 1, (c, n)
    print(len(ok), "valid configs checked")
lint()

It prints 6 valid configs checked with no dead lines. For the 25,920-combination example enumeration is still cheap, but real catalogues reach 10^20 or more raw combinations, and enumeration stops being viable. That is where SAT and constraint solvers earn their place. A usage expression and a constraint are both Boolean formulas over choice variables, with one-hot constraints per family (exactly one choice selected). Dead-line detection becomes “is the conjunction of constraints and the line’s expression satisfiable”, coverage becomes “is the conjunction of constraints and the negation of ‘exactly one cab part selected’ satisfiable”, and a satisfying assignment is a concrete counterexample configuration to show the engineer. Modern SAT solvers handle industrial feature models with thousands of variables, which is why this approach was adopted in software product lines first. Treat claims about specific solver performance on your model as something to measure; I have not benchmarked any here.

Ownership across PLM, configurator and ERP

Who owns what is the question that decides whether a variant programme succeeds. The responsibilities split along the lifecycle.

PLM owns the engineering truth: the 150% structure, the usage expressions, the option families as engineering defines them, the revision history and the effectivity attached to engineering changes. Teamcenter’s product configurator and Windchill’s options and variants both live here, and both describe a single repository for variability definition and content.

A product configurator (often inside a CPQ, meaning configure, price, quote, system) owns the customer-facing logic: which choices are visible, in what order, with what defaults, at what price, and with sales-side constraints such as market availability. Its constraint set must be a superset-compatible view of engineering’s, not a competing copy.

ERP owns execution: production orders, purchasing, costing and inventory. SAP’s variant configuration illustrates ERP-side ownership: the configurable material, characteristics, dependencies and configuration profile control the sales-order configuration and the BOM explosion at order time. Many companies run the configuration model natively in ERP and have PLM only supply the released parts and structure, which works but moves the rule authoring to a team that does not own the design.

Figure 3: A configure-to-order interaction. The configurator validates and prices, PLM resolves the engineering structure, ERP plans and builds, and the as-built record returns to PLM.

In Figure 3 the arrows are the integration contracts. The sales UI sends choices; the configurator validates them and asks PLM for the configured BOM; PLM resolves and returns the 100% BOM together with associated documents; the configurator places an order that carries the configuration identifier; ERP plans and produces; the as-built record flows back so engineering can later answer “which units have which revision”. The identifier is the critical artefact. It is a stable, versioned reference to the configuration and the rule-set revision it was validated against, so that the same order resolved a year later reproduces the same BOM, or explicitly reports why it no longer can.

Rule languages compared

Variant rules are written in one of four styles, and most tools mix them. Knowing the differences tells you what each can validate.

Style	Example	Strength	Weakness
Boolean usage expressions	DRIVE == 'ELEC' and REGION == 'EU'	Simple, analysable, trivially SAT-encoded	Verbose for numeric logic
Constraint-based	not (A and B), implications, cardinality	Declares what is illegal without listing what is legal	Hard to explain why a choice is greyed out
Product-structure filters	Saved filter applied to the structure	Fast for engineering review	Produces a view, not a frozen BOM
Procedural or table-driven	Case tables, formulas on parameters	Handles continuous values	Opaque to solvers, easy to hide bugs

Windchill’s documentation mentions expressions assigned to structure items, filtering criteria to check the selection logic, and parameters that feed variable constraints and case tables, so it covers three of these four styles. SAP’s dependencies likewise cover both selection of components and restriction of combinations. I could not verify the exact set of dependency types from the page I fetched, so check your release documentation before designing around a specific type.

A practical rule: use Boolean expressions wherever the domain is discrete, and confine procedural logic to parameters. The moment a procedure decides which part is selected, the BOM stops being analysable, and you lose dead-line detection exactly where you most need it.

Modular architecture changes the numbers

Platform and modular strategies attack the combinatorial problem from the product side rather than the data side. A modular architecture defines modules with stable interfaces, so that the choice within a module is independent of choices in other modules. If the cab module interfaces to the chassis through a defined mounting, hydraulic and electrical contract, then CAB and DRIVE no longer interact, and the constraint set loses all rules that coupled them.

This has a structural effect. Constraints that couple families are the cause of both validation complexity and customer confusion. A modular design reduces them; an integral design, where the engine bay, cooling and cab layout interact, multiplies them. A 150% BOM tool manages whatever variability you give it, and reducing the coupling between families is an engineering decision that no tool can make for you. Teams that count cross-family constraints per product line, and treat growth in that count as a design-quality signal, tend to catch problems early. I present that as a recommended practice and not as a documented industry statistic.

Two platform concepts help here. A platform fixes a common core (frame, electrical backbone) across product lines, so the 150% BOM only needs to express variation above it. A module library lets product lines share option families and the parts behind them, which is where option-family reuse in Windchill’s option sets and similar features pays off.

Where to resolve: engineering, order or plant

The architectural fork is when the 150% BOM collapses to a 100% BOM.

Resolve at order time in PLM when engineering structure is the product definition and plants build what engineering defines. The 100% eBOM is generated per order, then transformed to an mBOM. This keeps one source of variability logic, but the eBOM-to-mBOM transformation must run per order, so it must be automated and fast.

Resolve at order time in ERP when ERP holds a super BOM and configuration, as SAP describes. PLM releases parts and the super BOM structure; ERP’s configuration engine resolves per sales order. This puts execution close to planning, but design changes to rules must be synchronised into ERP and the two rule models can drift.

Resolve per plant when plants add local variation, such as local sourcing or tooling, on top of the engineering variant. That requires a 150% mBOM with plant-specific usage expressions, which is the most complex arrangement and should be adopted only when plant variation is substantial.

There is no universally correct answer. The decision follows who owns the rule model today, how often rules change, and whether your ERP’s configuration engine is already deeply deployed. What fails reliably is having two authoritative rule models, one in PLM and one in ERP, each edited separately.

Figure 4: Change impact on a superset BOM. A single edit fans out to many configurations, so the flow ends in a regression diff of resolved 100% BOMs.

Change impact in a superset structure

An engineering change in a 150% structure has an unusual property: one edit affects an unknown number of buildable products. Replacing the HVAC in the example touches every configuration with a comfort cab, which is a large share of the valid space. The change process must therefore answer, before release, which configurations are affected, which open orders and built units fall inside each, and what effectivity protects them.

The flow in Figure 4 does this in order. Locate the affected lines and rules. Re-evaluate all valid configurations, by enumeration or solver, to produce the impacted set. Check open orders and built units, and set effectivity so units already in production keep the old part. Release the revision. Notify the configurator and ERP. Finally, diff the resolved 100% BOMs before and after, for a representative or exhaustive set of configurations, and require the diff to match the change’s declared intent. That last step is a regression test for engineering data, and it catches the rule typo that would otherwise silently delete a part from a variant nobody checked. Our article on engineering change management with ECR and ECO covers the surrounding approval workflow in detail.

Note the two kinds of change. A structural change alters the superset lines. A rule change alters selection or constraints without touching the parts. Rule changes feel cheap, because no drawing changes, yet they alter what customers receive, so they deserve the same revision control, approval and effectivity as part changes. Teams that version parts rigorously and rules loosely eventually ship an unreleased rule.

The as-built record

Resolution produces a frozen 100% BOM per order, but the configuration identifier alone is not sufficient to reconstruct history. Store four things with each order or serial: the option choices, the rule-set revision, the structure revision, and the effectivity context (date and unit) used. With those four, the resolver can reproduce the BOM deterministically. Without the rule-set revision, a later rule change makes historic orders unreproducible, a failure that tends to surface only during a warranty claim or a regulatory audit.

For service, the as-built record is also the entry point to the digital twin. A serial-level 100% BOM, plus the revision of every part actually installed, is the structural backbone onto which sensor data, firmware versions and maintenance history attach. If your twin cannot tell you which cab variant a machine carries, it cannot select the right diagnostic model.

Trade-offs, Gotchas, and What Goes Wrong

The superset becomes unreadable. A 150% structure with thousands of expressions is difficult to review as a tree. Engineers lose the ability to look at a drawing tree and see a product. Mitigate with saved views per variant family, named sub-configurations such as “EU electric comfort” for review, and a rule of thumb that no single line should carry an expression longer than a screen.

Expression sprawl and duplicated logic. The same condition (“EU and diesel”) gets copied into dozens of lines. When the underlying rule changes, some copies are missed. Define composite options, named once, and reference them. This is the same remedy as removing duplicated code.

Effectivity treated as an option. Covered above, and common. The signal is an option family with a name like “version” or “generation”. Move that dimension to effectivity.

Two rule models that drift. PLM, CPQ and ERP each keep their own constraint set. In the first year they match. Later they do not, and a configuration sells that cannot be built. Pick one authoritative rule store and publish read-only projections of it, or generate the downstream representations from it.

Hidden coupling through parameters. A numeric parameter such as motor power quietly selects different parts through a table. The solver cannot see inside, and the lint misses it. Keep tables small, test them with boundary values, and prefer to discretise a parameter into named bands if the choice affects the structure.

Non-deterministic resolution. If resolution depends on “latest released revision” at call time, the same order resolves differently on different days. The fix is to bind the structure revision at order time and record it, as described above.

Performance cliffs. Resolution is cheap per order but expensive per catalogue. A nightly job that resolves every valid configuration to refresh pricing can take hours when the space is large. Cache by configuration hash, invalidate by rule and structure revision, and resolve only what is demanded.

Migration of legacy variants. Existing clones differ in ways nobody documented. Building a 150% BOM by merging them requires deciding, for each difference, whether it is a real variant or an accident of history. Budget for that analysis; it is usually the longest part of the project, and the tooling only automates the merge.

Over-promising the tools. Vendors describe configurators as single-repository solutions. The Siemens page I reviewed, for instance, claims an out-of-the-box approach with no client customisation. Take such statements as a description of intent and verify against your own rule complexity, integration landscape and release; I have not tested any of these products.

Practical Recommendations

Start by deciding the ownership question before choosing a tool. Write down, on one page, who authors option families, who authors usage expressions, who authors sales constraints, where the authoritative rule set lives, and when the 150% BOM collapses. Most programme failures trace to an unanswered line on that page.

Then model deliberately. Keep option families discrete and few. Move time-based change to effectivity. Reduce cross-family coupling in the design before encoding it in rules. Name composite conditions once. Keep procedural logic confined to parameters.

Treat the rules as code. Version them with the same rigour as parts, run the lint and solver checks in the release pipeline, and require a before-and-after diff of resolved 100% BOMs on every structure or rule change. Store the full reproduction record (choices, rule revision, structure revision, date and unit) with every order.

Finally, integrate through identifiers and contracts, not copies. The configurator should call PLM’s resolver, or consume generated rules, rather than maintain a second model.

• [ ] One-page ownership matrix signed off by engineering, sales and manufacturing
• [ ] Option families discrete, reused across products, named in a shared register
• [ ] Effectivity (date, unit, lot) modelled separately from options
• [ ] Constraint set stored once, with projections to CPQ and ERP generated, not typed
• [ ] Dead-line, coverage and satisfiability checks in the release pipeline
• [ ] Regression diff of resolved 100% BOMs required on every change
• [ ] Reproduction record stored per order: choices, rule revision, structure revision, date, unit
• [ ] Performance budget for resolution and a caching strategy with revision-based invalidation
• [ ] Plan for the legacy variant merge, including a human review of each difference

Frequently Asked Questions

What is a 150% BOM?

A 150% BOM is a single superset bill of materials containing every part that any variant of a product family might use, with each usage line tagged by a rule saying when it applies. It is not a measurement; the percentage means “more than one product’s worth”. A resolver applies a configuration and effectivity context to derive the 100% BOM of one buildable product.

What is the difference between a 150% BOM and a 100% BOM?

A 100% BOM lists exactly the parts of one specific, buildable product, with no alternatives and no conditional lines. A 150% BOM is the master from which many 100% BOMs are derived. You maintain the 150% BOM, and you release, plan and build from the 100% BOM. Confusing the two is the root of most variant-management errors.

What is the difference between options and effectivity?

An option is a choice made per order by a customer or salesperson, such as drivetrain or cab grade. Effectivity is decided by engineering and states when a line or revision is valid, by date, unit or lot. Customers do not choose effectivity. Using options to represent engineering revisions clutters the catalogue and breaks traceability.

Does a product configurator replace the 150% BOM?

No. A configurator guides a user to a valid, priced selection using rules; the 150% BOM defines which parts that selection means. They share the rule set. A well-designed architecture keeps one authoritative constraint model and lets both the configurator and the BOM resolver use it, rather than duplicating logic in each.

How do you validate variant rules?

Rules are Boolean formulas over a finite option space, so they are machine-checkable. For small spaces, enumerate every combination and check for dead lines, missing or doubled slot coverage and impossible rule sets. For large spaces, encode the rules as SAT or constraint problems, and ask the solver for counterexample configurations that violate a coverage or consistency property.

Should variability live in PLM or ERP?

It depends on who owns the rule model today. Keeping variability in PLM keeps engineering authority and revision control in one place. Keeping it in ERP, as with a super BOM and configuration in SAP, puts resolution next to planning. What matters most is that only one system is authoritative, and the other receives generated, read-only projections.

Further Reading

Internal:

• eBOM to mBOM transformation: PLM and ERP bill of materials architecture
• Engineering change management: ECR and ECO architecture in PLM

External primary sources:

• PTC Windchill Options and Variants capabilities, vendor documentation for overloaded product structures, options, expressions and parameters.
• SAP help: variant configuration with classes, characteristics, dependencies and super BOMs, archived vendor documentation (older release, so check current S/4HANA documentation).
• Siemens: Introducing Teamcenter Product Configurator for Variability Management, vendor description of variability management and feature effectivity.
• Batory, D. “Feature Models, Grammars, and Propositional Formulas”, SPLC 2005, doi:10.1007/11554844_3, on mapping feature models to propositional logic for automated analysis.

By Riju — about