Product Configurator CPQ: Constraint Solving, 150% BOM and Variant Management

A manufacturer sells a drive system with five motor sizes, three voltages, four cooling options, six enclosure ratings and a dozen accessories. Nobody designed 4,320 distinct products. Engineering designed a modular platform, and the sales organization is now asked to quote any valid combination in minutes. The failure mode is familiar: a salesperson promises a combination that cannot be built, manufacturing discovers it at order release, and a three-week “engineering clarification” begins. A well-built product configurator CPQ stack exists to make that failure impossible by construction.

This is harder than it looks, because three different systems each own part of the truth. PLM knows what can be built, the configurator knows what may be combined, the pricing engine knows what it costs, and ERP knows how to build it. The interesting engineering is in the seams between them: where the rules live, how a customer’s choices become a buildable bill of materials, and how you prove a rule set is correct before a customer finds out it is not.

What this covers: rule-based versus constraint-based versus model-based configuration, the 150% BOM and how it resolves to a 100% BOM, the layers of a CPQ pricing engine, PLM-CPQ-ERP integration and rule ownership, combinatorial explosion, rule-set testing, engineer-to-order edge cases, and a runnable constraint-solver example.

Context and Background

Configure, price, quote (CPQ) software emerged from three older disciplines that were solved separately. Configuration engines came from artificial-intelligence research on expert systems in the 1980s, and the classic problem was the configuration of computer systems. Pricing was handled by ERP price lists and discount tables. Quoting was a document problem, handled by word processors and spreadsheets. CPQ welded these together so that a valid configuration, a defensible price and a contractual quote document come out of one flow.

The term “variant management” is broader and older. It covers how an organization represents the many versions of a product across engineering, manufacturing and sales. Two strategies dominate. In the first, every sellable variant gets its own item and its own BOM. This is easy to understand and disastrous to maintain beyond a few dozen variants, because a change to a shared sub-assembly must be replicated everywhere. In the second, engineering maintains one superset structure plus rules that select the right parts per order. That superset is the 150 percent BOM, and it is the foundation of almost every scalable variant approach.

The incumbents sit on both sides of the PLM and ERP boundary. SAP’s Variant Configuration uses classes, characteristics, object dependencies and selection conditions to explode a configurable material into a BOM; SAP documents this as part of its BOM explosion for variant configuration. PLM suites offer option and variant modules of their own, which we compare at platform level in our SaaS PLM comparison of Teamcenter X, 3DEXPERIENCE and Windchill. Dedicated CPQ vendors add guided selling, quoting workflows and approvals on top. Vendor feature sets change quickly, so treat any named product capability in this article as a pointer to documentation, not as a current-version guarantee.

The thesis of this article is simple and, in my experience, under-appreciated: the hard part of CPQ is not the solver, it is rule governance. A solver will faithfully enforce whatever rules you give it, including wrong ones. The architecture that wins is the one that makes rules a versioned, tested, single-owner asset, rather than logic scattered across a CPQ tool, a PLM option table and an ERP characteristic profile.

The Reference Architecture: Where Configuration Logic Lives

A CPQ stack has five functional blocks, and the useful question for each is who owns the data and who may change it.

The product model defines features (motor power, voltage), options within each feature (2 kW, 5 kW), and the relationships between them. The configuration engine evaluates a partial selection against that model and answers three questions: is this selection consistent so far, which options are still available, and is the selection complete. The pricing engine turns a valid configuration plus customer context into a price. The quote layer handles documents, approvals and expiry. Finally, the order handoff carries a configuration identifier or a set of option codes to ERP, where it resolves into a manufacturable BOM.

Figure 1: Reference architecture for a product configurator CPQ stack. The rule library is fed from the PLM option model, and the same option codes drive both the quote and the resolved BOM.

The figure shows the property that matters most: the rule library and the 150 percent structure both originate in PLM, and the option codes on the order are the only join key between sales and manufacturing. If sales can sell an option code that the BOM does not recognize, or the BOM carries a selection condition that the configurator never enforces, the two halves drift apart.

