Anatomy of a PIM Implementation

June 14, 2019
blog image for Anatomy of a PIM Implementation

A PIM, or Product Information Management System, provides a singular place to collect, manage, and enrich product information; create a product catalog; and distribute it to eCommerce channels. The need for accurate and up-to-date product information has increased for merchants, and this is where a PIM can be a valuable asset. Designed to serve as a central repository for all your product information, a PIM greatly simplifies the data management and enrichment process, and facilitates the syndication of accurate and timely data across all your channels. 

Now that you know what a PIM is, you may be wondering what it actually takes to successfully implement a PIM. What are the pieces? What tasks will you encounter? Every PIM implementation is unique, and if you think about it, they should be. Take, for example, if you were a retailer with 1 million products in your catalog from hundreds of suppliers, your PIM implementation would look very different from a manufacturer with 500 products customizable by color, material, and finish.

While there are many PIM providers out there, let’s use one in particular in order to break down a typical PIM implementation into its main components and activities. We work often with Akeneo PIM, so I’ll be referencing them in this article and using some of their terminology and process framework. The ideas are pretty common across other vendors’ PIM systems.

PIM Discovery and Planning Sessions

The Design and Discovery phase is up first. Having successful project discovery and planning sessions are critical to the success of your project. Granted, this is often an iterative process and what comes out of these sessions almost certainly will need revision as you start to dig into the project. It’s often the first time that all the stakeholders and partners get in a room and dig into the data (and problems with the data).

Organizational [buy-in] is key. Smart planning with all of the stakeholders at this point is critical for long-term success. Establish clear business goals to back up your technical implementation. If you start the process anticipating development setbacks and data deficiencies, you can create processes to follow. Of course, it’s important to make sure these are communicated and adopted internally — if your content team goes in and edits everything by hand downstream after you implement your PIM, it may invalidate all the work implemented up front.

 

Don’t leave a PIM discovery session without accurate (or as accurate a possible), current, and idealized product enrichment flow diagrams! These will help serve as your “North Star” as you start making decisions about how you build your PIM. In these sessions, prioritize understanding first how data flows through the system, the connectors and data sources that matter the most to your business then move on to understanding workflow. And while this is never as fun as you think, this is the time to have an honest discussion about how clean your product data is. 

 

Common Activities

  • Functional Workshop 
  • PIM Concepts Overview 
  • Stakeholder Interviews  

Resulting Artifacts

  • Requirements Document 
  • Project Schedule 
  • Project Plan 
  • Inventory of Product Data Sources
  • Enrichment Flow Diagrams 
  • Current Product Lifecycle Definition 

Key Questions

  • What does your current product lifecycle look like?  
  • Are you happy with it? 
  • Does it meet your business needs?  
  • Can/should automation be employed for efficiency? 
  • What is (Be honest!) your data quality?

Attributes, Families, and Product, Oh My!

Before you can import/create any products in your new PIM, you have to define your catalog structure (i.e. how you organize your data). That journey begins with the question, “What data makes up a product?” Akeneo, in particular, requires several dependent structures created before you can start building your first product.

It makes sense — in order to have a product, you need to have a definition of the kind of product it is, which in this case we might call a “family” (a type of product with a distinct data signature). A family is composed of pieces of data or “attributes.” The attributes need to exist first, then any attribute options, then you can make the families, and then products — then repeat. Be sure to review your collection of product information to validate any assumptions you’ve made about your data. 

 

A common source of confusion is what data should live in a PIM. Sometimes taking a flexible position with this question is needed, but in general, we often differentiate types of data by “hot” and “cold” data. Cold data means data you access or changes less frequently. Cold data should live in the PIM, while hot data is data that can change frequently, so the most recent version needs to be accessed in real-time or near real-time like sale price, current inventory, and product page views. Hot data should usually be left out of the PIM. This is for a number of reasons, including that PIM systems are designed to store and enrich static or “near static” data and don’t meet the availability, scalability, and performance requirements you might expect from a real-time transactional data platform.

 

