One of the first things we hear when we engage with a new client is “our data sucks” followed by a “can you fix it?” or “we need a PIM”. Our response is usually something like “how do you know?”, “yes we can”, and “you probably do.” Let me explain…

“Our data sucks” might be true, but it isn’t a very technical term, it’s emotional and subjective. What we need to do is to get to something a bit more objective and descriptive. That’s why one of the first things we ask when we hear this is “how do you know?”. Often the response is “because our customers tell us the data is no good” or “our competitors have much better data than us”. These statements begin to expand on the meaning of “sucks”, but we need to go a level deeper to formulate a game plan.

We like to start at the end by probing the primary use cases for the data. For example, is the data being used for print publications, to feed a website, to send to trading partners, for regulatory compliance, or a myriad other use-cases. What we are trying to get at is the end game, how are you using the data and how does it drive value for your business. Once we have a consensus on the use cases we can begin to define the data elements that best support those use cases. For example, in the website use case we may agree that we need basic product descriptors such as a part number, a model number, weights and numbers, a basic description, and so on. We might also decide we want features and benefits, one or more images, how-to guides, complementary products, and specifications unique to a given product type. All of these data elements contribute to optimizing the data for use on the web site. What is probably becoming apparent is that these data elements reside in different systems (being a realist we’ll include Excel as a system) and are likely maintained in different departments. Assembling these data requirements takes cross-functional participation and is often best facilitated by a third party.

With the data elements identified now we can begin to document the data model, and the more complete the documentation of the model, the better it will serve you through the rest of the process and into the future. Things to consider when documenting the model include:

  • the data element name
  • a short description of the data element and how it is used
  • where the data element is mastered today, and where it should be mastered going forward
  • who can create it, who can change it
  • does it apply to all objects (we’ll use products for example), or is it unique to a specific product category, and if so, which category
  • is it constrained to certain valid values, for example, a list of colors
  • are there other constraints such as length of characters, or number of decimal places
  • which use cases does the data element support (if the answer is none, question why it exists)

There may be many other considerations that apply based on the use cases defined and your specific needs, but this is a good starting list.

Now we come to “Can you help us fix it?”. With agreement on the use cases and the beginnings of a documented data model, the answer is “Yes we can”. It is possible to provide some insights into problem areas in the data before this, but it is difficult to assess without the model. For example, we could conduct a data profiling exercise and identify that weights and measures are arbitrarily expressed in multiple forms such as “1.25 in”, “1-1/4 inch”, “1.252 in” and so on. And we could surmise prior to the creation of the data model that this may be problematic in certain use cases, but having the model defined allows us to benchmark the data, current and future, against specific criteria we have developed that support the intended use cases. With the use cases and model defined we can identify areas where the data is missing, where it violates the model, or perhaps even where the data may challenge the model or use case itself. By collaborating on “what it is”, “what it needs to be”, and even “what do you think is next” your users can stop worrying about their data and start imagining what comes next.

How do we perform this analysis? We have use cases, we have a data model, we have data – so how do we put it all together to assess “suck-i-ness” and plot a course of improvement. This is where you need a tool, and as most correctly assume it is probably a PIM or MDM product (we use the two interchangeably in this discussion, although there are use cases where the difference will be relevant).

A PIM comes with predefined functionality to support most business requirements it was designed to support; however, there is work we need to do to begin to take advantage of its functionality. First, you will want to take the model you have defined and create it in the PIM to include the rules and constraints that have been defined for each data element. Now we can begin to plan the migration into the new PIM / new model as we visualize where problems and opportunities exist. This exercise is key as not only does it engage the current data owners to really help define their data, it provides them the place (PIM) to realize the future. The PIM will also help us identify areas where the model itself needs to be revised. It allows you to see the entire data record for that object, a product in this case, in one place. Many of the PIM products can even preview the data in the context of one of your use cases. This provides direct visibility into where to begin a data improvement initiative and start to realize the value of your data.

So, what comes next? Your data is managed is now mastered in a new system where it’s available to you and your enterprise with speed and accuracy. You trust your data and that it meets your quality standards. But that’s just adding efficiency to your business today. It becomes exciting when you begin to leverage the flexible, decoupled nature of your PIM model to enable rapid deployment of business decisions. Shortly after PIM go-live, we start to see our customers execute more projects from their strategic roadmaps… New product assortments? Allow vendors to self-manage? Connect to more trading partners? Drive an increase in Consumer engagement? Expand your digital footprint?  PIM helps relieve the chains of legacy systems so that business can focus on… the business.

We have only touched on basic concepts here, we haven’t talked about workflows, automation, on-going data governance, or organizational change management, all of which will come into play in a comprehensive data management project such as this, but hopefully, this helps to begin to shape answers to those initial questions. If the perception is that the data “sucks” there are likely opportunities for improvement, for as the saying goes where there is smoke there is fire. To focus your efforts, it is key to identify your use cases and the data necessary to optimize those use cases, get a tool if you don’t have one, such as a PIM or MDM product, load your data, and begin to Harness The Power of Your Data.