What a configuration engine actually answers

A configuration engine is not a form with dropdowns. It maintains a constraint network and offers four services. Validation checks that a complete selection satisfies every rule. Propagation removes options that have become impossible given choices made so far, which is what makes a guided-selling screen grey out a 5 kW motor after air cooling is chosen. Completion fills in choices that are forced. Explanation reports why an option is unavailable, which separates a tool that sales can use from one that produces support tickets.

Of these, explanation is the most neglected and the most valuable. When a rule set has several hundred constraints, “this option is unavailable” is useless. “Unavailable because 5 kW motor requires liquid cooling, and you selected air” is actionable, and it can be computed from the conflict set the solver produces.

Why option codes, not part numbers

The handoff between systems should carry option codes, a compact vocabulary of choices, rather than part numbers. Part numbers change when engineering revises a component; option codes describe customer intent and stay stable. The resolution from intent to parts happens late, at the moment the order is released, against the engineering structure effective on the required date. This late binding is what lets an engineering change take effect without touching every open quote, a topic that connects directly to how engineering change management and effectivity work in the digital thread.

Rule ownership: the decision that shapes everything

There are three plausible homes for configuration rules, and each has a cost.

Putting rules in the CPQ tool gives sales fast iteration and good user experience, but it means engineering constraints are duplicated in a system engineering does not control. Putting rules in ERP, as classic variant configuration does, gives strong transactional integrity and automatic BOM resolution, but ERP modeling is slow to change and user interfaces are rarely sales-friendly. Putting rules in PLM keeps them next to the design intent, but PLM option modules are often weaker at interactive, high-volume evaluation.

The pattern that holds up is to author rules once, in a neutral and testable form owned by product engineering, and publish them to each consumer. The CPQ tool and ERP then execute the same published rule set, and a release pipeline proves equivalence before either is updated. I return to this in the integration section.

Three Families of Configuration Technology

The research literature on product configuration usually divides engines into three families. They differ in how knowledge is represented and, as a consequence, in what they can explain and how well they scale.

Figure 2: Three families of configuration knowledge representation and where each tends to fit.

Rule-based configuration

A rule-based engine stores knowledge as if-then rules: if voltage is 400 V, then add a 400 V power supply; if enclosure is IP67, then require seal kit. Rules fire in some order, often by forward chaining, and the engine’s behaviour depends on which rules exist and in which order they are evaluated.

The strengths are real. Rules are easy to explain to non-specialists, easy to write in a spreadsheet, and cheap to execute. The weaknesses appear with scale. Rules are directional, so “5 kW requires liquid cooling” does not automatically give you “air cooling excludes 5 kW” unless someone writes the second rule too. Rule interactions create order dependence and cycles. Detecting contradictions or dead options requires separate analysis, because nothing in the representation guarantees consistency. A rule base of a few hundred rules is manageable; a few thousand without tooling is where “nobody dares touch it” begins.

Constraint-based configuration

A constraint-based engine states what must hold rather than how to derive it. The model is a set of variables (features), a finite domain for each (the options), and constraints over them. This is a constraint satisfaction problem (CSP), and a configuration is an assignment of values that satisfies every constraint. The secondary keyphrase here, constraint-based configuration, names exactly this representation.

Declarative constraints are symmetric. “5 kW requires liquid cooling” is a single implication, and the solver derives its contrapositive, that air cooling excludes 5 kW, without anyone writing it. The same model supports validation, propagation, completion and explanation. Solving can use classic CSP search with constraint propagation, boolean satisfiability (SAT) after encoding to propositional logic, or satisfiability modulo theories (SMT) when arithmetic over numeric attributes is involved, such as total power draw not exceeding supply capacity.

The cost is that the knowledge engineer must think declaratively, and that solver performance depends on the structure of the model. Most commercial configurators are constraint-based at heart even when the authoring surface looks like rules, because the guarantees are too valuable to give up. Google’s open-source OR-Tools offers a CP-SAT solver whose boolean and integer modeling interface is a good match; see the CpModelBuilder reference for the constraint methods used later in this article.

