Blog & News

Read what we are doing

Key Master Data Facets: Context

Context:  Fitting Master Data to your business needs

The conventional view of master data management is that it helps you get to a single version of the truth. But as I pointed out in the last post on time, “truth” is often relative to “when.”   If we ask, what is the stock ticker for Hewlett Packard, both HWP and HPQ are correct because the original HP ticker,  HWP, was replaced on May 6, 2002 with HPQ.  If we consider a country and its states as a hierarchy, “when” has an impact on what’s in the hierarchy. The sub-division hierarchy for Sudan (ISO3166 SD), changed in 2011 with the secession of subdivisions SD-14 and SD-23. Those regions came together to become South Sudan (ISO3166 SS).

In both examples, I’m using basic master data because it tends to maintain its meaning irrespective of our frame of reference.   Sudan represents a physical location, that space may grow or shrink over time, it might even change its name, but it is still a physical location. When you start to address more complex master data–customers, suppliers, products– the frame of reference, or business context, of your audience starts to matter.

In fact, if we were to sketch this out, it might look a bit like this mxn matrix. Where each row, m,  represents the business context of legal, sales, marketing, etc.  And where each column, n, represents the version, or edition, from a point in time. What is true depends on who and when you ask. (and I thought Rashomon was complex!) Before I verge too far into the philosophical, what does this mean for the MDM practitioner.  Since we’ve already covered temporal effects in the previous post, lets just focus on the different business contexts and its impact on master data (one of the columns, or a vector mx1).

context1

Do you need to maintain contextual views?

The first question is do these points of view matter?  If you’re only planning on handling elementary forms of master data–country codes, security symbols– business context may not be an issue, you’ll just need to deal with versions over time.

Research tells us that most firms are not focusing on more than elementary data. MDM expert  Andy Hayler has found that most organizations are focused on domains like customer, product, supplier and organization–domains where context matter a great deal.  Since that’s the case, what are a few of the business context issues that one should look for?

Does each business context require different labels?

This case is really easy to see in internationalization. Consider that you’re a worldwide soft drink product manager where each country represents a new business context.

context2

While you might label the beverages كوكاكولا in Abu-Dhabi, 可口可樂 in Taipei, and Coca-Cola in Wichita, they still represent the same product.  The context of the target country drives the labeling.   We can see similar effects in hierarchies.

context3

Above we see the MSCI Global Industrial Classification Standard. While the labels and descriptions are different for France and Germany, the relationships, or hierarchy, between the sectors → subsectors → industries → sub-industries does not change.   The MSCI team has translated the labels and the descriptions to reduce dissonance overseas.

Label changes do not always need to be due to a foreign language issues.  You may have cases where your engineering, or system facing groups use more precise industry terms (or terms of art), while your client or market facing teams use more colloquial language.

Does each context require different hierarchies?

Unlike the previous example, this type of business context adaptation is a bit more complicated because you are altering the hierarchies to fit a specific business need. We can see this kind of problem when different groups work with entity data.

Imagine your company is doing business with several subsidiaries of General Electric: GE Healthcare, GE Power Systems, and GE Money.

  • Legal wants the official hierarchy of GE because they need to understand where liability would be assigned in the event of a default.
  • Sales needs GE broken down by industry, since the physicians, engineers, financiers all may have different needs and buying cycles.
  • Marketing would like a GE separated by country, since the copy of the awareness campaign would probably run better if it was in the local language.

As you add more teams–engineering, product management, support –there is a high likelihood that they will deal with that entity in a slightly different way and need a different hierarchy.

Does each context require different labels and hierarchies?

Finally, there will be cases where both the hierarchy and the labels are subject to adaptation.  One might see this example with products that are sold world-wide.  Not only could names may be modified to meet local language requirements, there may be situations where product line are merged (or split) to meet specific local demand.

For example, if you compare the product lineup for Subaru in Australia vs. Japan you’ll notice a couple of things.  First, the Subaru midsized sedan, Legacy is named Liberty in Australia.  Next, you’ll see that the Subaru Outback, which is a trim-line in Japan is a full-fledged model line in Australia.  Perhaps this has to do with the relative robustness of the SUV market in Australia (and the lack of an SUV market in Japan).

Just like in the first example, groups responsible for the P&L for mid-sized car division at Subaru would want to make sure that irrespective of what it was named, and where it falls into the country specific product hierarchy – -the revenue flows are credited properly.   Additionally, the engineering staff, if they needed to issue a recall would need to get that list irrespective of the name of the vehicle or the location in the hierarchy.

How does your MDM platform manage these business contexts?

Often, companies start their master data management projects by focusing in on a specific business context and domain combination; for example, mastering product information for product management. The number of contexts increase as more groups use the product data because each new group uses the product information in a slightly different way.

context4

As I pointed out in the examples above, each new group’s point of view is a permutation of the original content.  This means there’s always going to be a segment of information that is shared across all business contexts.  This means the MDM platform needs to manage three things: the original content, the permutations created by the business context, and the relationships and shared content between the business contexts and the original.  If you’re looking at figure 4, you’ll need to manage the top box, each box in the hierarchy (the derivatives) and the blue arrows.

One approach is to manage only one instance by combining all the contexts. This is similar to the flattened approach from my post on time.   While this is pretty easy to implement and it eliminates the need to manage relationships between the different contexts , using this structure can get pretty messy. Imaging our coca-cola example and having to add a new product name field for every country/language combination.

Another approach is to create copies of the original content then customize each copy. This improves upon the combined approach by isolating the business context from original content.  The isolation means you can overload fields, for example, making the product_name field represent the English value in the original context and the Arabic name in the Abu Dhabi context.   The main issue here is dealing with the shared content between the business contexts and the original.   Because these are copies, you’ll need to run  after the fact synchronization and that creates all the issues you’d expect.

context5

A final approach is to use inherited data sets. In this case, child datsets are created from the original and the elements that need to be modified to fit the business context are adjusted. The inherited copies are just the deltas (and pointers back to the inherited content).   Because the inherited data set references, not copies, the original source as the parent copy changes those values flow down into the children.

Up till now we’ve talked about the technical aspects of time and context.  But what about the people? And how do they interact to govern and address the lifecycle related to master data? And that is the topic of our next post.

Photo Credits
Arabic Coke Can: http://www.flickr.com/photos/zoonabar/3138681857/
Chinese Coke Can: http://www.flickr.com/photos/pinkellie/2637761803/
English Coke Can: http://www.flickr.com/photos/elsie/4023275760/

By Conrad Chuang