Product information management brings your product data together

You are about to publish a new item, but the weight differs between the webshop, the price list and the datasheet in an email thread. Marketing is waiting for an answer. Sales is using the old file and finance wants to know which version applies.

Product information management, PIM, starts by sorting out conflicts like these. The system helps you structure product data and distribute it to the right channel. The work also requires decisions about who may change a value and which source applies.

PIM brings product data together in one place for every channel

Say your product manager checks the conflicting weight. The webshop shows net weight, the price list contains shipping weight and the datasheet refers to an earlier variant. Every value has an explanation. Nobody has documented which weight each channel should use.

Product data covers everything that describes an item. That includes item number, dimensions, material, images, datasheets, compatibility and areas of use. Prices are also part of the information flow, even though price calculation normally needs to be controlled from the business system.

In PIM, you collect, structure and maintain product information. Approved data is then sent to websites, customer portals and reseller channels.

Think of a recipe book in a kitchen. The base recipe is documented once and used when the chefs prepare different dishes. Changes need to be approved and reach everyone who uses the recipe. Product information needs the same discipline when several departments publish the same item.

A content tool mainly works with the website's presentation. PIM works at item level, where attributes, documents and product relationships need to follow set rules. The boundaries of responsibility should be visible as early as when you choose a system.

A CMS publishes pages, copy and images as a finished presentation. PIM handles attributes, relationships, documents and data quality per item and sends them to several channels. The business system holds item numbers, core data, pricing logic and transactions.

Without clear boundaries, people start copying data between systems. A fix in the webshop then leaves the price list unchanged. The next import may also overwrite the fix.

So start by looking into the incorrect value. If the right value exists somewhere, you need to set up its route to publishing. If the value is missing at the responsible source, someone first has to produce it.

The same product data has to reach the web, the portals and EDI

In 2024, 36.7 percent of Swedish companies with at least ten employees sold online, according to Statistics Sweden's figures on e-commerce channels. 31.2 percent of the companies used the web and 11.2 percent used EDI, and the requirements on product data differ between those channels.

The web and EDI place different demands on presentation. On the web, the customer needs to be able to understand and compare the product. EDI is structured electronic data exchange between companies, where the receiving system has to interpret the data according to agreed formats.

The share varies between industries, which matters when you compare with your own business.

For your product model, the consequence is concrete. A reseller may need the pack size, an installer compatibility details and an end customer a clear area of use. Customer-specific terms also have to come from the right source.

When systems are split up, you need to decide who is responsible for each information flow. The discussion of composable commerce is relevant when you assess system boundaries like these.

Map the channels where your product data is already used. Mark which recipients need machine-readable fields and which need a finished presentation.

Attributes, source and owner decide whether the data holds up

A weight field is easy to create. The hard part is deciding what the weight refers to, who vouches for the value and when it may change. That is where you decide whether the product model can be maintained.

Record data type, unit of measure, whether it is mandatory, source and responsible owner for every attribute. Also document the latest change and how the value should be checked. A technical check can spot text in a numeric field, but an expert has to judge whether the value is reasonable.

The owner must be able to decide when values conflict. The supplier can provide the material, the product manager review it and marketing work on the description.

The product manager approves technical dimensions and units of measure, the marketing manager approves descriptions per language and channel, the business system owner decides where the price is calculated and the document owner approves the version and validity of product documents.

Relationships need the same care. A spare part can fit several models and a datasheet can apply to several variants. So link each document to the right products and document version. Otherwise a correct file can be shown for the wrong variant.

Digital product passports make source tracking especially important. The Swedish Environmental Protection Agency describes the product passport as a digital container for product-specific information and a digital identity meant to support traceability through the value chain. According to that description, it covers the product types that receive information requirements through product-specific delegated acts under the Ecodesign Regulation, ESPR. Not all products are covered automatically from one shared date.

Data on things like repairability, recycled content, environmental footprint and performance class needs to be verifiable when it is part of applicable requirements. Version control makes it possible to see which record supported a published value.

The line between e-commerce and the business system therefore needs to be set per piece of data. Choose a product category and try to name the owner behind each value. Empty ownership fields show where you need to make decisions.

How product data moves from the business system to publishing

Start with what comes in from the business system. Item numbers, core data and pricing logic are transferred according to set rules. Keep the origin, so you can tell whether an error arose in the source or during the transfer.

Next, the people responsible enrich the product in PIM. They add copy, technical attributes, images and documents. Lock fields controlled by the business system against manual editing, unless you have an explicit exception.

Validation then checks the data before publishing. Missing units, incomplete classification and conflicting values should produce clear error messages. An error needs to show the item, field, cause and responsible recipient.

After the check, an authorised person approves the product and saves the publishable version. Then you can look back later at what content was sent. Changes that need a new review should return the product to the right workflow state.