Model-based configuration

Model-based, or structure-based, configuration describes the product as a library of component types with ports or interfaces and compatibility conditions, and lets the engine generate a structure by connecting components. It is natural when the number of instances is not fixed in advance: how many cooling loops, how many I/O modules, how many racks. A flat set of option variables cannot express “between one and sixteen modules, each of which has its own type.”

This family dominates engineer-to-order and large systems such as telecom racks, process skids and building systems. It is more expensive to model and often relies on generative constraints, where variables are created during the search. For fixed-structure products with option-style variation, it is overkill.

Choosing between them

A practical rule: if your variation is a fixed set of features with finite options, use a constraint-based engine and treat the 150 percent BOM as the structure. If your variation includes repeating or nested structure of unknown size, you need model-based capability, possibly layered on constraints. Pure rule-based engines remain defensible only for small, stable catalogs.

From 150% BOM to 100% BOM: The Resolution Mechanism

The 150 percent BOM, sometimes called a super BOM or maximal BOM, is a single structure that contains every part that could appear in any valid configuration. The name is a loose convention: it expresses that the structure is larger than any one product, not that it is literally 1.5 times. It is not a bill of materials for any real product. A 100 percent BOM, by contrast, is the exact bill for one configured unit.

Each line in the 150 percent structure carries a selection condition: a boolean expression over option codes that decides whether the line is included. Lines without a condition are always included. SAP’s training material describes the same concept as selection conditions in BOMs and task lists, evaluated against the characteristic values of the configuration; see the SAP Learning page on defining selection conditions in BOMs and task lists.

Figure 3: Resolving a 150 percent BOM into a 100 percent BOM and then a manufacturing BOM.

The resolution algorithm

Resolution is a tree walk. Starting at the root, evaluate each child’s selection condition against the configuration and the required date. Drop children whose condition is false or whose effectivity does not cover the date, keep the rest, and recurse. Quantities can be constants or formulas over characteristics: four seals for IP67 enclosures, or a cable length equal to the selected rail length. Sub-assemblies that are themselves configurable receive a derived sub-configuration, which is why nested variant structures need rules that map parent selections to child characteristics.

Worked example, with illustrative numbers. Suppose the superset has 9 lines for a toy drive: frame, two motors, two power supplies, two cooling kits, seals and an ATEX plate. A 5 kW, 400 V, liquid-cooled, IP67, ATEX configuration keeps frame, 5 kW motor, 400 V supply, pump kit, 4 seals and the plate: six of nine lines. The runnable example later reproduces exactly this resolution.

Effectivity: the second filter

Selection conditions answer “does this option need this part”. Effectivity answers “is this part valid on the date or serial range of this order.” They are orthogonal and both must be true. A pump kit may be superseded by a new design effective from a given date; the condition still selects “pump kit” but effectivity picks the revision. Mixing the two, for instance encoding dates inside option conditions, is a common anti-pattern because it makes rules unreadable and breaks when dates slip.

Engineering BOM to manufacturing BOM

The resolved 100 percent structure is still an engineering view: it reflects how the product is designed. Manufacturing needs a different view, organized by plant, work centre and assembly sequence. The transformation adds phantom assemblies, consolidates or splits sub-assemblies, adds consumables such as fasteners and adhesives that engineering does not model, assigns operations and routing, and substitutes alternates where a plant sources a different but equivalent part.

Two plants building the same configuration can legitimately produce different manufacturing BOMs. This is why the engineering-to-manufacturing step cannot be a straight copy, and why it belongs in a governed transformation rather than in manual re-keying. A thorough PLM data migration with validation and cutover strategy explicitly checks that these two views stay reconcilable after a move to new systems.

Combinatorial Explosion and What a Solver Does About It

Variant counts multiply. If a product has independent features with option counts n1, n2, n3 and so on, the raw space is the product. Ten features with four options each gives 4^10 = 1,048,576 raw combinations; twenty such features gives over a trillion. These are illustrative figures, but the shape is real, and it is why no one enumerates variants by hand.

