When creating a data model, an important measurement of success is going to be whether the project and resulting system deliver value to the organization. in particular, more value than it cost. Otherwise – why do it? As with any data management project that adage of “garbage in/garbage out” comes into play with MDM. If you don’t have the right data and processes defined, you can’t expect a system to meet your objectives or yield the value you pitched to the executives. And, we all know, many aspects of data management will determine whether the system delivers the benefit intended to include data, workflows, approvals, standards, etc. In this article, we’re going to focus on the data, and, in particular, a means to determine what data needs to be managed.

Ensuring the right data is in the system is largely going to be a function of defining an appropriate data model at the outset.

Determining the appropriate data model involves answering some fairly straight-forward questions, such as:

  • What are the business objectives for the project and how will you measure success?
  • Which core data object(s) will be involved?
  • What are data elements live at the intersection of your objectives and the core data object? (For example, assume the core data object is a product with a business objective to accelerate new product setup. What data elements are involved in these scenarios?)
  • How are those data elements created? Where are they maintained? Who is organizationally responsible for them?
  • Do standards exist for those data elements?
  • Are there current data level issues that need to be addressed?

You may have additional questions of interest, but I think you get the point. We have a business objective. We want to define the data and specific characteristics of the data necessary to satisfy that objective.

Many MDM vendors today come equipped with very nice templates for defining and ingesting the data model. The challenge for many clients is that when presented with these multi-tabbed, macro-driven Excel masterpieces, they don’t necessarily know where to begin. The approach described above of identifying the necessary data in the context of the business objective should help with that. For example, again let’s assume this is a Product MDM project.

Our goals might include:

  • Reduce product setup time and effort;
  • Improve regulatory compliance;
  • Speed time of publishing product information to selling channels
  • Reduce shipping errors due to inaccurate weights and measurements

Let’s take the first objective for our data model

If we consider a product and the data associated with setting it up, we can begin to settle in on what matters, and how to account for that in our MDM system. For example, we know we will need a Part Number.  So, by examining Part Number we can document where it is currently being created, maintained, and stored.

We document the characteristics of Part Number in our company such as:

  • Products will be required to have a Part Number
  • Part Numbers have a specific structure, that will need to validate for format
  • Part Numbers will be unique with duplicates not allowed

And so on.

At the end of this exercise we know:

  • The Part Number is currently created by Product Management
  • They create and maintain the Part Number in the ERP system
  • There is a unique identifier that identifies a specific product in all company systems
  • Each is constructed with a 3-digit prefix representing the product group code, followed by a 5-digit random number, i.e., xxx-xxxxx
  • The Part Number must be unique; we never reuse them, we always retire them
  • For the purposes of our objective, we desire to have the Part Number created in the MDM system and fed to the ERP and other systems

We continue this process of working through the necessary data elements that satisfy our objectives. You’ll notice that not only does this help to construct an initial data model that will meet the goals and deliver value to the organization, but you are also beginning to document the basis for some of your data governance activities down the road.


Of course, there are shortcuts, or at least perceived shortcuts, to this process. We do see some who simply want to take all their current data and dump into an MDM system. This approach may work for some, but the danger is that you end up with yet another system, managing the same data as others and overloaded with excess data the purpose of which nobody can remember and that does not deliver a value higher than its cost.

Many tend to view the speed of implementation as a critical success factor, and surely none of us favor a lengthy process. However, doing it fast, at the expense of doing thoughtfully, i.e., targeted to align with specific objectives and measurable items, is not necessarily the best approach. Make sure that before you begin to actually build something in your MDM platform that one of the columns in that modeling spreadsheet the vendor gives you is “Objectives Supported.” It should record everything you decide to include that contributes to the satisfaction of one or more objectives. If you can’t identify an objective it supports – why bother?

This is as a primer to help you begin a process to determine what to include in your MDM data model, but, of course, this is only a starting point. Choosing the right partner who provides consultative support with an eye to the measurable success of the initiative will ensure your success. Amplifi’s team has decades of experience designing data models for some of the world’s top brands. Contact us today to see how we can help you.