Then the presentation is shaped for each channel. The website may need a short title and the portal a technical name. Item numbers, dimensions and other shared facts must keep their meaning through the transformation.

Finally, the information is published and the recipient's response is logged. A rejected product needs to reach someone who can fix the error. A technically successful transfer is not confirmation that the recipient has accepted the content. Follow one chosen item all the way to the recipient before you approve the flow.

Your integrations also need to handle retries without creating duplicate or conflicting updates. Decide how a corrected product is resent and how resolved errors are marked.

Check in particular where validation happens and who may stop a publication. If the answer takes several email threads, the workflow is too unclear.

One product area at a time beats a big overhaul

A single product family can hold two different documentation requirements. A standard product may need only a datasheet, while a pressurised item in the same family also needs declarations and certificates. If the whole catalogue is reworked at once, people have to resolve differences like that in every family in parallel. A limited family lets you test the model before the rest of the range is connected.

According to the European Commission's timeline for digital product passports, the product passport registry should be up and running on 19 July 2026, and certain batteries must have a product passport from 18 February 2027. Iron and steel, energy-related products, textiles, tyres, aluminium, furniture, mattresses and ICT products have planned years between 2026 and 2029. The Commission also states a transition period of at least 18 months after a product-specific delegated act is adopted. Planned years should therefore be kept apart from fixed dates.

Map which of your categories may be affected and follow the product-specific acts. A year in a work plan supports preparation, but it does not on its own decide which fields your item needs.

Start with the category that has the earliest relevant deadline. If your range includes both textiles and batteries, the batteries should go first, because 18 February 2027 is a fixed date while textiles still only have a planned year. Define the attributes in that family, identify the source material and test publishing with real products. Regulatory data can be added to the same attribute model once the details of the delegated act are known.

That takes a named owner, a list of the data sources and working time to correct older values. Keeping it limited makes the work manageable, but someone on your side still has to approve the data before it goes out.

When PIM is not the right first step

A limited range sold through one channel can work well with a structured spreadsheet. The condition is that someone owns the file, checks changes and follows a clear publishing routine. A new system then has to be justified by a real work problem.

Incomplete core data also needs to be dealt with before implementation. If item identities, units and variant links are unclear, the import will need recurring exceptions. People then risk spending the PIM work investigating the same root errors.

You need to appoint a product owner with a mandate across departments. The role must be able to decide on mandatory fields and which source applies when values conflict. The product owner also needs access to the people who can review technical facts. Make the system decision after deciding who may approve product data.

Ongoing management continues after the catalogue is published. New variants can require changed relationships and new markets can need other documents. The budget therefore needs to cover both technical responsibility and your own ongoing work with the content.

Judge the benefit by following concrete tasks. Look at where staff copy data, which fixes keep coming back and which items get stuck before publishing. That gives a better basis for a decision than counting empty fields alone.

If the core data has no owner, it is better to clean it up in the business system first. Introduce PIM once the division of responsibility works and you can describe what the system should take off your hands. That also makes the delivery easier to scope.

Two questions to ask your PIM supplier

Raise the first question with a concrete item as an example. How is ownership of attributes split between the business system and PIM, and which source applies when values conflict? Ask the supplier to show the conflict in an example import flow.

A strong answer states the source, responsible role and rule for each field involved. It also describes how an approved exception is documented. An evasive answer revolves around editing options and leaves the actual decision to whoever is in front of the screen.

The second question is about what happens after the transfer. What happens to a product the channel rejects, who receives the error and what work is needed to add another channel? This lets you judge both the error handling and the promises about reuse. Ask for a concrete error flow with recipient, fix, retry and confirmation.

A well-worked answer shows where the error appears and how it reaches the right person. The supplier should also be able to separate reusable product data from new channel rules. Another channel may need development, for example when the recipient uses a different format or has its own approval requirements.

Answers that only list functions leave the cost-driving tasks undescribed. You can take these questions to your next supplier meeting without a technical background. You judge who does the work and how you can check it was done right.

Start by mapping the product data you share

A useful decision basis can start with one chosen product family. Gather the data that appears in several channels and state its source, responsible owner and recipients. Mark the values where any of that is missing.

Also add what happens when a value changes. A new dimension can affect filtering, drawings and compatibility descriptions. The material shows which dependencies you need to handle before a change may be published.

For products that may be affected by new information requirements, the walkthrough of the digital product passport helps you link documentation questions to the product's identity. The same inventory works whoever you choose as your supplier.

We deliver PIM where copy, attributes, images and documents are managed in a structured system. Information is enriched once and distributed to several channels. The PIM integration handles the enriched content, while the business system integration handles item numbers, core data, pricing logic and transaction-related data.

Glanser takes long-term product ownership of the solution. On the PIM and product information page, you can see how we structure, enrich and publish product data, so you can compare our approach with your mapping of the first product family.