The raw space overstates reality, because constraints cut it down sharply. In the toy example later in this article, five yes-or-no style choices give 32 raw combinations, and four rules reduce them to 13 valid ones. In real catalogs the valid fraction is often tiny, which is both good news (few customers can order nonsense) and bad news (the valid region is a thin, irregular shape that humans cannot reason about).

Why this is tractable in practice

Generic constraint satisfaction is NP-complete, so worst-case hardness is real. Product configuration instances are usually friendlier than worst cases, for structural reasons. Constraints are mostly local: a handful of features interact, not all of them at once. Domains are small. Most rules are implications, exclusions or table constraints, which propagate cheaply. Modern SAT and CP-SAT solvers exploit this with clause learning and propagation, and interactive configuration, where choices arrive one at a time, requires only incremental propagation rather than full search.

Two techniques are worth knowing. The first is compiling the constraint model once into a compact decision structure such as a binary decision diagram (BDD), after which validity checks and option availability are lookups. This trades heavy offline compilation for very fast online response, but BDD size can blow up for poorly ordered or arithmetic-heavy models. The second is incremental solving with assumptions: keep a solver instance alive and ask whether each remaining option is still satisfiable under the current selections, which is how propagation is typically implemented on top of SAT.

Where explosion still bites

Three situations break the comfortable picture. Numeric constraints, such as sums of power or weight across many components, push you toward SMT or integer programming and away from pure boolean propagation. Unbounded structure, such as an arbitrary number of modules, needs model-based generation. And global optimization, such as finding the cheapest valid configuration that satisfies a requirement, turns a decision problem into an optimization problem with a different cost profile. A CP-SAT solver handles the last well for moderate sizes, but you should measure on your own model rather than trust vendor figures.

The human explosion

There is a second combinatorial problem: the number of rules a team must maintain. Rule count tends to grow faster than option count, because each new option interacts with several existing ones. A discipline that helps is to model compatibility at the level of feature groups and use tables rather than pairwise rules. A compatibility matrix between motor and drive families is easier to audit than forty implications that encode the same facts.

The Pricing Engine: Layers Between a Valid Configuration and a Quote

A configuration is valid or it is not. A price is a negotiated, contextual number computed through layers, and conflating the layers is a classic source of audit pain. A useful decomposition has five layers evaluated in order.

Base and option pricing sets list prices from the price book: a base price for the platform plus a price per selected option, sometimes with dependent prices (the cost of a cabinet depends on the number of modules). Prices come from a price list keyed by currency, region and validity period, which is another effectivity dimension.

Cost-plus and cost roll-up is used when price derives from cost, notably in engineer-to-order. Material cost comes from the resolved BOM, labour from the routing, and margin from policy. Note the dependency: this layer needs the 100 percent BOM, which means the configurator may need to call the resolution logic during pricing.

Customer and contract pricing overrides list prices with agreed prices, tiered volume discounts and customer-specific price lists. Precedence rules matter here: does a contract price beat a promotion, and can discounts stack?

Adjustments and discount governance apply manual discounts, bundles and promotions, constrained by guardrails. Discounts beyond a threshold trigger an approval workflow, and the approval matrix is part of the quote layer, not the pricing arithmetic.

Taxes, freight and currency are applied last, often delegated to external tax or logistics services.

Making pricing explainable and deterministic

Two properties are non-negotiable. Pricing must be deterministic: the same configuration, customer and date must produce the same price, which requires pinning price-list versions on the quote. And pricing must be explainable: store a price waterfall, one line per layer, with the rule or list that produced each amount. When a customer disputes a quote six months later, the waterfall is the evidence.

A worked example with illustrative numbers: list price for the base drive is 10,000 and the 5 kW motor option adds 2,400 and the ATEX package adds 1,800, for 14,200. A contract discount of 8 percent applies to the option-inclusive subtotal, giving 13,064. A manual discount request of a further 5 percent would take the price to 12,411, and if policy requires approval above 10 percent total discount, the cumulative discount here of 12.6 percent triggers it. The point is not the figures but the order: swapping the order of percentage and fixed discounts changes the result, so the order must be explicit and tested.