Cold Data (goes in your PIM!):

  • Description
  • Color
  • Weight
  • SKU
  • MSRP 

Hot Data (doesn’t go in your PIM!)

  • Price/Sale Price
  • Current Inventory
  • Product Views
  • Units Sold  

While PIMs tend to emphasize features like data visualization, enrichment, syndication, and workflow management, including “hot data” in a PIM can result in poor user experience and cause headaches down the road as your organization’s data needs scale. 

 

Do you know where your product information lives? And are you sure? Discovery often turns up many surprises not limited to untracked spreadsheets, soon to be deprecated eCommerce platforms, legacy ERPs, and supplier API feeds. Capture and document these locations and formats. Try to define as much of your catalog as possible by hand for your new PIM.  

Sometimes this is impractical, and automation is required. Don’t let your legacy product catalog structure (defined or unorganized) guide your PIM development. PIM needs and structure should never be dictated by external dependencies. It’s not uncommon for a PIM implementation to be created as a quick fix for an eCommerce platform lacking a user-friendly back-end site, or a legacy ERP being phased out and the marketing team refusing to manage all product data in spreadsheets anymore. This structure will dictate many future data flows. Time spent getting it right before future developments/deployments will pay dividends.  

Common Activities

  • Catalog Workshop 
  • Stakeholder Interviews 

Resulting Artifacts

  • Requirements Document 
  • Proposed Product Family Designs 
  • Proposed Attribute Structure 

Key Questions

  • What data makes up a product? 
  • Is your catalog small enough to model entirely by hand? 
  • What product groups can you prioritize to see the largest gains? 
  • What types of product data make up a product (e.g., text fields, numbers, files, etc.)?

Importing Data Into Your PIM

Now that you have a catalog structure, you can start looking at importing data into the PIM. At the most basic level, this can be as simple as leveraging out-of-the-box functionality of an Excel/CSV import/export tool included in most PIMs. If products are born in the ERP or other external systems, they most likely will flow into the PIM via automated import connector. This can be scheduled nightly or more frequently if necessary, for your business needs.  

Sometimes, integrations need not repeat, for instance, if you’re importing from soon-to-be-retired product databases or legacy eCommerce sites with the latest product descriptions. Do you really want to spend months building and testing a back-end connector to transform data from an outdated database when you could spend a couple of days creating CSVs and importing them in a more manual way? 

DAMs (Digital Asset Managers) are a great integration for catalogs that have (or are building) rich image, video, and file data for products. Many PIMs such as Akeneo have asset management functionality but are limited to storing image names and locations and minimal transformations. If digital assets are a core business need, plan out their integration to your PIM.  

The goal with any integration here is to fill a business need. Any enrichment to product data there should flow effortlessly into the PIM.  

 

Common Activities

  • Requirements Workshop  

Resulting Artifacts

  • Requirements Document 
  • Proposed Data Flow Map 
  • Proposed Solution Architecture 
  • Solution Design Document 

Key Questions

  • What systems store product data that should live in the PIM? 
  • Will this integration be a single import? 
  • If repeating, how often should this import run? 
  • Do you need additional solutions to fill your business needs?  

Data Validation is The Life-Blood of a PIM

This section could easily go before Integrations. One of the key strengths of a PIM is in facilitating the goal of a single source of truth for product data. The power in having a single source of truth only exists if that source is complete, valid, and trustworthy. Misspellings, various abbreviations of the same word (e.g., ct vs. count vs. CT), and ambiguous data (bullet points are notorious for this!) all hurt your data quality.  

 

Start by setting the most restrictive data types on your product attributes (choose selections, numbers, and metrics over simple text fields). Many PIMs also allow for text format validation. Leverage it when you can. Advanced data clean-up can also occur via customizations to import functions. Parsing bullets and descriptions for more descriptive attribute types can work as well.  

 

