Skip to main content


Prepping for Product Information Management (PIM) Implementation Resizeimage 5 (1)

Maintaining data is not a new challenge. It’s complex when you want to succeed in the market and want to get ahead of your competitors. The eCommerce market is expected to grow further in coming years, making data management a crucial factor.
This post is a quick guide that will help you not just to implement your product information management (PIM) solution, but also make the necessary preparations before the implementation phase.
I have divided the analysis you need to do to prepare for PIM implementation into four phases (as per the BDAT pillars of the TOGAF framework).
Diagram 1 - BDAT Pillars of TOGAF: Business Architecture, Data Architecture, Application Architecture, Technology Architecture
There is no definite sequence defined between Data Architecture and Application Architecture, but I preferred to go with Application Architecture first.

1. Business Architecture

The very first action item in each phase is to draw and understand the baseline (existing) architecture. The ideal situation is to have an architecture repository with all artifacts that reflect the baseline architecture. If you do not have this in place, then I would recommend you prepare it first.
Your baseline architecture should include a definition of how your current enrichment process works. Out of all possible different analysis visuals or diagrams, the most simple is to create a flow diagram that explains the different phases of product enrichment, right from concept to reality to market. Identify which teams are involved in the product’s enrichment process. This will help to identify how product enrichment is happening.
The most common problems are:

  1. There are multiple copies of same information in different systems. So to modify any single piece of information, one has to coordinate with different platform owners.
  2. The way the information is presented is different across different sales channels. For example, two different sales channels are selling same product with different marketing descriptions.
  3. There is no single platform where multiple teams or members to collaborate.
  4. Manually updating information can lead to errors.

As a part of your target architecture, a very simple diagram (Diagram 1 – Concept to Reality to Market) can help to define how the target system should work and how different teams can come together to enrich all data in one single portal.
Diagram 2 - Concept to Reality to Market
Product Enrichment, Product Categorization and Publish to Market (green colored boxes) should always be a part of the PIM system. In some cases, Initial Concept or Prototype information can also be maintained within PIM. This depends on the case and whether you want to have unapproved products in your PIM. Keeping unapproved products in your PIM can be a challenge because those product may not have SKUs assigned to them at that stage, making it difficult to identify them uniquely with the PIM platform.
After your concept is approved, all the enrichment must happen in the PIM system in a collaborative effort from the different teams. Once the enrichment is complete, you can push the data to multiple channels.
There should not be any enrichment in sales channels themselves, but within the PIM system only.

2. Application Architecture

As a part of baseline architecture, you’ll need to identify the number of systems that contribute to the product enrichment process, as well as how these different systems are integrated together and what kind of information they share. You ultimately have to identify the purpose of each system in place.
When defining your target architecture, with the consideration of the PIM system’s involvement, you must redefine the integration protocol and redefine the responsibilities of each system. In this case, it may happen that some of the responsibility is transferred to the PIM system, or you may identify the elimination of any old system.
A gap analysis between the different systems would show you what all systems are needed and how they are integrated with each other. The key point here is that there should not be a situation where two different systems have the same responsibility because that could create a conflict for either the users or the data.
There is no limit on how the complex your application architecture could be, but below is the one of the simplest diagrams with the systems expected to be included in your target architecture.
Diagram 3 - Application Architecture

3. Data Architecture

One of the crucial phases of implementing a PIM system is designing a model that can maintain the intended product information in one place and will provide the other systems with the data they need. With the identification of your enrichment process (Business Architecture) and your target application architecture, you get a good understanding of where to start data modeling.
As a part of your baseline architecture, you first need to understand the structure of your data and how it is categorized in the current architecture context. It’s very important to understand the current state of your data quality and catalog structure. You may identify the current data quality as poor and in need of some massaging.
For example,

  1. There are parts associated with the assembly and these parts can be sold individually, but when the user tries to buy these parts individually, they do not have any association back to the original assembly. The user may get confused or may not get a clear picture of which assemblies this part can be used with. So, the association of a part with the possible assembly is missing.
  2. If you have multiple copies of data in different systems, it may be unclear which version contains the correct, final information.
  3. The depth of your product structure is also important. In some cases, your products may have different assemblies and then each assembly has parts and the parts have accessories and the accessories are not sellable. In such situations, the question that you must find an answer to is, “How we can make our product or catalog structure simple, so users do not find it confusing and it’s easy to navigate on our website.”

There are lots of factors that can help you analyze and improve your product data quality. The catch here is to resolve these issues before finalizing your target data architecture or model.
Below is one of the simplest forms of conceptual data modeling. Again, the more simplified your model is, the better the manageability, implementation, and integration will be.
Diagram 4 Data Modeling
A conceptual data model further gets turned into a local or physical model. Generally, a physical data model defines the very minor of level of details like each field and its data type. A simple proof of concept may help you review and visualize your model and make sure it meets the data needs of all your stakeholders.

4. Technology Architecture

As a part of defining or understanding your baseline technology architecture, you need to identify the systems in place and how they are integrated together to share information. You also need to evaluate the reliability of their integration.
With your new PIM system in place, you’ll need to define how all the existing or new systems will integrate with the PIM. Define the integration architecture and what technologies you will use for integrating the different systems seamlessly. There are multiple options in the market that can help make the integration possible, such as Microsoft Azure Service Bus, etc.
Define how your data transformation will be carried out and make sure all of the integrations will be flawless. The older way is just integrating a system using some file transfer protocol (FTP or SFTP) to share information between two different systems. There are number of factors that can help you decide what to use for this integration. You’ll need to take into consideration data integrity, uptime, IT security policies, etc.
Your options can also be defined based on whether there should be a direct coupling between two platforms or if you should use loosely coupled systems with a middleware approach to maintain the data in a queue before it is consumed by another system.
Diagram 5 - Integration Example

Opportunity and Solutioning

The gap analysis from all above different phases will help you draw a final solution or Architecture Definition Document for your implementation phase. Each phase gives you an opportunity to identify current issues and how your target architecture can solve the business problems.
The analysis from the above phases will give you a good starting point to create the requirements for your implementation phase.

User Onboarding

Apart from all the analysis and implementation phases, user onboarding defines the major success factory of the project. At the end, users should be comfortable using the new PIM system. If users are not comfortable, then whole success matrix will fail, even with the greatest system and integration design. Designate one product owner who has a good knowledge of the PIM platform and its features. They can help define a direction that can generate maximum value out of the implementation. A simple training session before the implementation phase can be a great start.

inRiver PIM

inRiver PIM is one of the leading solutions for product information management. It’s one of the simplest solutions that can solve many business problems related to PIM.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.