Pricing for configurations that engineering has not seen

If a configuration includes a non-standard request, a “special,” the price cannot come from a price book. The workflow must park the quote, create an engineering request, and resume once cost is known. Designing this fork explicitly, rather than letting sales fall back to a spreadsheet, is one of the biggest differences between a CPQ that is trusted and one that is routinely bypassed.

PLM-CPQ-ERP Integration and Rule Ownership

The integration question is not primarily technical. Most pairs of these systems can exchange data through REST APIs, files or middleware. The difficult question is which system is the source of truth for each kind of knowledge, and how changes propagate.

Figure 4: Sequence from publishing the option model in PLM through quoting in CPQ to BOM resolution for an ERP order.

A sensible ownership split

Product engineering, working in PLM, owns the structure, the options, the compatibility rules and the selection conditions, because these express design intent and safety constraints. Sales operations owns pricing, discounts and quote templates. Manufacturing owns routings, plant-specific alternates and the manufacturing BOM transformation. ERP owns transactional state: the sales order, the planned order and the production order.

A subtle but important point is that rules fall into two classes. Technical rules state what can physically or safely be combined; engineering must own these, and CPQ may never override them. Commercial rules state what the company is willing to sell together, such as bundles, regional restrictions and portfolio simplification; sales may own these. Mixing both classes in one undifferentiated rule base makes it impossible to tell whether a blocked option is a safety issue or a marketing decision.

Integration patterns

There are three common patterns. In publish and replicate, PLM exports an option model and rule set that CPQ imports as its own configuration model; this gives fast interactive response but creates a copy that can drift. In shared service, a single configuration service holds the rules and both CPQ and ERP call it; this removes drift at the price of a runtime dependency and a latency budget. In ERP-centric, the sales front end calls ERP’s configuration engine directly, which is simplest where one ERP vendor dominates but usually delivers a weaker sales experience.

Whichever pattern you choose, use a release mechanism, not ad hoc edits. A rule set version should have an identifier, an effectivity date, an author and an approval record; each quote should store the rule set version it was validated against; and re-validation of open quotes should be a defined event when a new version goes live, not a surprise.

Reconciliation: proving two systems agree

If the same rules execute in two places, you need an equivalence check. The practical form is a regression corpus: a large sample of configurations, each with the expected resolved BOM, run through both the CPQ validation and the ERP explosion, with differences reported. Differences are almost always real defects: a condition that was translated incorrectly, a unit of measure mismatch, or an effectivity gap.

The cost of getting this wrong

The costs are mostly hidden. Rework in order engineering, schedule slips from late discovery of invalid configurations, and sales mistrust of the tool are rarely tracked as a single number. I would not cite an industry-wide figure here, because I could not verify a reliable one; instead, measure your own: the share of orders that need engineering clarification after booking is a direct, auditable indicator of how well rules cover reality.

A Runnable Example: Constraint Solving and BOM Resolution

The following Python script uses OR-Tools CP-SAT (pip install ortools). I ran it with OR-Tools 9.15 for this article. It models a toy drive with three one-of-n features, two flags, four compatibility rules and a nine-line 150 percent BOM, enumerates every valid configuration, resolves one to a 100 percent BOM, and rejects an invalid customer request.

from ortools.sat.python import cp_model

m = cp_model.CpModel()
motor = {k: m.NewBoolVar(k) for k in ("M1_2kW", "M2_5kW")}
volt  = {k: m.NewBoolVar(k) for k in ("V230", "V400")}
cool  = {k: m.NewBoolVar(k) for k in ("AIR", "LIQUID")}
ip67  = m.NewBoolVar("IP67")
atex  = m.NewBoolVar("ATEX")

for group in (motor, volt, cool):          # exactly one per feature
    m.AddExactlyOne(group.values())
