Why can't we just implement a PIM system?

It seems that implementing a PIM system is a very simple task, even if the company used to work without it. There are directories, streams — what else do you need? Take it and do it, there's only one left choose the “right” system!

Indeed, products are a more or less well-developed field of research. The company is constantly working with the nomenclature — it is unlikely that there may be a shortage of any information here. Dropbox contains XLS files, and some more information is stored in 1C and on the website. All that's left is to combine the data and put it in one place.

But this is a trap. Most likely, if you just take it and implement it, you will have to start completely redesigning the PIM system in a couple of months, as it turns out that the product card does not take into account any nuance specific to the product category, the product life cycle is a rare scenario, and the attribute structure reflects the requirements of half of the departments involved in ensuring this very life cycle.

KT.team has integrated PIM systems into the IT architecture of more than 25 companies — retail, manufacturing, agricultural and even service companies. Based on our experience, we have developed our own internal regulations for the implementation of PIM systems, which consists of seven stages.

In this article, we will share these regulations with you and tell you what mistakes each of the described steps can avoid in implementing a PIM system.

Briefly about PIM systems

How many parameters does your product (service) have? According to some studies, a basic product description requires up to 200 parameters, and sometimes even more: dimensions, weight with or without packaging, color, size (for example, clothes), basic and additional materials, production parameters, seasonality, power, functions, equipment... The full list is so long that it can be safely put into a separate article.

Usually, all this information is stored separately by the company. Some are in ERP, some are in signs on desktop computers or in the clouds. Product photos and certificates are in networked storages. Data for analytics is in the BI system, seasonality is in the minds of sales staff...

And when you need to put together existing data (for example, to start working with a new dealer in a new market), an entire department spends several days collecting, updating and double-checking data — this is the real case of one of KT.team's clients, but we believe many people have faced a similar situation.

The PIM system (abbreviated from English product information management system) is a master system for storing information about goods and services. The PIM system can store text information, calculated parameters, media files, data for analytics, attributes, regional and seasonal characteristics, prices, etc. If it becomes necessary to upload all data to a new marketplace or transfer it to a dealer, this process takes only a few minutes instead of a few days.

Another advantage of the PIM system is its functioning as a single source of product information. There are no more annoying situations when one dealer describes the color of the vacuum cleaner body as “dark gray”, another as “gray”, a third as “black”, and the buyer does not understand who to believe and transfers the negative to the vacuum cleaner manufacturer.

The PIM system “distributes” information to all sales channels: dealer portals, marketplaces, retail outlets, online stores, printed catalogs, etc. You can set a single description structure and a combination of fields for all channels, or, conversely, set up a specific upload model for each of them.

The PIM system can be used simultaneously by all company departments whose activities are somehow related to ensuring the product life cycle: production, procurement, sales, marketing, logistics, etc. Customizable roles and access levels (provided in most PIM systems) allow each department to access only the part of information that is important to it or is within its area of responsibility.

Finally, PIM systems provide a mechanism for controlling the quality and completeness of published information. If it is important for you to have products with at least three photos on your sales channels, the PIM system will not allow you to publish product cards without photos. Or another example: if the cabinet weight cannot be less than 15 kg, the PIM system does not validate 3 kg cabinet cards.

But there is a caveat: the PIM system itself will not become a “silver bullet” for all the problems and tasks associated with working with product data — for this purpose it must be properly implemented.

Seven steps towards the proper implementation of the PIM system

1. Record the problem that is planned to be solved by implementing PIM

As a rule, the main data problem is discovered long before the task of implementing PIM occurs. Data clutter, difficulties in collecting information, fragmentation — this is how business customers most often formulate their problems at the start.

Without previous experience working with PIM systems, you can also focus on these inputs. But such a strategy is dangerous, primarily for the customer.

Often, an integrator is contacted only by the department that is interested in implementing PIM, which is usually an e-commerce division, a commercial department, and a sales department of a manufacturing enterprise. However, product data is usually used by several departments simultaneously. For example, our client, the trading and manufacturing company Ascona, has procurement, production, warehousing, logistics, sales, e-commerce, marketing, etc. The product life cycle is inseparable from the main business process.

If the implementation of PIM does not take into account the needs of all departments that use, generate or change product information, the company will eventually get a broken tool — the service model will be broken.

An attentive reader will object here: you can launch an MVP for one department and then refine it! For example, now transfer only information from the site to PIM, and add fields for marketplaces, logistics, and production in future iterations.

In theory, yes. In practice, this strategy leads to employees returning to their usual Excel games in a couple of months, and millions in budgets are being merged. Or, each department starts its own PIM system “with preference and information models”, and instead of one “golden record”, several unsynchronized, or even completely contradictory, appear again.

Are you ready to give millions so that nothing fundamentally changes (or even gets worse, adding a mess to the data)?

therefore the first step in implementation is to collect complaints and requests from all departments that interact in any way with product information. It will take some time for the implementation team to clarify the details. It will be necessary to draw up a scheme of the company's services, understand how to reorganize the circuit, and coordinate the proposed changes with all interested departments.

