Authority over the product rules sits with your company — with engineering, sales, purchasing and everyone else who owns a part of the product data and the rules behind it. That part is rarely disputed. What is disputed, usually too late, is how a change actually gets made.
Ownership is not the problem. The path is.
Which steps does a change pass through? Who signs it off? And does the tool enforce that sequence — or does it trust everyone to follow a process that exists on paper?
A rule that can be edited straight into production is not governed, however the process reads on paper.
Why full control is the wrong goal
Full control over the rules sounds like the opposite of supplier dependency, and it is often sold that way. But configurators carry more interdependence than they show from the outside. A single option can affect a bill of materials, a price, a part number, a drawing and a lead time at once.
Someone editing with good intentions and an incomplete picture can do a lot of damage quickly — and the damage does not show up as an error message. It shows up in quotations, weeks later, at a customer.
Safe change instead of maximum freedom
What you want is not maximum freedom but safe change: a defined set of things a trained user can edit directly, anything deeper behind review, the effect of a change visible before it is approved — and a way back.
- ChangeInside a defined scope
- Impact previewPrices, BOMs, part numbers affected
- ReviewA second pair of eyes
- ApproveBy the owner of that data
- ReleasePer series, not the whole system
- Way backRollback in minutes
The tool enforces the sequence. Nobody has to remember it.
The step that is missing most often is the second one. Running a changed rule against every existing configuration and reporting the differences takes seconds for a machine and is impossible by hand. Without it, approving a change is an act of faith.
Who changes what — a typical split
Where exactly the line sits depends on your products and your organisation. As a starting point, this is a split we see work in practice:
| Who | Changes directly | Changes after review |
|---|---|---|
| Sales | Price lists and surcharges within approved limits | New discount structures, list price rounds |
| Purchasing | Component costs, suppliers, lead times | Replacing a component across a series |
| Engineering | Texts, documents, option descriptions | Options, dependencies, technical rules, part number logic |
| Product management | Which series are visible, and to whom | New series, discontinued series |
The important part is not the table itself. It is that the table exists, that someone decided it — and that the system knows it, rather than everyone remembering it.
What to ask before you buy
- Who may change which rules — and does the system enforce that, or only the process?
- Can a trained user change prices and texts without a developer, while deeper changes stay behind review?
- Can we see what a change affects before we approve it?
- Is every change versioned, with who changed what and when?
- How fast can we undo a change — for one series, without touching the rest?
These are questions 3 and 4 of our buyer’s checklist for product configurators — together with versioning, rollback per series and impact analysis before approval (questions 5, 6 and 23).