Variant explosion at Alpine Pumps
Alpine Pumps sells six pump families. Each family varies by flow rate (4 options), seal type (3) and voltage (2). Today every combination is its own released product - 2,900 items - with duplicated bills of material, trade agreement lines and product images. Adding a third voltage last quarter meant creating 72 items and 72 new BOMs. Engineering cannot report scrap by seal type, and Finance complains that standard cost is identical for all three seals even though the ceramic seal costs roughly three times the nitrile one. Units are serialized for warranty, stock sits in three warehouses with bin locations, and the costing method is Standard cost. The team wants far fewer items without losing the ability to buy, sell, cost and report at the seal, flow-rate and voltage level.
1. Recommend the product, storage and tracking dimension group design and justify every dimension chosen. What must you warn the team about before touching existing items?
Read the worked answer
Product dimensions
- Configuration = seal type. Choose configuration for the dimension that changes what the item is made of. BOM lines and route operations can be tied to a specific configuration, so the ceramic-seal variant can carry its own component line. No other product dimension has configuration technology behind it.
- Size = flow rate, Style = voltage (or Color if they ever go retail-facing). These are descriptive; they drive reporting and pricing but not the recipe.
- Keep the product dimension group to exactly three active dimensions. Every added dimension multiplies master data work, and dimensions cannot be removed later if transactions exist.
Storage dimension group: Site, Warehouse, Location (plus Inventory status if the DCs will use statuses for holds). Location is mandatory to get bin-level picking later in warehouse management.
Tracking dimension group: Serial number, active for physical inventory. Serial is what gives warranty traceability per unit; batch is not needed unless seals or motors are lot-controlled upstream.
Warnings before the change
- Storage and tracking dimension groups are locked once transactions exist on an item. Any item already transacted must be replaced by a new item, not edited.
- You cannot simply delete the 2,900 legacy items - open stock, open orders and cost records keep them alive. Plan a cutover per family at a period boundary: new product master live, legacy items moved to an end-of-life lifecycle state and blocked for new sales while remaining valid for costing until inventory reaches zero and inventory close has run.
- Trade agreements, price and discount can be defined at the product master level and inherited by variants; check which of the 72 duplicated agreement lines can collapse to one master-level line before rebuilding them per variant.
2. How can one product master carry three different standard costs, one per seal type? What breaks if it cannot?
Read the worked answer
Standard cost is not stored on the released product - it is stored as item price records in a costing version, and those records carry the item plus dimensions (including configuration) and site.
So the sequence is:
- Create a costing version with type Standard cost and set the activation date.
- Create item price records for the product master at each configuration (and per site if the sites should carry different standards).
- Activate the version so the pending prices become active on the effective date.
- Model the cost build-up with cost groups - one for the ceramic seal component, one for the nitrile - so the cost breakdown report shows why the ceramic variant is three times the material cost of the nitrile variant.
If costs cannot be differentiated: every production receipt posts at a single blended standard, so the ceramic units generate a persistent production variance that nobody can explain, margin by configuration is fiction, and the make-versus-buy decision on the ceramic seal is made on bad data. Revaluation also becomes a manual exercise every time a supplier price changes, because you cannot revalue a single configuration cleanly.
One caution: a variant with no item price record does not inherit a neighbour's price. Enumerate every configuration that will be transacted and check the list against the activated records before go-live.
3. The 2,900 legacy items already have open stock, open purchase orders and customer trade agreements. How do you migrate without breaking costing or pricing?
Read the worked answer
Treat it as a phased cutover per pump family, not a big-bang renumbering.
Per family
- Build the product master with dimensions and BOM lines assigned to configurations, and load the standard cost price records for every configuration.
- Stop new demand on the legacy items (lifecycle state to end-of-life, block for sales) but leave them financially open.
- Let existing purchase orders, production orders and sales orders finish on the legacy items. Transfer any stock you want to keep across to the new variant items - an inventory adjustment or a transfer order at the new item, valued so that no gain or loss is manufactured in the move.
- Run inventory close on the legacy items, confirm zero on-hand and zero open transactions, then archive them.
- Only rebuild trade agreements that genuinely differ per variant. Vendor- and customer-specific pricing that was identical across 24 items collapses to one master-level agreement, which is the real payback of the exercise.
Risks to name out loud: open sales orders reserved against legacy items must ship from legacy stock or be re-pointed manually; any batch/serial history does not follow the item across, so warranty lookups need both items live in reporting for the warranty period; and the forecast/trade agreement copies must be reconciled so a customer is not quoted the old item number in month one.