You can entrust this work to your team or go through the initial phase together with an integrator. In both cases, it is important that the team includes specialists with experience in implementing similar implementations — they know what questions to ask in order for the implementation of a PIM system to benefit your business.

2. Design and coordinate information models

‍So, at the first stage, the implementation team recorded the existing problems and expectations from the PIM system, voiced by various departments of the company. The next step is to build an information model of the product card (or several information models) that will take into account all the identified interests.

At this stage of implementation, it is important to abandon the belief that “if we have always done this, then we should transfer our previous experience to PIM”. We'll have to “reassemble” the work with product information, by asking the right questions about what is important and necessary for each department.

• ‍Are there differences in the understanding of terms between departments? Are all concepts understood by interested departments in the same way? If not, what is the difference and what is important to consider?
  ‍For example, one of the companies we worked with kept wholesale and retail items in one place. At the same time, the purchasing department and the retail department understood “article” as different entities.
  Thus, for purchases, the same items could mean different colors of the same product, but the goods themselves had to be produced at the same factory.
  For retail, on the contrary, it did not matter at which plant the goods were manufactured, but color was of fundamental importance. In addition, there were nuances in terms of wholesale and retail packaging.
  The company did not say anything like this before the implementation began, as this discrepancy in terminology was long-standing and self-evident. Conflicts were discovered only when we carefully analyzed product data, that is, when we faced data conflicts directly. In the end, it was necessary to restructure information models taking into account the positions of both interested departments.
  Imagine if the PIM system was implemented only at retail requests, although purchases were also planning to use it. What position would the latter end up in?

• ‍Is there a relationship between attributes? Are there any restrictions on attributes? What are the rules for interconnection and restrictions?
  ‍This issue is particularly important for manufacturing companies, although retailers sometimes also face it. Such relationships are often not taken into account explicitly, because “everyone who needs it knows about them.” For example, if the cabinet door is longer than 170 cm, it is attached to three hinges. Or if the sofa frame is made of MDF, the color range is limited to five colors, and if made of wood, seven.
  There are also less obvious rules: instead of a list of attributes, there is a range with a rule for choosing values. For example, the length and width of the product can range from 80 to 260 cm with an interval of 1 cm, but if the width is less than 120 cm, the length cannot exceed 160 cm.
  Such rules and interdependencies can be ignored when setting up information models. But in this case, implementing a PIM system turns into “transferring tables” from Excel to PIM, which does not solve any problems systemically: employees will continue to fill out endless cards, just now in the new system.
  ‍
• ‍What product data should be formalized in the product card?
  ‍Creating a digital copy of a product involves formalizing a huge amount of information. Let's look at an ordinary simple product — a pillow. This is what it looks like on the marketplace. Does it seem like nothing complicated?
  

‍

And this is what the pillow information model looks like in the PIM system. And that's only half of the specs!

The information model takes into account all the characteristics that are important for sales, marketing, production, logistics, and procurement. The pillow is not just “50 × 70 cm, the filler is sheep wool”. The product card must answer hundreds of questions:
- What are the characteristics of the package: dimensions, material?
- What are the features of production: stitching, cover fabric, lock, number of layers of cover and filler?
- Who is this pillow for? For those who like to sleep on soft or hard sleep? On your back, on your side, or sitting? Is it suitable for people with osteochondrosis?
- Does the pillow let in air? (Yes, there is also such a characteristic!)
- Which channels sell the pillow: in your own stores, on marketplaces? Or maybe this model is sold exclusively in the B2B segment — hotels?
This information has always been collected and stored, but before the implementation of the PIM system, it was stored in several systems, Excel files, and manuals. To take into account and collect all important information in one “golden record”, you need to study each product category.
‍

• How do non-core processes actually work and what attributes are associated with them?
  ‍The PIM system customer (the main department that took the initiative to implement it) does not always know how to work with product information in other departments, and therefore cannot provide reliable information about all the nuances of this work.
  For example, one large company that received products from another company in the holding company claimed that all attributes are generated within the holding and are subject to management. When we started analyzing roles and information models, we suspected that this was simply impossible: the data was extremely fragmented, and maintaining it would take too much effort.
  As a result of numerous negotiations, it was possible to find out that two-thirds of the attributes are downloaded directly from the supplier plants and then are not processed within the holding in any way, i.e. they do not need to be entered or changed — you just need to import them.
  If we implemented PIM based only on the customer's first comment, the product card information model would be more complex both in terms of architecture and performance properties.
  There have also been reverse cases, when information models in some categories have turned out to be suspiciously simple. After a detailed analysis and clarification, it turned out that in fact there were many “problem areas”, but only one department dealt with them through its own internal processes, while other departments could see only a “simple model”.

If such hidden processes are ignored, the most overloaded departments will not get the expected effect from the PIM system. Dissatisfaction with the new product will accumulate. And over time, there will be a “sign out and log in normally” request — to reimplement PIM, but now in a way that's convenient for everyone.