Complex product structures and hierarchies should be explored at this stage. If you have parent/child product structures, take the time here to analyze them and ensure they are configured correctly. 

 

This process can take a significant amount of time to complete properly. However, Data Validation is the life-blood of any PIM solution. Your PIM will be stronger for it and so will your return-on-investment (ROI). 

 

Ultimately, to borrow a phrase, “only you can prevent forest fires!” In this case, decide what is an acceptable amount of data clean-up that should occur within your PIM. In a perfect world, all data validation would occur on (or before) import, and your PIM would be spotless from day one. That’s unrealistic for most organizations and that’s OK! Just make sure you’re developing a schedule and workflow for enriching that messy data that is already imported and can be cleaned up in future projects later on. 

Common Activities

  • Requirements Workshop 
  • Product Data Analysis for common errors 

Resulting Artifacts

  • Requirements Document 
  • Proposed Attribute Data Types to enforce new data cleanliness 
  • Solution Design Document 

Key Questions

  • How clean is your data? 
  • Are your complex products correctly mapped and configured? 
  • How critical are your data validation errors?  
  • Is it more efficient to clean data before import or once it's visible in the PIM? 

Send Your PIM Data Into The World

Now that you have robust product data — time to take a victory lap (or enjoy a cocktail?)! Yup! Well, not quite. You want to send it into the world! So, where will it go? Print catalogs, eCommerce, Point of Sale, and Marketplaces are all possible destinations. Identify the differences in what product data should flow each target, often referred to as contextualization, and design your PIM to handle those variations. Akeneo primarily uses “channels” to allow for variations in product data and “locales” to support internationalization when exporting to different destinations. 

It’s not uncommon to begin a new PIM project by focusing on eCommerce as the primary destination for this newly enriched data. Plan for the needs of your eCommerce site in your design phase, but don’t let it dictate your PIM’s strategic decisions. 

Why not? Product data from a PIM perspective is different than your eCommerce site. Replacement parts, related products, print catalog quality content, and even configurable products all differ between eCommerce needs and best practice for a PIM. Building your PIM only to spit out what Magento (or any other eCommerce solution) wants will limit you to that model and catalog structure. If you build your PIM to be the best representation of your products then you have better data, and that will help in the future. 

 

Common Activities

  • Requirements Workshop 
  • Stakeholder Interviews 

Resulting Artifacts

  • Requirements Document 
  • Solution Design Document  

Key Questions

  • How many data consumers are in your product information ecosystem? 
  • Are there different requirements for each consumer? 
  • How critical is your data validation that flows to down-stream consumers?  
  • Is it more efficient to clean data before import? Or once it's visible in the PIM? 

Are You Ready to Implement?

While there are many parts and considerations that go into a PIM implementation (e.g., catalog structure, integrations, imports, exports, workflows, etc.), some of the first steps you’ll need to consider will involve choosing the right PIM vendor and potentially an implementation partner. There are many PIMs out there, a few of the most common are Enterworks, InRiver, and Akeneo.

Depending on your team structure, implementation could happen in-house, or you may find yourself relying on an implementation and support partner. Most PIM vendors have partner programs that will list out certified vendors, however, it can be helpful to engage with a partner before choosing which PIM vendor to use.

A great partner is one that can understand your business and guide and support you through this process. We’re often brought in to help recommend which PIM product will work best, and that can change based on which eCommerce platform you’re using, how many products you’ll need to support now and in the future, and what internal systems you already have in place. Of course, it’s often easier when we’re involved in the process from start to finish — building the site, integrating the eCommerce platform, and connecting all the dots.

No matter which partner, platform, or PIM you use, if you follow the steps outlined above and take time to complete each step, most of the common pitfalls can be caught and planned for and you will have a solid team in place to guide you along the way. There will always be some unexpected developments in any project, but building your PIM in this order will enable you to dodge most of the major issues and plan and prioritize what is most critical for your business.