How to Create a Data Model for Success

I remember a debate I had with my boss near the beginning of my career involving data management and value. 

He was asking me to set up a system to track some data to which I said we already have a system that tracks that data. We got into a lengthy discussion about it. My point was that it costs money to capture, manage and store data, and that unless the fruits of that effort were higher than the cost, you shouldn't do it. His point was that he was the boss and I was the kid still learning the ropes. 

Of course, he was right. 

Fast forward to today and an MDM project. Certainly, an important measurement of success is going to be whether the project and resulting system deliver value to the organization, and 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?

- What is the core data object(s) 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, and the business objective is to accelerate new product setup or to reduce the time it takes to get new product information into your selling channels. 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, and we want to define the data and specific characteristics of the data necessary to satisfy the 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 measures

Let's take the first objective as an example. 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, we examine Part Number to document where it is currently being created, maintained, and stored. We document the characteristics of Part Number in our company such as:

-      Every product must have a Part Number, i.e., it is required

-      Every Part Number has a specific structure, i.e., we'll need to validate the format

-      Every Part Number must be unique, i.e., duplicates are 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

-      The Part Number is a unique identifier that identifies a specific product in all company systems

-      The Part Number 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. 

This goes back to that debate I had with my first boss, why replicate everything you are already managing into yet another system? You may get it up and running faster but does that deliver incremental value to the organization? The beauty of modern MDM platforms is that they inherently support an incremental approach. They offer a great deal of flexibility where it is easy to add to the model over time as new objectives are defined, or new uses discovered. This gives you the opportunity to evolve your MDM initiative in a way that is grounded in business objectives and demonstrates value along the way.

Many tend to view 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 measurables, 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.