How product information management works
Most catalog projects that go badly go wrong before anyone opens a screen, at the point where nobody has said what product information management is for. This page says it. Read it before you touch the data model.
The problem a PIM solves
Ask a mid-sized B2B company where the description of article 4711-A lives and
you will usually get four answers at once:
- The ERP has the SKU, the price, the weight, the tax class, and a 40-character description written for an invoice line.
- The supplier's spreadsheet has the technical attributes (thread size, material, pressure rating) in whatever columns that supplier happens to use.
- A shared drive has the images and the PDF datasheet, named
4711_neu_final_2.jpg. - Somebody's head has the part where you explain which of the three similar articles the customer wants.
None of these is wrong. Each is the right tool for its job. The problem is that a shop, a printed catalog, a marketplace listing and a customer's procurement system each need a different subset of all four, in a different format, in the right language, and there is no single place where the whole picture exists.
A PIM is that single place. The ERP and the shared drive keep their jobs. The PIM is the layer where product information from every source is brought together, structured, enriched, translated, and then published to every channel that needs it.
What a PIM does
Four things, in this order:
- Collect. Pull data in from ERP, suppliers, spreadsheets and existing systems, without demanding they all agree on a format first.
- Structure. Force it into one defined model. A pressure rating is always a number in bar, never sometimes "10 bar", sometimes "10bar" and sometimes "ca. 10".
- Enrich. Add what no upstream system has: the good description, the application note, the comparison that helps a buyer choose, the translations.
- Publish. Hand each channel exactly the subset it needs, in its format.
The value sits almost entirely in steps 2 and 3. Step 1 is plumbing and step 4 is a feed. Structure and enrichment turn a list of part numbers into something a buyer can shop.
Why this matters more in B2B than in B2C
A B2C shop selling 400 SKUs of clothing can survive with product data that is mostly a photo and a paragraph. B2B catalogs break that model in four ways.
Volume. Technical wholesalers routinely run 50,000 to several million articles. Anything that requires per-product manual work does not scale, so the structure has to do the work instead.
Attributes are the product. A buyer choosing a fitting is filtering by thread type, material, pressure rating and norm. Those attributes are how the product is found and chosen. If they live in a free-text description, your search and your filters cannot work, however good the search engine is.
The data leaves your shop. Through punchout, your catalog is rendered inside your customer's procurement system. Through BMEcat or Excel exports it lands in their ERP. Those systems are far less forgiving than a web page: a missing unit of measure means a rejected order line, not a crooked layout.
Different customers see different catalogs. Assortments, prices and even descriptions can be customer-specific. That only works if the data is structured enough to be filtered and overridden per audience.
Signs you need to take this seriously
These are the symptoms that point at the data model rather than at the shop:
- Your search returns the wrong things and tuning the search engine has not helped. The attributes are not structured.
- You cannot offer filters that buyers ask for, like "thread size".
- The same product has three descriptions in three channels and nobody knows which is current.
- Adding a supplier means a week of manual data work.
- Translating the catalog has been "planned" for two years.
How this works in the Revenue Cloud
The Products app is the PIM. It carries the full model: attributes, families, variants, reference entities, assets and measurement families, with per-channel and per-language values and a completeness measurement.
The four steps above map onto it like this:
| Step | Where it happens | What carries it |
|---|---|---|
| Collect | Import; BMEcat, ETIM and eClass feeds are the intended import formats | SUPPLIER_PID becomes the SKU, features become attribute values, media becomes assets |
| Structure | PIM › Data model | Attributes with a type, families that say which are required, measurement families for units |
| Enrich | PIM › Products | One value per language, per channel, or per pair, on the same attribute |
| Publish | Channels and exports | Values are resolved per channel and locale before they leave |
You do not need to buy and integrate a separate PIM to run a serious B2B catalog here. If you already run one (Akeneo, Contentserv, inRiver), the model maps closely enough that syncing into it is a field-mapping job rather than a re-modelling job. See Deciding your system of record.
Next
- The catalog data model — the pieces, and how they connect.
- Plan your data model — the decisions to make before you create anything.