Why every PIM project is different

This or something similar could be the subtitle of a book about the introduction of PIM solutions in companies.

But first a step back: According to the abbreviation, PIM initially means "product information management". PIM systems bring together a lot of information that is known in the company about a product. Unlike ERP (Enterprise Resource Planning) systems, which take care of all the data that makes a product saleable, a PIM system focuses purely on sales information. For example, dimensions, product characteristics and media such as operating instructions and data sheets can be found in the PIM. Prices and inventory information, on the other hand, do not belong here.

This already brings us to the first practical problem: Many customers begin such a PIM integration project with the expectation of finally getting a global view of all the information in their product range. You'll often hear management saying: "Finally, I will be able to see everything in one place". In fact, this can even be done - but then you would have clearly missed the point and brought data into the PIM that it neither can nor wants to manage.
Remember: A PIM is not a dashboard for the product range.

Speaking of product range: The first step in every successful PIM project is to map one's own product model in the PIM. Basically, a distinction is made between products (e.g. "T-shirt") and articles, i.e. characteristics of products (e.g. T-shirt, size 56, color red). Already here it becomes exciting. Not all software products follow these designations; Shopware, for example, distinguishes between articles and variants. So caution is called for.

The assortment built up in this way is now sorted into a classification tree. This is not about the subsequent presentation in the shop, marketplaces or print products, but solely about the grouping of similar articles. The classification tree gets more and more specific from top to bottom. A path within the tree could therefore be, for example:

Tool -> Power tool -> Cordless tool -> Cordless screwdriver

The idea is that, for example, every cordless tool has properties that it inherits from the "power tool" classification, such as the electrical power. At the same time, however, a "cordless tool" has properties that not every power tool has, such as its battery voltage.

The classification tree serves to increase data quality, since each classification level can introduce mandatory fields. In the case of the cordless tool mentioned, for example, the battery voltage could be defined as a mandatory field. In this way, the PIM forces the editor to take a close look at the article and, if necessary, to obtain missing information from the supplier.

In practice, this step often separates the wheat from the chaff. If you do not work properly here, you will have the problem afterwards that it may not be clear into which classification an article belongs. Always keep in mind: It's not about the categories in the online store, but purely about the question "What makes the article and what defines it?"

Good classifications have another advantage: You can define when a product or article has been maintained to the point where it may be routed to the individual channels. In this way, you set a minimum standard that every article must reach in terms of content. Unsightly things such as articles without a picture or descriptive text are now a thing of the past, because the PIM prevents an article from being published in case of doubt. In addition to a possibly existing distributional barrier provided by an ERP, a PIM can thus form an editorial hurdle that the article has to overcome. It also makes it possible to keep an article out of an English-language store, for example, until all content has been fully translated.

Any PIM project could work like this or similar if you could start on the proverbial "green field". Unfortunately, the reality is different: Many PIM systems cause considerable costs - especially in the initial phase of the project. Among these there are the pure licenses for the product used. It makes sense to deal with these issues in a series of workshops and to involve all stakeholders of the company as early as possible. Although this ties up personnel and a relatively large amount of time, it pays off quickly and increases the acceptance of the project.

However, the devil is often in the (technical) details. In addition to the project team that makes decisions about content that's why it's important to put together a technical team. Besides the in-house IT staff, this team should always include developers and contacts from the PIM manufacturer. Problems often arise at various points during the implementation phase, but they can be solved quickly if official channels can be bypassed. Practical experience with the existing systems can then also be incorporated here.
After all, the best sales presentation is of no use if the project stalls afterwards because, for example, the company's special requirements were not known and therefore could not be taken into account.

It is essential to check in advance whether the planned PIM solution meets all requirements. Clarify whether the software covers all use cases. Interfaces to all existing systems or the options for creating them are particularly important. But factors such as scalability can also become important in the case of large installations.

Don't try to turn your entire product model upside down with the PIM. After all, your employees are "creatures of habit" like all humans. If you're going to introduce them to a new system for data maintenance, at least leave them with familiar territory in terms of content. Proceed cautiously - introduce the system, gain experience and only then change the process bit by bit or adjust mechanisms.

Then you will also be able to deal with the "exceptional problem" mentioned at the beginning and the project will be exceptionally good.