PIM System Implementation: 7 Steps

Seven stages to go through on the way from idea to implementation. 4.8.2023.
Reading time: 14 min. Implementing a PIM system might seem like an extremely simple task, even if the company has worked without one before.
There are reference catalogs and data flows — what else could you need?
Just do it — all that's left is to choose the "right" system! Indeed, products are a fairly well-explored area of study.
The company works with its product range constantly — surely there can't be any shortage of information here. There are XLS files in Dropbox, and some of the information is stored in 1C and on the website.
All that's left is to bring the data together and put it in one place.
Most likely, if you "just go and implement it," within a couple of months you'll have to start a complete rework of the PIM system, because it will turn out that the product card doesn't account for some nuance specific to the product category, the product lifecycle misses a rarely occurring scenario, and the attribute structure overlooks the requirements of half the departments involved in supporting that very lifecycle.
KT.Team has integrated PIM systems into the IT architecture of more than 25 companies — trading, manufacturing, agricultural, and even service businesses.
Drawing on the experience we've gained, we developed our own internal PIM implementation procedure consisting of seven stages. In this article we'll share this procedure with you and explain which PIM implementation mistakes each of the described stages helps avoid.

PIM systems in brief

How many parameters does your product (or service) have?

According to some studies, a basic product description requires up to 200 parameters, and sometimes more: dimensions, weight with and without packaging, color, size (for clothing, for example), primary and secondary materials, production parameters, seasonality, power rating, features, included components…

The full list is so long that it could safely be turned into a separate article.

Usually all this information is stored across the company in a fragmented way. Some of it sits in the ERP, some in spreadsheets on desktop computers or in the cloud.

Product photos and certificates are in network storage.

