Most manufacturers introduce a PIM sooner or later. The interesting question is not whether — it is what has to change when it arrives. If your configurator holds the product master data, the answer is: almost everything. If the data sits in a neutral layer, the answer is: nothing the configurator would notice.
The island problem
Product data maintained inside a configurator becomes an island. It starts harmlessly: the configurator needs series, options, prices and texts, so they are entered there. Then the website needs the same series. The datasheet needs the same curves. The second product range gets its own configurator, with its own copy.
A year later there are two or three versions of the truth, each slightly different, and nobody can say with confidence which one the last quotation was based on.
A neutral data layer
The alternative is simple to describe: keep the product data outside the configurator, in a layer of its own, and serve it to every channel through an API. The configurator reads from it. So do the website, the datasheet generator and whatever comes next.
- One declared unit per quantity
- Versioned
- Exportable at any time
When a PIM arrives, it takes over the source side. The configurator never notices.
That layer is what makes a PIM introduction painless. The PIM takes over the master data at the source; the API that every channel reads from stays the same. No rebuild, no migration project for the configurator, no second version of the truth.
What a PIM will not hold
A PIM is built for commercial product information: articles, attributes, texts, images, prices. It is not built for performance curves, sizing tables, test-bench data or the other technical datasets an engineering configurator actually computes with. Neither are most configurators.
Technical data needs its own home, its own owner and its own update path — decided before you need it, not when the first curve changes and nobody knows where to put it.
One unit per quantity — and conversions in one place
Mixed units look harmless at the moment they are entered: flow in m³/h here and l/s there, pressure in bar in one table and in metres of head in another, sizes in more than one notation. They cost you a wrong configuration later.
Store one canonical unit per quantity, with the unit declared rather than implied by a column name or a convention someone remembers. Every conversion then lives in code or behind the API — one implementation, tested once — instead of in a rule, a spreadsheet formula and a screen field, each with slightly different rounding.
Your data, exportable at any time
Rules, configurations, prices and version history should be exportable on demand, in an open format, without a support request. If getting your own data out requires asking the supplier, it is not really yours — and switching systems later will cost far more than it should.
What to ask before you buy
- Where does the product data live — inside the configurator, or in a layer of its own?
- If we introduce a PIM next year, what exactly has to change?
- Where do performance curves and technical datasets live, and who maintains them?
- Is every quantity stored in one declared unit? Where do conversions happen?
- Can we export everything ourselves, today, in an open format?
If the answers are vague, the data will end up on an island — and you will pay for the bridge later.
These are questions 8 to 12 of our buyer’s checklist for product configurators. How the data layer itself is built and distributed is covered in API-First Product Data Distribution.