How we implement PIMs in global eCommerce platforms?

Care to share?

Integrating Product Information Management (PIM) systems into existing eCommerce infrastructures is a burden. As always, the first step is the hardest. So while working with world market leaders, we came up with a process that helps us to confirm the project’s requirements, design a solution and verify if a taken direction is good. Here’s how we do it:

In the last years, we have built complex Product Information Management systems for global leaders, generating over EUR 12 billion in total sales yearly. From fashion to metal and electric industries, working on existing systems operating in multiple countries is tricky. The new PIM solution has to match the client’s business goals and be compatible with already functioning solutions (ERP systems, databases and eCommerce platforms just to name a few). Often, PIM is the tool that connects multiple companies and sellers operating in various countries and languages.

Of course, it depends on the company size, product models and product enrichment processes. The PIM implementation process will look different for wholesalers, manufacturers, and B2B or B2C eCommerce, but despite the business, understanding the clients’ needs and answering all their business requirements is the key.

Powerful Product Information Management for Magento. Explore the benefits >

Mistakes and risks in PIM implementations

While working with global companies, we are always challenged with the business scale – like databases with over 650k objects, multiple languages and importing data in different formats. Another important issue in eCommerce is ETIM Classification which has to be implemented across all the companies within the business.

What are the most common mistakes we observe?

  • Missing one of the actors that play a role in the Product Information Management process, because the project team doesn’t see its part.
  • Overcomplicated workflow before publishing a product in the selected channel.
  • Too many features for the MVP version.

All of them are the result of poorly prepared business requirements. In effect, the future PIM system can represent a workflow that is too complicated and causes an increase in the time-to-market. Or if an actor is overlooked, the system can’t be fully implemented in the company.

How to avoid these and similar mistakes?

4 steps for painless PIM implementation

While working on PIM implementations, we have learned that there is no better way to do it well than to run tests. Based on our previous experiences we have built a four-step path which allows us to understand and confirm clients’ business requirements and then evaluate development phases with our client.

1. Run a proof of concept

The point of a Proof of Concept, aka PoC, is to prove the feasibility of a solution or the feasibility of a critical aspect of a solution, e.g. can we have centralized PIM for a few companies, where data will be shared between them.

At the start we define the PoC criteria, then develop a testing environment and measure if the criteria are met. Once, we worked with a company offering assembly and fastening materials in 6 Eastern European countries. The company’s goal was to improve product distribution, and so we recommended Pimcore’s PIM. To see if this solution was the right one, right we prepared six test Pimcore instances corresponding to the central database and invited company members to the test team.

By running this Proof of Concept, we learned that using Pimcore is the right choice in this case. What’s more, in a short time we gathered the business requirements, confirmed them with the client and planned the PIM’s architecture.

2. Prepare the developer backlog

Usually, while implementing the PoC, we run a business analysis phase. It’s divided into two major activities: discovery workshops and creating a Business Requirements Document (BRD). During discovery, the workshop team discusses the requirements for the designed system, and they are written to the Business Requirements Document. Based on this document, the lead developer creates a requirements backlog which will be a base for the project scope.

Exemplary requirements backlog.

3. Control PIM implementation process

From the very beginning, test all new features, and don’t forget to engage the client in this process. Let’s get back to our example. We began our PIM implementation in October, 2017 and from the start, our client could test new functionalities in his instances. Each company had its own test instance, to which the new functionalities were applied to test at the same time thanks to the automated continuous deployment process.

Thanks to this, the customer had constant access to the system being created and could test and observe changes incrementally. The development stage was divided into three phases, based on the delivered functionality package.

4. Evaluate each development phase

In addition, after the completion of each development phase, we organize meetings or summaries with the client, so he is always up to date and, in case of new problems, we can easily discuss them and make decisions. Make this process easier by letting your customer into your backlog system.

Our customer had access to the Jira ticket system, where he made comments and submissions, as well as new requirements. What’s more, the client was able to follow the prepared BRD documentation on an ongoing basis, where the statuses of particular functionalities and business requirements were marked.

Manage your content across all customer touchpoints with Pimcore >“></a></span><script charset=

Summary

This 4-step model of cooperation is even more important when we work with companies with many stakeholders. It allows stakeholders to have an impact on the final version of the system, while our implementation process remains uninterrupted. Of course, each project is different and so this model may vary, but in many cases, it has helped us to deliver top-notch PIM solutions and support global companies in catering to end users, with consistent product information in all possible touchpoints.

Published June 13, 2019