So, in the first stage, the implementation team recorded the existing problems and 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 takes all the stated interests into account.
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 is the difference and what should be taken into account
For example, one company we worked with stored wholesale and retail SKUs in one 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 about them."
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 range is limited to five colors, and if it is made of wood, to seven.
There are also less obvious rules: instead of a list of attributes, there is a range with a value selection rule. For example, a product's length and width may fall within 80 to 260 cm in 1 cm increments, 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 this case, PIM implementation turns into simply shuffling spreadsheets around.
from Excel to PIM, which does not solve any systemic problems: employees will continue filling out endless records, only 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 a simple, ordinary product: a pillow.
This is how it looks on the marketplace
Seems simple enough? This is what a pillow information model looks like in a PIM system. And this is only half of the characteristics!
The information model captures all characteristics important for sales, marketing, production, logistics, and procurement. A pillow is not just "50 x 70 cm, filling - sheep 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? -
Does the pillow allow air to pass through?
(Yes, that is a characteristic too!) - Which channels sell the pillow: your own stores, marketplaces? Or is this model 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 that this was simply impossible: the data was extremely fragmented, and maintaining it would require too much effort. After numerous discussions, we found out that two thirds of the attributes are loaded directly from supplier factories and are then not processed in any way within the holding company, meaning they do not need to be entered or changed - they only need to be 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.
Dissatisfaction with the new product will build up. In time, the request to "start over properly" will emerge.
- reimplement PIM, but this time so it works 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.