Analytics data is in the BI system, seasonality is in the heads of the sales staff… And when you need to pull all the available information together (for example, to start working with a new dealer in a market that's new to you), an entire department spends several days collecting, updating and re-checking the data — this is a real case from one of KT.Team's clients, but we believe many have faced a similar situation.

A PIM system (short for product information management system) is a master system for storing information about goods and services. In a PIM system you can store text information, calculated parameters, media files, analytics data, attributes, regional and seasonal markers, prices, and so on.

If you need to export all data to a new marketplace or hand it over to a dealer, the process takes only a few minutes instead of several days.

Another advantage of a PIM system is that it acts as a single source of product information.

No more frustrating situations where one dealer describes a vacuum cleaner body color as "dark gray," another as "gray," and a third as "black," leaving the customer unsure whom to trust and projecting their frustration onto the vacuum cleaner manufacturer. The PIM system distributes information to all sales channels: the dealer portal, marketplaces, retail outlets, online stores, printed catalogs, and more.

You can define a single description structure and combination of fields for all channels or, conversely, configure a specific export model for each of them.

The PIM system can be used simultaneously by all departments of the company whose work is in some way tied to supporting the product lifecycle: production, procurement, sales, marketing, logistics, and so on.

Configurable roles and access levels (available in most PIM systems) let each department access only the portion of information that is relevant to it or falls within its area of responsibility. Finally, PIM systems provide a mechanism for controlling the quality and completeness of the published information.

If it's important to you that products appear in sales channels with at least three photos, the PIM system will not let product cards without photos go to publication.

Or another example: if a cabinet cannot weigh less than 15 kg, the PIM system will not validate cabinet cards with a weight of 3 kg.

But there's a catch: a PIM system on its own won't be a "silver bullet" for every problem and task related to working with product data — to achieve that, it needs to be implemented correctly.

Seven steps toward a proper PIM system implementation

Below are seven stages that let you prepare and carry out a PIM implementation so the system works from its first version, rather than needing a full rebuild a few months later.

1. Define the problem the PIM implementation is meant to solve

As a rule, the main data problem is discovered long before a PIM implementation task ever appears.
Messy data, difficulty gathering information, fragmentation — that's how business clients most often frame their problems at the start.
With no prior experience working with PIM systems, you might settle for these initial inputs.
But such a strategy is dangerous — first and foremost for the customer.
Often only the department interested in the PIM implementation reaches out to the integrator — usually the e-commerce unit, the commercial department, or the sales department of a manufacturing enterprise.
However, product data is usually used by several departments at once. For example, at our client Askona, a trading and manufacturing company, those departments include procurement, production, warehousing, logistics, sales, e-commerce, marketing, and so on.
A product's life cycle cannot be separated from the core business process.
If a PIM implementation ignores the needs of all the departments that use, create or modify product information, the company will ultimately end up with a non-working tool — the service model will be broken.
Here an attentive reader will object: you could launch an MVP for one department and refine it later! For example, move only the website information into the PIM now, and add fields for marketplaces, logistics and production in later iterations.
In practice, this strategy leads to staff going back to their familiar spreadsheets within a couple of months, while million-ruble budgets are wasted.
Or else each department sets up its own PIM system "with all the bells and whistles and its own information models," and instead of a single "golden record" you again get several that aren't synchronized — or even contradict one another.
Are you ready to spend millions for nothing to fundamentally change (or even get worse, adding more mess to the data)?
So the first step of implementation is collecting the complaints and requests of every department that interacts with product information in any way.
Clarifying the details will take the implementation team some time.
You'll need to map out the enterprise's services, work out how the landscape should be reorganized, and agree the proposed changes with all interested departments.
You can entrust this work to your own team or go through the initial stage together with an integrator. In both cases it's important that the team includes specialists experienced in similar implementations — they know which questions to ask so that the PIM system implementation benefits your business.

2. Design and agree on the information models

So, in the first stage the implementation team recorded the existing problems and the expectations for the PIM system voiced by the company's various departments.

The next step is to build a product card information model (or several information models) that accounts for all the interests identified.

At this stage of implementation it's important to drop the belief that "if we've always done it this way, we should carry our old practices over to PIM too."

You'll have to "reassemble" the work with product information by asking the right questions about what matters and is needed for each department.

Are there discrepancies between departments in how terms are understood?

Do all the departments involved understand the concepts in the same way?

If not — what's the difference and what matters to account for? For example, one company we worked with stored wholesale and retail SKUs in the same place.

At the same time, the procurement department and the retail department meant different things by "SKU." For procurement, identical SKUs could denote different colors of the same product, but the product itself had to be made at a single plant.

For retail, on the contrary, it didn't matter which factory produced the item, but the color was critically important.

On top of that, there were nuances around wholesale and retail packaging.

The company mentioned nothing of the sort before the implementation began, because this terminology gap was long-standing and taken for granted.

The conflicts surfaced only on a careful review of product data — that is, when we ran into data conflicts directly. In the end we had to rebuild the information models to account for the stance of both interested departments. Imagine if the PIM system had been implemented solely on retail's requests, even though procurement also planned to use it. Where would procurement have ended up?

What are the rules for relationships and constraints?

This issue is especially important for manufacturing companies, though trading businesses sometimes face it too.

Such relationships are often not captured explicitly, because "everyone who needs to know already knows." For example, if a cabinet door is longer than 170 cm, it is mounted on three hinges.

Or if the sofa frame is made of MDF, the color palette is limited to five colors, and if it's made of wood — to seven.

There are also less obvious rules: instead of a list of attributes, a range with a value-selection rule. Say, the length and width of the item can fall between 80 and 260 cm in 1 cm steps, but if the width is under 120 cm the length cannot exceed 160 cm.

Such rules and interdependencies can be ignored when configuring information models.

But in that case the PIM implementation turns into "shuffling spreadsheets" from Excel into PIM, which systemically solves nothing: staff will keep filling out endless cards, just now in a new system.

Which product data needs to be formalized in the product card?

Creating a digital copy of a product means formalizing a huge volume of information.

Let's look at an ordinary, simple product — a pillow.

This is how it looks on a marketplace. Seems simple, right? And this is what the information model of a pillow looks like in a PIM system. And that's only half the attributes! The information model captures every attribute that matters for sales, marketing, production, logistics, and procurement.

A pillow is not just "50 × 70 cm, filled with sheep's wool."

A product card must answer hundreds of questions: -

What are the packaging specs: dimensions, material? -

What are the production specifics: stitching, cover fabric, zipper, number of cover and filler layers? -

Who is this pillow intended for?

For those who like to sleep on something soft or something firm?

Is it suitable for people with osteochondrosis? -

Is the pillow breathable? (Yes, that's an attribute too!) - Which channels is the pillow sold through: own stores, marketplaces? Or maybe this model is sold exclusively in the B2B segment — to hotels?

This information was always collected and stored, but before the PIM implementation it was kept in a decentralized way across several systems, Excel files, and handbooks.

To capture and gather all the important data into a single "golden record," you need to study every product category.

How are the non-core processes actually structured, and which attributes are tied to them?

The PIM system's client (the main department that initiated the implementation) doesn't always know how product information is handled in other departments, and so cannot provide reliable details about every nuance of that work. For example, one large company that received products from another enterprise within its holding claimed that all attributes were generated inside the holding and subject to management.

When we started analyzing the roles and information models, we suspected this was simply impossible: the data was extremely fragmented, and maintaining it would require far too much effort. After numerous negotiations, we found out that two-thirds of the attributes are loaded directly from supplier factories and are not processed any further within the holding — meaning they need neither to be entered nor modified, only imported.

Had we implemented the PIM relying only on the client's first comment, the product card's information model would have been more complex both in architecture and in operational properties.

There were also opposite cases, where the information models of some categories turned out to be suspiciously simple.

After a detailed review and clarification, it turned out there were in fact many "problem areas," but only one department had handled them through its own internal processes, while the other departments saw only the "simple model."

If such hidden processes are left unaddressed, the most overloaded departments won't get the expected effect from the PIM system.

Frustration with the new product will build up. Over time a demand will emerge to "start over and do it right" — to re-implement the PIM, but this time so it works well for everyone.

It's important to understand that your team most likely doesn't know everything about the processes, and building a proper product information model will require asking hundreds more questions.

We'll curate materials for your task

clients@kt.team Telegram @kt_team_blog

We'll reply within 30 minutes and send relevant cases, diagrams, or analyses tailored to your context.

3. Identify what does not need elaboration

Based on the previous point, you can imagine the effort it takes to work out the information models, with all the negotiations, correspondence, clarifications and questions.

At least 40 hours. And what if there are 20 or 50 categories?..

Working out the information models alone will take a business analyst a year of working time. True, but…

At the start you need to determine whether all categories are truly unique and require separate work — some product categories may have non-unique information models. For example, our client, a manufacturing company, had 53 product categories in its catalog.

But from the standpoint of how the information model works, only 30 of them are unique — as a result, the total work time was cut by 920 hours (23 × 40)! Another of our clients, a wholesale supplier of electrical equipment, has eight categories in its active catalog: "Cables and Wires," "Electrical Equipment," "Lighting Equipment," "Cable Support Systems," "Installation Materials," "Switchgear Equipment," "Structured Cabling and Telecom," and "Tools and Protective Gear."

You'd think eight product information models would need to be developed…

But studying the product information structure showed that, in fact, just two universal models suffice: one for cables and one for the rest of the electrical products.

This made it possible to cut development time during the PIM implementation and to reduce post-implementation labor costs by about 20%.

4. Define roles and access levels for product cards

In the previous sections we repeatedly noted that working with product information is often not confined to a single department but spread across several. Each department contributes its own share of information, and within departments there are also different roles. For example, Timothy (any resemblance is coincidental) receives an Excel file from the procurement department and, in a way known only to him, transfers the information from it into, say, the ERP, while suppliers enter part of the information themselves.

The implicit division into roles that has taken shape needs to be digitized by configuring access levels for the different roles: what category managers, curators, suppliers, and marketers can change, who will approve changes, which triggers will fire… And here we move on to the next point — digitizing the business processes for working with product information.

5. Describe the lifecycle of product information as a business process

It seems the business process is relatively clear — the company has dealt with the product for years and knows what statuses it can have.

But often the real business process isn't documented, its fragments "live in people's heads" across several departments, and what passes for the business process is a heavily truncated flow with three or four statuses.

However strong the temptation, settling on such a scheme won't work.

After overlaying the role model, conditions, attributes, and unique cases, the diagram usually takes the following shape.

Here the reader may object that business processes built in such detail only increase the overall PIM implementation time, and therefore aren't necessary to build.

In effect, this is nothing more than digitizing the existing state of affairs. Yes and no.

If you don't have clearly built processes with well-defined statuses, responsible employees, inputs and outputs, you may struggle to understand whether everything is going fine, whether something needs to change and exactly how to do it.

Well-structured processes make changes faster and simpler, because they are easy to read, fully mirror the domain, and are built atomically enough to be transformed without any difficulty. In the context of a PIM implementation, such a deep dive into processes lets you avoid having to re-implement the system — it will be close to the company's real needs from its very first version.

6. Decide how PIM will be integrated with other systems

Another trap you can fall into in the early stages is poorly thought-out integrations. "We already have an API, there'll be no export quirks, no duplicates, all the data flows are clear." Good, if that's true.
But in practice, as you know, something often works differently than expected, forcing you to seek workarounds: building a mapping between the information source (for example, a supplier portal) and the PIM system, linking attributes for correct loading, configuring exports so they don't duplicate, and so on.
For our part, we recommend building integrations not in a point-to-point paradigm but through an ESB layer: this approach removes functions that don't belong on end systems, including PIM, reduces the amount of code, and makes integrations more manageable.
You can read more about ESB systems in this article.
Understanding the existing data flows is usually not hard; it's harder to uncover the accumulated problems in point-to-point integrations.
But either way, this work also takes time.

Elaborate, configure, agree, rebuild… fully rework?

"Wait," you'll say, "what does 'rework' mean? So even after going through all six previous stages, you'll still have to make changes to the PIM system?"
From our own experience, we can say: yes, you will. In some places only minor changes, in others you'll need to rethink a large block of information.
Conducting pre-project analysis lets you get close to the optimal PIM system at the time of implementation and avoid building a project that is doomed to fail.
But the IT landscape can't (and shouldn't) stand frozen for ages.
Your company evolves like a living organism: business processes, interaction models, and the business as a whole all change. And since the IT landscape and each IT service must always be a reflection of the business, they will inevitably have to change as well. And here is an important consideration: don't count on being able to "stockpile minor fixes and come back to the integrator in a year."
As soon as the system stops supporting current processes through its own functions, your employees will get used to solving their tasks around the PIM again — with Excel, 1C, Google Sheets… And by the time you turn to the integrator again, the PIM will have become an unused burden.
So a tactic of accumulating and postponing will only lead to the need to re-implement the PIM system instead of the minor refinements you'd planned.
Between a system built "one-and-done" and incapable of change, and a system that is constantly modified, flexibly adapting to the business's current needs, lies a vast gulf in business value. And that gulf has a name: lean thinking and continuous improvement (plus Agile and digital transformation).
If you don't think about it, there's no point implementing a PIM at all — Excel would be better.

Contacts

Let's Discuss Your Project

Leave your current contact details and describe your task. We will come back with clarifying questions and a proposal for the next step.

Why you can't just deploy a PIM system and be done with it