m.AddImplication(motor["M2_5kW"], volt["V400"])        # rule 1: requires
m.AddImplication(motor["M2_5kW"], cool["LIQUID"])      # rule 2: requires
m.AddBoolOr([atex.Not(), ip67])                        # rule 3: ATEX implies IP67
m.AddBoolOr([atex.Not(), cool["AIR"].Not()])           # rule 4: ATEX excludes AIR

# 150% BOM: (part, qty, selection condition as a literal or None)
bom150 = [("FRAME-01", 1, None), ("MOT-2K", 1, motor["M1_2kW"]),
          ("MOT-5K", 1, motor["M2_5kW"]), ("PSU-230", 1, volt["V230"]),
          ("PSU-400", 1, volt["V400"]), ("FAN-KIT", 1, cool["AIR"]),
          ("PUMP-KIT", 1, cool["LIQUID"]), ("SEAL-IP67", 4, ip67),
          ("ATEX-CERT-PLATE", 1, atex)]

class Collect(cp_model.CpSolverSolutionCallback):
    def __init__(self, vs):
        super().__init__(); self.vs, self.sols = vs, []
    def on_solution_callback(self):
        self.sols.append(frozenset(v.Name() for v in self.vs if self.Value(v)))

allv = [*motor.values(), *volt.values(), *cool.values(), ip67, atex]
s = cp_model.CpSolver(); s.parameters.enumerate_all_solutions = True
cb = Collect(allv); s.Solve(m, cb)
print("valid configurations:", len(cb.sols), "of", 2*2*2*2*2, "raw combinations")

def resolve(sel):   # 150% -> 100%
    return [(p, q) for p, q, c in bom150 if c is None or c.Name() in sel]

for sel in cb.sols:
    if "ATEX" in sel and "M2_5kW" in sel:
        print(sorted(sel)); print(resolve(sel)); break

# Validate a customer request: 5 kW + air cooling
m2 = m.Clone(); m2.Add(motor["M2_5kW"] == 1); m2.Add(cool["AIR"] == 1)
print("5kW+AIR:", s.StatusName(cp_model.CpSolver().Solve(m2)))

The output on my run was: 13 valid configurations out of 32 raw combinations; the resolved ATEX configuration ['ATEX', 'IP67', 'LIQUID', 'M2_5kW', 'V400'] produced FRAME-01, MOT-5K, PSU-400, PUMP-KIT, SEAL-IP67 x4, ATEX-CERT-PLATE; and the request for a 5 kW motor with air cooling returned INFEASIBLE.

What the example demonstrates

Rules 1 and 2 are written once as implications, yet the solver rejects air cooling with the 5 kW motor, which would need an explicit extra rule in a rule-based engine. The selection conditions on the BOM lines are literals of the same model, so the configuration and the BOM cannot refer to different option vocabularies. That is the deepest design lesson: the option code is the shared vocabulary, and the solver and the BOM must be bound to it, not to each other.

To extend this into an interactive propagation loop, you would, for each unselected option, solve the model with that option forced true under the current assumptions and grey out those that return infeasible. For explanation, CP-SAT supports assumptions and can return a subset of assumptions that caused infeasibility (SufficientAssumptionsForInfeasibility), which you can map back to rule names. I did not exercise that call in the script above, so verify the API against the current documentation before relying on it.

Testing and Validating Rule Sets

Testing a rule set is a different activity from testing code, because the failures are in the specification rather than the implementation. A rule set can execute perfectly and still be wrong. Four kinds of checks, from cheap to expensive, cover most defects.

Structural lint. Detect rules referencing unknown options, options that no rule or BOM line uses, BOM lines whose selection conditions are never satisfiable, and duplicate or contradictory rules. These are static and run in seconds.

Satisfiability and dead-option analysis. Ask the solver whether the model has any valid configuration at all, and for each option whether some valid configuration includes it. An option that can never be selected is a dead option, usually the result of an over-constraining rule. A feature with a single remaining option is a forced choice and may indicate a mis-modeled exclusion. The example’s model passes this check: all options are reachable in at least one of the 13 configurations, which you can confirm by iterating the solutions.