It is important to understand that, most likely, your team does not know everything about processes, and in order to build a normal product information model, you will have to ask hundreds more questions.

3. Identify what doesn't need to be worked out

Based on the content of the previous paragraph, we can imagine how much effort it will take to develop information models with all negotiations, correspondence, clarifications and questions. At least 40 hours. What if there are 20 or 50 categories?.. Only developing information models will take a business analyst a year of working time.

Yes, but...

At the start, you need to understand whether all categories are really unique and require separate study — perhaps the information models of some product categories are not unique.

For example, our client, a manufacturing company, has 53 product categories in its catalog. But from the point of view of how the information model works, only 30 of them are unique — as a result, the total development time has been reduced by 920 hours (23 × 40)!

Our other client, 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”, “Switchboard Equipment”, “SCS and Telecom”, “Tools and Protective Equipment”.

It would seem that we need to develop eight product information models... But a study of the structure of product information showed that in fact, only two universal models are sufficient: for cables and for other electrical products. Thus, it was possible to reduce the development time spent on implementing the PIM system, as well as to reduce labor costs after implementation by about 20%.

4. Record roles and levels of access to product cards

In the previous paragraphs, we have repeatedly said that working with product information is often not localized in one department, but is distributed among several. Each department contributes its own part of the information, and there are also different roles within departments. For example, Timofey (all coincidences are random) receives an Excel file from the procurement department and, in a way known only to him, transfers information from there, say, to ERP, and some of the information is supplied by suppliers.

The current implicit division into roles needs to be digitized by adjusting access levels for different roles: what category managers, curators, suppliers, marketers can change, who will coordinate changes, what triggers will work... And then we move on to the next point — digitizing business processes for working with product information.

5. Describe the life cycle of product information in the form of a business process

It seems that everything with the business process is relatively clear: the company has been dealing with a product for several years and knows what statuses it may have.

But often the actual business process is not recorded, and its fragments “live in the heads” in several departments, and a business process means a very truncated scheme with three or four statuses.

No matter how strong the temptation is, you will not be able to dwell on such a scheme. After applying a role model, conditions, attributes, and unique cases, the scheme usually takes the following form.

A noticeable difference, right?

Here, the reader may object that such detailed business processes only increase the overall implementation time of the PIM system, and therefore it is not necessary to build them. In fact, this is nothing more than a digitization of the current state of affairs.

Yes and no. If you don't have well-structured processes with clearly defined statuses, responsible employees, entrances and exits, it may be difficult to understand whether everything is going well, whether something needs to be changed, and how to do it exactly.

Properly designed processes help speed up and simplify changes, because they are easy to read, completely repeat the subject area and are designed to such an extent atomically that they can be transformed without any difficulties.

When implementing PIM, such a deep immersion in processes avoids the need to reimplement the system — it will be close to the company's real needs from its first version.

6. Decide how PIM will be integrated with other systems

Another trap you can fall into at the initial stages of work is ill-conceived integrations. “We already have an API, there will be no nuances of uploading, no duplicates, all flows are clear.”

Well, if so. But in practice, as you know, things often do not work as expected, forcing you to look for workarounds: create a mapping between the information source (for example, the supplier's portal) and the PIM system, linking attributes for correct loading, configure uploads so that they are not duplicated, etc.

For our part, we recommend building integrations not in the “point-to-point” paradigm, but through the ESB layer: this approach removes unusual functions from end systems, including PIM, reduces code size and makes integrations more manageable. You can read more about ESB systems in this article.

It is usually not difficult to understand existing data flows; it is more difficult to identify accumulated problems in point-to-point integrations. But in any case, this work also takes time.

Work out, customize, coordinate, rebuild... completely rework?

“Wait a minute,” you say, “what does it mean to recycle”? So even if you go through all six of the previous steps, you still have to make changes to the PIM system?”

We can say from our own experience that yes, we will. Somewhere it's minor, but somewhere you'll need to rethink a large block of information.

Pre-project analytics allows you to get closer to the optimal version of the PIM system at the time of implementation and avoid creating a deliberately non-working project. But the IT circuit cannot (should not) freeze for centuries. Your company is developing as a living organism: business processes, interaction models, and business as a whole are changing. And since the IT circuit and each of the IT services should always be a reflection of the business, they will inevitably have to be changed as well.

And there is an important consideration here: we should not hope that we will be able to “save up minor changes and return to the integrator in a year”. As soon as the system stops supporting current processes through its own functions, your employees will again get used to solving their problems bypassing PIM — using Excel, 1C, Google Sheets... And by the time you contact the integrator again, PIM will become an unused burden. Therefore, the tactic of saving and procrastinating will only lead to the need to reimplement the PIM system instead of the planned minor improvements.

There is a huge gap in business value between a system that is built “once” and is not capable of changes and a system that is constantly being modified to flexibly adapt to current business needs. And the name of this gap is frugality and continuous improvement (as well as Agile and digital transformation). If you don't think about it, you shouldn't implement PIM either — Excel will be better.

‍