What your ERP doesn't know about your products

Ask ten manufacturers or wholesalers where their product information lives. Nine will answer "in the ERP". That is true, and still almost every online project runs aground on exactly that point.

The misunderstanding sits in the words product information. What an ERP holds is not what a customer needs in order to order. These are two different sets of data with a small overlap, and that overlap is why the misunderstanding survives.

What an ERP was built for

An ERP is an administrative system. It tracks what an item costs, what it sells for, how many are in the warehouse, which supplier it comes from and which account the sale is booked to. It does that well, and it is exactly what finance, the warehouse and purchasing need.

An item's description is a side matter in that system. Often it is a text field of forty or sixty characters, filled in once by someone who mainly needed it to be recognisable on a packing slip. That is how descriptions like BOLT SHCS M8X40 SS A2 DIN912 come about. For the warehouse that is enough. For your inside sales team too, because they know what it means.

For a customer looking at your site, it is unreadable.

What a customer needs in order to decide

A business buyer weighing two items needs information that does not fit in that text field. A photo, because people do not buy what they cannot see. Dimensions and material. The standard it meets and the certificate that proves it. The technical drawing. What the product is for and what it is expressly not for. Which other items belong with it. What the alternative is when it is out of stock.

That information does exist in your company. It just does not sit in the ERP.

It sits in a folder on the server full of photos, named after supplier references. In the PDFs your suppliers send along. In a catalogue a printer laid out three years ago. In quotes where someone once wrote out neatly what the difference is between two ranges. And a good part of it sits in the head of a colleague who knows the catalogue by heart.

That last one is not a joke. In many companies one person is the de facto product information system. As long as that person is around, it works.

Why it always starts with a spreadsheet

The first time you need that data for something other than a quote, an export file appears. Someone pulls the item list out of the ERP, adds columns for description, material and weight, and starts filling it in.

That works. For two hundred items, once.

Then comes the problem almost everyone recognises. Prices change in the ERP, so the file falls behind. A second file appears for the new range. Marketing produces a third version with better copy. Someone sends a copy to a customer who wants their own assortment list. Six months later there are four versions of the truth and nobody knows which one is right.

The awkward part is that this is not carelessness. It happens because a spreadsheet has no owner, no history and no structure. Anyone can change anything, nothing is tracked, and there is no check that says: this item still has no photo.

What a PIM does differently

PIM stands for product information management. It is a system that does one thing: hold all information about your products in one place, in a structure you define yourself.

The comparison that makes it clearest: your ERP knows what a product costs, your PIM knows what it is.

Three things separate it from a spreadsheet.

There is a structure per product group. A bolt needs different fields than a pump. In a PIM you define per group which properties exist, which are mandatory and which values are allowed. Material becomes a picklist instead of a free text field, so you never again find "SS", "inox" and "stainless steel" side by side for the same material.

There is visibility on what is missing. A PIM can show you that 2,400 of your 8,000 items have no photo and that 1,100 have no French description. That sounds mundane, but it is the difference between a problem you can plan for and a problem you discover when a customer calls.

There is one source for every channel. The same data feeds your webshop, your customer portal, the data feed to a marketplace, the product sheet your customer sees inside their own procurement system and the PDF catalogue. One change, applied everywhere.

So a PIM does not replace your ERP. It sits next to it and takes over the work the ERP was never meant to do.

Who owns which field

This is the question an implementation succeeds or fails on, and it is wise to answer it before anything is integrated. For every field it has to be clear which system holds the truth and which way the data flows.

A split that works in most companies:

The ERP stays owner of the item number, prices including customer-specific agreements and volume tiers, stock, unit and pack size, supplier data and the VAT code. These are figures a booking or a delivery depends on. You do not change them outside the ERP.

The PIM becomes owner of the commercial name and description, all technical properties, photos and documents, the category structure as the customer sees it, translations, relations between items such as accessories and alternatives, and search terms.

The flow then runs one way per field: item number, price and stock come from the ERP and are never overwritten in the PIM. The rest originates in the PIM and goes out to the channels, not back into the ERP.

What you want to avoid is a field that can be edited in both systems. Within a month you will have an argument about which description is correct, and nobody wins that one.

The item number is the key between the two systems. That seems obvious until it turns out the ERP holds items under two numbers, or that the same bolt was created under three references by three different buyers. Cleaning that up belongs to the preparation, not to the integration.

How to fill in 8,000 items without spending a year on it

Most companies balk at the volume. Rightly so, if you plan to do it all by hand. There are three ways to clear most of it without anyone typing the same thing eight thousand times.

Start with what you already receive. Your suppliers have this information. Many manufacturers deliver product data in a structured format, and technical sectors have standards such as ETIM where the properties per product group are already defined. What you can import, you do not have to type.

Work per group, not per item. Material, standard and warranty period are often identical within a range. A good PIM lets you set a value on a whole selection at once. A handful of actions then covers hundreds of items.

Do the items that matter first. In almost any assortment, eighty percent of revenue sits in a small part of the catalogue. Completing those items pays off more than half-completing all of them. You fill in the tail as demand appears, or as customers search for something and find nothing. That search log is your priority list.

Expect the first group to be the slowest. At that point you are not only entering data, you are deciding which fields you want to maintain at all. You make that decision once.

Two things that build on this later

Multiple languages. The moment you sell across a language or national border, you need every description and every property in several languages. In a spreadsheet that means a column per language and a translator working from a file that is out of date before it comes back. In a PIM, language is a layer over the same structure: the value "stainless steel" is translated once and applies to every item carrying that value.

The Digital Product Passport. Europe is phasing in a mandatory digital passport per product, covering origin, composition and recycling. The first product groups follow from 2027, and which sector comes up when differs. The data it asks for is exactly the kind of property that belongs in a PIM. Those who already have that structure will be filling in fields. Those who do not will be starting a separate project under time pressure.

Where to start today

You do not need a quote to know where you stand. Take your fifty best-selling items and note for each one: is there a photo, is there a description a customer would understand, are the technical properties there, is there a document or drawing, and does it read correctly in French.

The outcome of that exercise predicts fairly accurately how long your online project will take. Not the ERP integration, which is a matter of weeks. Filling in what is missing, that is the work.