BOM coverage. For every valid configuration, or a statistically meaningful sample when enumeration is infeasible, resolve the BOM and check invariants. Each valid configuration must resolve to a non-empty structure, must include exactly one motor, must have no line with zero quantity, and must not contain two mutually exclusive parts. The most valuable invariant is no orphan options: every option that can be sold must change at least one BOM line, otherwise the customer pays for something that is never built. The reverse also matters: every conditional BOM line must be reachable.

Differential and regression testing. Keep a golden corpus of real past orders and expected outcomes. After each rule change, re-run the corpus and review every difference. Differences are not all bugs: a deliberate rule change should change some outputs, and the review confirms that exactly the intended ones changed. Combine this with pairwise or t-wise combinatorial testing when the space is too large to enumerate; pairwise coverage is a well-known heuristic, though it can miss defects that require three or more simultaneous options.

Treat rules as code

Store rules in version control, review changes, run the checks in continuous integration, and block merges that fail. A rule set that can be changed by clicking in a production admin screen with no review is the single most common root cause I would look for when a configurator “mysteriously” starts producing bad orders. This is opinion based on common practice rather than a measured statistic.

Engineer-to-Order Edge Cases

Configure-to-order assumes the design space is closed: every valid product was engineered in advance. Engineer-to-order (ETO) breaks that assumption, and the architecture has to bend.

Open design space. A customer wants a skid three metres longer than any standard. The configurator cannot validate it, because the rules do not cover it. The right behaviour is a controlled escape: allow a “special” line that routes to engineering, with the configuration frozen at the point of divergence, and bring the result back as a new or extended option once engineered.

Parametric items. Some parts are defined by dimensions rather than choices: a rail cut to length, a tank of given volume. These are numeric variables with ranges, and the BOM line quantity or part attributes are formulas. Integer arithmetic in CP-SAT handles bounded ranges; continuous physics generally does not belong in the solver and should be delegated to a calculation service whose result is validated against a tolerance.

Customer-specific parts and one-offs. Special parts created for one order should be created as items with a restricted effectivity or an ownership marker, so they do not pollute the catalog. After the project, a deliberate review decides whether to promote them to standard options.

Late design change. ETO orders live for months, and engineering changes arrive mid-build. The order should be pinned to a configuration and a structure revision, with change impact analysis deciding whether the change applies to this order, a pattern that rests on the ECR, ECO and ECN processes discussed in our change management article.

Pricing under uncertainty. Cost for the open parts is an estimate. The quote should separate firm lines from estimated ones, carry a contingency policy, and record the estimate’s basis, so that margin analysis after delivery can improve future estimates.

Trade-offs, Gotchas, and What Goes Wrong

The 150 percent BOM becomes unreadable. A superset structure grows with every option, and after a decade nobody can read it. Lines with conditions nobody understands accumulate. Mitigate with modular sub-assemblies, each with a small, documented interface, and periodic pruning of lines whose conditions can never be true.

Overloaded option codes. If one code means different things in different product lines, or the same choice has two codes, rules and BOMs diverge silently. Governance of the option vocabulary, including a catalog with owners, is cheap compared with the cost of reconciling meanings later.

Rule drift between systems. The classic failure is a rule fixed in CPQ and forgotten in ERP. Prevent it structurally with single-source authoring and automated equivalence tests, not with good intentions.

Solver as a black box. A solver that says “infeasible” without explanation trains users to work around it. Invest in explanations early, and surface them in the sales interface.

Performance cliffs. Interactive response must stay within a user-tolerable budget, and models that are fast in testing can slow sharply after a rule change introduces dense interactions. Track solve time as a metric in the test pipeline. I would not quote a universal latency target; set one from your own user research.

Over-constraining and under-constraining. Over-constraining makes valid products unsellable and shows up as lost deals. Under-constraining lets invalid products through and shows up as rework. The second is more visible and therefore more feared, but the first is more expensive in aggregate because it is silent.

