Options, variants, and rules that say why

What it is, and what it is not

Option sets with values, rules that constrain how values combine, and BOM lines that belong to particular selections. A selection plus the rules produces one concrete structure through the resolver.

It is not a product family folder. Copying a structure per configuration is the common alternative and it works until the twelfth copy: a change then has to be applied twelve times, and the copies drift because somebody applies it eleven times.

It is also not a configurator for sales. Manufacturing PLM models what is buildable; what is sellable is a commercial question with pricing, lead times and regional availability attached, and those belong in a quoting tool that reads this rather than in the engineering record.

The mechanism: rules that name themselves

Rules constrain combinations — requires, excludes, implies. IP67 requires 240V, because the sealing gland is not rated for the 120-volt inlet. DE implies the EU label, adding one part and removing another.

When a selection is rejected, the rule that rejected it is named, with its reason. Not invalid configuration. That distinction sounds cosmetic and is the difference between a constraint people work with and one they route around, because an unexplained rejection reads as a bug and the response to a bug is a workaround.

Validation happens at selection, not at build. A combination that cannot exist is refused when somebody chooses it, while it costs nothing — rather than resolving to a structure that is quietly wrong and surfacing on the floor.

Rules live as tenant configuration alongside object types and lifecycles, versioned and promoted from a sandbox. Adding a constraint is a change you can diff, cost against real data, and roll back.

The failure it prevents

A product ships in three voltages, two enclosures and four languages. Rather than model it, somebody creates twenty-four product structures by copy.

Eighteen months later a component is superseded. The change is applied to the structures somebody could find — which is twenty-one of the twenty-four, because three were created during a rush and named inconsistently. The three stragglers keep building the old component until the supplier stops shipping it.

The alternative failure is subtler and worse. A team models variants properly but the rules are advisory, so a salesperson configures a 120-volt IP67 unit because nothing stopped them. It reaches production as a works order, and the first anybody knows is that the gland does not fit.

How it meets the rest of the product

Variant selection is one of four conditions the resolution engine takes, alongside effectivity, revision policy and plant scope, and all four are applied in a single pass. That matters because applying them as sequential filters produces different answers depending on order — a line effective from October and belonging to the 240-volt option is not the same question asked twice.

Because compare resolves both sides first, comparing two variants shows what genuinely differs between them rather than reporting every option-membership decision as a difference. Comparing the same variant across two revisions works the same way.

Rollups sum the lines that survive selection, so a cost or mass figure is per configuration rather than an average nobody builds. Where-used answers which configurations contain a part, which is the question a supplier change actually asks.

Baselines capture a released configuration — a specific selection, resolved, at a moment — which is what a customer qualification or a first article is. Comparing today against that baseline is the same operation with the baseline as one side.

How it meets your ERP

Manufacturing PLM resolves before publishing. Your ERP receives a concrete structure for the configuration being built, not a rule set it would have to evaluate — because a BOM in an ERP holds a structure and has no way to reason about option membership.

This is deliberate even where the target could in principle model variants. SAP's variant configuration is capable, and mapping Manufacturing PLM's rules onto characteristics and dependencies is lossy in both directions with a silent failure mode: a wrong configuration that nobody notices until it is built. Resolving first and sending a concrete answer is simpler and verifiable.

Where you build to order across many configurations, the practical pattern is publishing the configurations you actually run rather than the combinatorial space. Twelve real variants is a manageable set of ERP structures; two thousand theoretical ones is not, and nobody builds most of them.

Where the boundary is

No pricing, no lead times, no regional availability and no quoting. What is buildable and what is sellable are different questions, and a system that conflated them would make engineering responsible for commercial policy.

There is also no automatic rule discovery. Manufacturing PLM will not infer that IP67 requires 240 volts by observing which combinations have been built; that is a real engineering constraint and somebody has to state it. A system that guessed constraints from history would encode past accidents as rules.