Variant explosion by sales pressure. CPQ makes it easy to add options, which tempts the business to add many. Each option multiplies test and supply-chain complexity. The honest trade-off is that a configurator reduces the cost of variety but never makes it free, and portfolio discipline remains a management task.

Migrations. Moving configuration knowledge between systems is among the riskiest parts of any PLM or ERP programme because the logic is implicit in objects and dependencies, not in a clean data table. Budget for rule extraction and equivalence testing, and consult a structured approach such as the one in our PLM data migration guide.

Practical Recommendations

Start from the vocabulary, not the tool. Define the feature and option catalog, name an owner for each feature, and fix the option-code convention before choosing a configuration engine. Everything downstream depends on it.

Pick the configuration approach by the shape of your variation. Fixed features with finite options call for a constraint-based engine and a 150 percent BOM. Repeating or nested structure calls for model-based capability. Reserve pure rules for small catalogs. Separate technical from commercial rules from day one, and give them different owners and approval paths.

Author rules once and publish them. Whether the consumer is CPQ, ERP or both, a single versioned source avoids the drift that produces most field incidents. Make each quote store the rule-set version, and make price waterfalls part of the quote record.

Build the test harness before the catalog is large. The checks above cost little when the model is small and are painful to retrofit later.

A short checklist to close the loop:

Option vocabulary defined, owned and versioned
Technical and commercial rules separated
Rules stored in version control with reviewed changes
Lint, dead-option and BOM-coverage checks running in CI
Regression corpus of real orders re-run on every rule change
Quotes record rule-set version and price waterfall
Explicit escape path for engineer-to-order specials
Metric tracked: share of booked orders needing engineering clarification

Frequently Asked Questions

What is a 150% BOM and how is it different from a 100% BOM?

A 150 percent BOM is a single superset structure holding every part that could appear in any valid configuration of a product family, each line carrying a selection condition. A 100 percent BOM is the exact bill for one configured unit, produced by evaluating those conditions against the customer’s option codes and the order date. The 150 percent figure is a convention, not a literal ratio. Engineering maintains one structure, and each order resolves its own buildable view.

What is the difference between rule-based and constraint-based configuration?

Rule-based configuration encodes knowledge as directional if-then rules fired in some order, which is simple but order-dependent and hard to check for contradictions at scale. Constraint-based configuration declares what must hold, and a solver derives consequences in every direction, so one implication also yields its contrapositive. Constraint models support validation, propagation, completion and explanation from the same specification, which is why most serious configurators use them underneath, even when the authoring surface looks like rules.

Should configuration rules live in PLM, CPQ or ERP?

Technical rules, which express design intent and safety, should be owned by product engineering and authored once in a controlled source, typically near PLM. They are then published to CPQ for interactive use and to ERP for order explosion, with automated equivalence tests. Commercial rules, such as bundles and regional restrictions, can be owned by sales operations. The key is single-source authoring with versioning, not the specific system that stores the master copy.

How do you test a product configurator rule set?

Combine four layers: structural lint for unknown references and unreachable lines, solver-based satisfiability and dead-option analysis, BOM coverage checks that resolve every valid or sampled configuration and test invariants such as no orphan options, and regression testing against a golden corpus of real orders. Run them in continuous integration so that no rule change reaches production unreviewed. Pairwise sampling helps when the space is too large to enumerate.

How does CPQ pricing work beyond a price list?

Pricing is evaluated in layers: base and option list prices, cost-plus roll-up where needed, customer and contract pricing, discounts under approval guardrails, then tax, freight and currency. The order of layers must be explicit and deterministic, with price-list versions pinned on the quote. A stored price waterfall, one line per layer with its source rule, makes quotes explainable and defensible in disputes.

Can a CPQ handle engineer-to-order products?

Partly. A constraint-based configurator handles the standard portion and validates what it can, but ETO has an open design space. The practical architecture provides a controlled escape for specials, parametric items with bounded ranges, restricted-effectivity part creation for one-offs, estimate-based pricing separated from firm lines, and order pinning to a structure revision with change-impact analysis. Model-based configuration helps when module counts vary.